Software Project Management

Precedence network (activity-on-node)

        +--> B (3) ---+
A (5) --+             +--> D (10)
        +--> C (5) ---+

A has no predecessor; B and C both follow A; D follows both B and C.

Forward pass (ES = earliest start, EF = ES + duration)

Backward pass (LF = latest finish, LS = LF - duration)

Paths

• A - B - D = 5 + 3 + 10 = 18 weeks
• A - C - D = 5 + 5 + 10 = 20 weeks

Critical path: A - C - D (all with zero float), and the project duration is 20 weeks. Activity B has a float of 2 weeks.

Step 1: Schedule (earliest start)

Step 2: Planned Value (PV) at day 10

• A: fully planned, 1000
• B: fully planned (5 to 10), 1000
• C: 5 days done of 10, $5 \times 100 = 500$
• D: starts on day 10, 0

$PV = 1000+1000+500+0 = 2500$

Step 3: Earned Value (EV) = % complete $\times$ budget

• A: $1.00 \times 1000 = 1000$
• B: $1.00 \times 1000 = 1000$
• C: $0.40 \times 1000 = 400$
• D: $0$

$EV = 2400$

Step 4: Actual Cost (AC)

$AC = 1200+800+800+0 = 2800$

Step 5: Variances and indices

$SV = EV - PV = 2400-2500 = -100$

$SPI = \frac{EV}{PV} = \frac{2400}{2500} = 0.96$

$CV = EV - AC = 2400-2800 = -400$

$CPI = \frac{EV}{AC} = \frac{2400}{2800} = 0.857$

Interpretation: SV is negative and SPI is below 1, so the project is slightly behind schedule. CV is negative and CPI is below 1, so it is over budget; each rupee spent has earned only Rs 0.86 of work. Corrective action is needed, especially on cost.

CPM network (activity-on-node)

        +--> B (4) ---+
A (4) --+             +--> D (6)
        +--> C (2) ---+

Forward pass

Backward pass

Paths

• A - B - D = 4 + 4 + 6 = 14 weeks
• A - C - D = 4 + 2 + 6 = 12 weeks

Critical path: A - B - D (zero float), and the project duration is 14 weeks. Activity C has 2 weeks of float.

Forward pass (ES = earliest start, EF = earliest finish):

E starts after both B (EF = 2) and D (EF = 4), so ES(E) = max(2, 4) = 4. The project duration is the largest EF, which is 8 weeks. The backward pass starts from LF = 8 at the end and subtracts durations.

Precedence network (activity-on-node):

        A(2) ---> C(4) ----------+
       /                          \
Start                              ---> End
       \                          /
        B(2) ---> D(2) ---> E(4) -
         \_________________/

B is also a direct predecessor of E, and D precedes E.

Paths:

• A - C: $2 + 4 = 6$ weeks
• B - E: $2 + 4 = 6$ weeks
• B - D - E: $2 + 2 + 4 = 8$ weeks

Critical path: B - D - E, duration 8 weeks. These activities have zero float. A and C each have 2 weeks of float.

Step 1: Schedule and planned value

Budget at completion $BAC = 1600 + 800 + 1200 + 1600 =$ Rs 5,200.

At the end of day 12 all four activities are scheduled to be finished, so

$PV = 1600 + 800 + 1200 + 1600 = \text{Rs } 5200$

Step 2: Earned value

$EV = \sum (\%\text{ complete} \times \text{planned cost})$

• A: $1.00 \times 1600 = 1600$
• B: $1.00 \times 800 = 800$
• C: $0.75 \times 1200 = 900$
• D: $0.50 \times 1600 = 800$

$EV = 1600 + 800 + 900 + 800 = \text{Rs } 4100$

Step 3: Actual cost

$AC = 1400 + 400 + 1000 + 1000 = \text{Rs } 3800$

Step 4: Variances and indices

$SV = EV - PV = 4100 - 5200 = -\text{Rs } 1100$

$SPI = \frac{EV}{PV} = \frac{4100}{5200} = 0.79$

$CV = EV - AC = 4100 - 3800 = +\text{Rs } 300$

$CPI = \frac{EV}{AC} = \frac{4100}{3800} = 1.08$

Interpretation: The project is behind schedule (SV negative, SPI < 1), having earned only about 79% of the planned work, but it is under budget (CV positive, CPI > 1), getting Rs 1.08 of work for every Rs 1 spent.

Step 1: Schedule (earliest start)

Step 2: Planned Value (PV) at day 16

• A: 600 (complete)
• B: 600 (complete)
• C: 4 days of 8 planned, $4\times200 = 800$
• D: 4 days of 4 planned, 1200

$PV = 600+600+800+1200 = 3200$

Step 3: Earned Value (EV)

• A: $1.00\times600 = 600$
• B: $1.00\times600 = 600$
• C: $0.25\times1600 = 400$
• D: $0.50\times1200 = 600$

$EV = 2200$

Step 4: Actual Cost (AC)

$AC = 800+400+500+400 = 2100$

Step 5: Variances and indices

$SV = EV-PV = 2200-3200 = -1000$

$SPI = \frac{EV}{PV} = \frac{2200}{3200} = 0.6875 \approx 0.69$

$CV = EV-AC = 2200-2100 = +100$

$CPI = \frac{EV}{AC} = \frac{2200}{2100} = 1.048$

Interpretation: SV is negative and SPI is well below 1, so the project is considerably behind schedule (only about 69% of the planned work is done). CV is positive and CPI is above 1, so it is slightly under budget. The main concern is the schedule, mainly because C and D are behind.

(a) Programme management vs portfolio management

(b) Payback period

The payback period is the time required for the cumulative net cash inflows of a project to equal the initial investment. It tells how long it takes to recover the money invested.

$\text{Payback} = \text{years before recovery} + \frac{\text{unrecovered cost at start of year}}{\text{cash flow in that year}}$

Use as an evaluation technique: Compute the payback of each proposed project and compare it with a cut-off period set by the organization. Projects that pay back within the limit are accepted, and where projects compete, the one with the shortest payback is preferred.

Example: Investment Rs 1,00,000, inflows Rs 40,000 a year: payback $= 100000/40000 = 2.5$ years.

Advantages

• Simple to calculate and understand.
• Favours projects that return cash quickly, reducing exposure to risk and uncertainty.
• Good for situations with liquidity problems or fast technology change.

Disadvantages

• Ignores cash flows after the payback date, so profitability is not measured.
• Ignores the time value of money (in simple form).
• The cut-off is subjective.
• May reject good long-term projects.

(a) Risks of an online voting system

(b) Ranking by risk exposure

1. R1 Security breach (3.0)
2. R2 Requirement changes (2.4)
3. R3 Server failure (2.0)
4. R4 Low user acceptance (1.5)

(c) Contingency plan for R1 (security breach)

Trigger: intrusion alerts, unexplained mismatch between vote counts and logs, or a report of unauthorised access.

Preventive (mitigation) measures:

• Encrypt data in transit (TLS) and at rest, use strong two-factor voter authentication and digital signatures.
• Run penetration testing and security code review before release, and apply patches promptly.
• Keep tamper-evident audit logs, and use a firewall and intrusion detection.

Contingency actions if the breach occurs:

1. Immediately suspend the voting service and isolate affected servers.
2. Activate the incident response team, and preserve logs for forensic analysis.
3. Restore the system from the last verified clean backup, and verify vote integrity against audit logs and receipts.
4. Notify the election commission and the affected voters, and reopen voting only after the vulnerability is fixed, possibly extending the voting period or using paper ballots as a fallback.
5. Review the incident and update the security plan.

Owner: security manager; the plan is reviewed before every election.

Return on investment (ROI) is the ratio of the average annual net profit to the total investment.

$ROI = \frac{\text{Average annual profit}}{\text{Total investment}} \times 100\%$

Step 1: Total net profit

$\text{Total inflows} = 5000 + 5000 + 20000 + 40000 + 50000 = \text{Rs } 120{,}000$

$\text{Net profit} = 120000 - 50000 = \text{Rs } 70{,}000$

Step 2: Average annual profit (over 5 years)

$\frac{70000}{5} = \text{Rs } 14{,}000$

Step 3: ROI

$ROI = \frac{14000}{50000} \times 100 = 28\% \text{ per year}$

Equivalently, the total ROI over the project life is $\frac{70000}{50000} \times 100 = 140\%$, i.e. 28% a year.

Identifying activities means listing all the tasks that must be done to complete the project.

Activity-based approach

The activities are found by first producing a Work Breakdown Structure (WBS) or an activity list, decomposing the project's work into tasks in a hierarchy. Each task then gets a duration, resources and dependencies, and the project network (e.g. a PERT/CPM diagram) is constructed from them. It is often a product-oriented or a task-oriented decomposition. It is suited to projects where the work is well understood and the tasks can be foreseen in detail.

Hybrid approach

It combines the product-based and the activity-based methods. The top levels of the WBS are broken down by products or deliverables (e.g. system modules), and then, at lower levels, each product is broken down into activities needed to create it. For example, a system's modules are first identified, then each module is divided into analysis, design, coding and testing activities. This is common in software projects.

Software project management is challenging because software is different from most engineered products, and these differences make planning, estimating and controlling the work hard.

• Invisibility: Software cannot be seen or touched. Progress is hard to measure, so a task can be reported "90% complete" for a long time without anyone being able to verify it.
• Complexity: Software has far more states and interactions per unit cost than physical products. A small change can have effects in many places.
• Conformity: Software must fit the requirements of customers, users, existing systems, laws and standards, which are set by people and are often inconsistent.
• Flexibility and changeability: Software is easy to change, so users keep asking for changes, even late in the project. This causes scope creep and rework.
• Uncertain requirements: Requirements are often vague, incomplete or misunderstood at the start and change as the users see the system.
• Estimation difficulty: Effort, size and duration are hard to predict because there is little historical data, technology changes quickly and productivity differs widely between people.
• Human factors: Development depends on skilled people. Team communication, motivation, turnover and skill gaps strongly affect the result.
• Technology change: Tools, languages and platforms change quickly, so the team keeps learning during the project.
• Constraints of time and cost: Pressure to deliver quickly with a fixed budget leads to shortcuts that affect quality.
• Quality and risk: Defects are hard to detect, and testing can never show that all faults are removed. Risk must be managed continuously.

Because of these factors, a software project manager needs sound planning, risk management, change control and good communication to deliver on time, within budget and with the required quality.

Abraham Maslow proposed that human motivation follows a hierarchy of needs. A person is motivated by the lowest unsatisfied need; once it is satisfied, the next higher need becomes the motivator. The five levels, from bottom to top, are:

1. Physiological needs: Basic survival needs such as food, water, shelter, sleep and a basic salary. At work: adequate pay and a reasonable working environment.
2. Safety needs: Security, stability, protection from harm and fear of loss. At work: job security, safe working conditions, health benefits and pension.
3. Social (belonging) needs: Friendship, affection, acceptance and being part of a group. At work: team spirit, good relations with colleagues and supervisors.
4. Esteem needs: Respect, recognition, status, achievement and self-confidence. At work: promotions, titles, praise and responsibility.
5. Self-actualization needs: The desire to reach one's full potential, to be creative and to grow. At work: challenging tasks, creative freedom and opportunities for learning.

        /\   Self-actualization
       /--\  Esteem
      /----\ Social
     /------\ Safety
    /--------\ Physiological

Relevance to software projects: A manager should find out which need is active in each team member. For example, a developer worried about job security needs reassurance before recognition will motivate them. Offering training and challenging assignments motivates staff who are already satisfied at the lower levels. A satisfied need no longer motivates.

Software quality is judged by several quality factors, which describe the characteristics a product should have. The McCall model groups them by the three phases of the software life cycle.

Product operation (how well it works)

• Correctness: The software does what the specification and the user require.
• Reliability: It performs its function without failure over a given period.
• Efficiency: It uses computing resources (time, memory) economically.
• Integrity: It controls unauthorized access to software and data.
• Usability: It is easy to learn, operate and understand.

Product revision (how easy it is to change)

• Maintainability: Errors can be found and fixed easily.
• Flexibility: It can be modified for new requirements with little effort.
• Testability: It can be tested easily to confirm that it works as intended.

Product transition (how well it adapts to a new environment)

• Portability: It can be moved to another hardware or software platform.
• Reusability: Its components can be reused in other systems.
• Interoperability: It can exchange data and work with other systems.

ISO 9126 gives a similar set of characteristics: functionality, reliability, usability, efficiency, maintainability and portability. Quality requirements should be stated clearly at the start of a project, with measurable targets for each important factor.

Software Configuration Management (SCM) is the discipline of identifying, organizing and controlling changes to the software and its related work products throughout the life cycle, so that the integrity of the product is maintained. The SCM process has the following activities.

1. Configuration identification: Decide which items are placed under control, called configuration items (source code, requirements, design documents, test cases, user manuals, build scripts). Each item gets a unique name and version number, and baselines are defined.

2. Version control: Record and manage the different versions of each item using a repository (for example Git or SVN), with check-in/check-out, branching and merging, so that earlier versions can always be recovered.

3. Change control: All changes follow a formal procedure:

   • A change request is submitted and logged.
   • The change is analysed for impact on cost, schedule and other items.
   • A change control board (CCB) approves or rejects it.
   • If approved, the change is made, tested and reviewed, and the item is then checked in to form a new version or baseline.

4. Configuration status accounting: Records and reports what has been changed, when, why and by whom, and the current state of each item and baseline.

5. Configuration audit: Verifies that the approved changes have been made correctly and that the product matches its requirements and documentation (functional and physical audits through reviews).

6. Build and release management: Builds the software from the correct versions of the items and packages controlled releases for delivery.

Through these steps, SCM prevents uncontrolled changes, avoids conflicts between developers and keeps the product traceable.

In a slip chart, a line that bends to the right means that activities are behind schedule and a line that bends to the left means that they are ahead. The line is updated at every reporting date, and a line that keeps bending away from the plan shows that the manager must take corrective action. A Gantt chart is mainly a planning tool, while a slip chart is a monitoring tool.

1. Present worth

Present worth (present value) is the value today of money to be received or paid in the future, found by discounting it at a chosen discount rate $r$:

$PV = \frac{C_t}{(1+r)^t}$

where $C_t$ is the cash flow in year $t$. Money received now is worth more than the same amount received later because it can be invested and because of inflation and risk. The net present value of a project is the sum of discounted cash flows:

$NPV = \sum_{t=0}^{n}\frac{C_t}{(1+r)^t}$

A project with $NPV > 0$ is acceptable, and among competing projects the one with the highest NPV is preferred. For example, Rs 10,000 received after 2 years at 10% is worth $10000/1.21 =$ Rs 8,264 today.

2. PERT diagram

PERT (Program Evaluation and Review Technique) is a network technique used for planning and scheduling projects where the activity durations are uncertain. It is drawn as a network of events (nodes) and activities (arrows) showing precedence.

For every activity, three time estimates are made:

• $a$ = optimistic time
• $m$ = most likely time
• $b$ = pessimistic time

$t_e = \frac{a+4m+b}{6}, \qquad \sigma = \frac{b-a}{6}$

The forward and backward passes find earliest and latest event times, slack and the critical path. The variance of the critical path is the sum of the variances of its activities, and this is used to estimate the probability of completing the project by a target date.

Why discounted cash flow (DCF) techniques are better

Net profit and return on investment (ROI) are simple, but they have serious weaknesses:

• They ignore the time value of money: Rs 10,000 earned in year 5 is treated the same as Rs 10,000 earned in year 1.
• They ignore the timing of cash flows, so two projects with the same total profit but different timing look equal.
• ROI depends on the accounting method and on how the average investment is defined.
• They do not take the cost of capital or the risk into account.

DCF techniques (NPV and IRR) discount each future cash flow to its present value at a discount rate $r$:

$NPV = \sum_{t=0}^{n}\frac{C_t}{(1+r)^t}$

so that earlier cash flows count more than later ones. They therefore give a realistic measure of the real value created by a project, allow projects with different time profiles to be compared fairly and include the cost of capital.

Applicability of IRR with respect to NPV

The Internal Rate of Return (IRR) is the discount rate at which $NPV = 0$. A project is acceptable if $IRR >$ the required rate of return (cost of capital).

• IRR is expressed as a percentage, which many managers find easy to compare with the cost of capital. It does not need the discount rate to be known in advance, only to be compared at the end.
• NPV gives the absolute value added (in rupees), so it is better for choosing between mutually exclusive projects of different sizes, and it is additive.
• IRR can mislead when comparing projects of different scale or timing (rankings can conflict with NPV), when cash flows change sign more than once (multiple IRRs), and it assumes cash flows are reinvested at the IRR itself.
• Therefore NPV is preferred for ranking, while IRR is a useful supporting measure; for a single conventional project both give the same accept/reject decision.

Manual calculation of IRR (trial and interpolation)

1. Choose a discount rate $r_1$ and calculate $NPV_1$ (positive).
2. Choose a higher rate $r_2$ such that $NPV_2$ is negative.
3. Interpolate:

$IRR \approx r_1 + \frac{NPV_1}{NPV_1 - NPV_2}\,(r_2 - r_1)$

4. Verify by calculating the NPV at the estimated rate and refine if needed.

For example, a project with cash flows $-1000$ and $+1100$ after one year has $NPV=0$ at $r=10\%$, so $IRR=10\%$.

Techniques for progress visualization

1. Gantt chart: Horizontal bars against a time scale show the planned start and finish of each activity. A "today" line and shading of completed portions show which activities are ahead or behind. It is simple, but does not show dependencies well.

2. Slip chart: A line that links the planned and the actual/revised completion dates of activities or milestones. The more the line bends from the vertical, the greater the slippage, so trends of delay are seen easily.

3. Timeline (milestone plot): Shows planned milestone dates over the reporting periods, so how the forecast date of each milestone changes from one report to the next is visible. Repeated moves of the same milestone point to a problem.

4. Ball chart: Shows the target start and end dates of activities or milestones as circles ("balls"). A ball is red when the date has slipped from the plan and green when it has been achieved on time, so it gives a quick status view.

5. Earned value (S-curve) chart: Plots cumulative planned value, earned value and actual cost against time. The gaps give SV and CV, and the SPI and CPI show schedule and cost performance.

6. Burn-down / burn-up charts: Remaining work (or completed work) against time, used in agile projects.

7. Traffic-light (RAG) reports: Green, amber and red status for each key area, to give managers a summary.

Why project monitoring and control is challenging

• Software progress is invisible, so it is hard to know the true state of the work, and people may report "90% done" for a long time.
• Estimates are uncertain, so plan baselines are not reliable.
• Requirements change frequently, so the plan has to be re-baselined.
• Information depends on the honesty and accuracy of team members' reports.
• Many interdependent activities and risks interact, so a delay in one place spreads to others.
• Collecting data takes effort, and the manager must decide when and how to react, because corrective actions have costs and side effects, such as adding staff to a late project.
• Distributed teams, third-party suppliers and technology changes make control harder.

The discount rate is not given, so a rate of 10% is assumed for NPV.

Net profit and ROI

• Project A: total inflows $=5000+15000+5000+40000+50000=115000$; net profit $=115000-40000=75000$.
• Project B: total inflows $=2000+10000+70000+50000+50000=182000$; net profit $=182000-80000=102000$.

$ROI_A = \frac{75000/5}{40000}\times100 = 37.5\%,\qquad ROI_B = \frac{102000/5}{80000}\times100 = 25.5\%$

Payback period

• A: cumulative inflows 5,000; 20,000; 25,000; 65,000, so payback is in year 4: $3 + \frac{40000-25000}{40000} = 3.375$ years.
• B: cumulative 2,000; 12,000; 82,000, so payback is in year 3: $2+\frac{80000-12000}{70000} = 2.97$ years.

NPV at 10% (factors 0.9091, 0.8264, 0.7513, 0.6830, 0.6209)

IRR (trial and interpolation): A is about 32% and B is about 25%.

Decision

Both projects are acceptable because the NPVs are positive and the IRRs exceed 10%. The two projects have different sizes, so ROI and IRR favour the smaller A, while NPV favours B. NPV measures the actual value added, so Project B should be chosen, as it has the higher NPV and a shorter payback. (If the cost of capital were above about 16.7%, the NPVs would cross and A would be better.)

Creating a project schedule is done in stages, normally as part of the activity planning process.

1. Define the project scope and objectives: Decide the deliverables and the work to be done, from the project plan and requirements.

2. Identify the activities: Break the work down into manageable activities using a work breakdown structure (WBS), an activity-based, product-based or hybrid approach.

3. Identify dependencies (sequencing): Determine the precedence relationship between activities: which must finish before others can start (finish-to-start, start-to-start etc.).

4. Estimate effort and duration: Estimate the effort and elapsed time of each activity, using expert judgement, analogy, three-point (PERT) estimates or algorithmic models.

5. Allocate resources: Assign people, equipment and other resources to the activities, considering skills and availability.

6. Draw the network and carry out the analysis: Build the precedence (CPM/PERT) network; do the forward and backward pass to find earliest and latest times, float and the critical path.

7. Resolve resource conflicts: Make a resource histogram and level the resources, adjusting the schedule using float, and shorten the critical path if needed (crashing).

8. Prepare and publish the schedule: Present it as a Gantt chart or other chart, get it approved, and set it as the baseline.

9. Monitor and update: Compare the actual progress with the schedule and revise it when needed.

The project management cycle (project life cycle in management) describes the sequence of stages through which a project is managed from start to finish. It is iterative, because information from later stages feeds back to earlier ones.

1. Project initiation / feasibility study: The idea is examined. Feasibility (technical, economic, operational) and business case are assessed, and the decision to go ahead is taken.

2. Project planning: The objectives, scope, activities, schedule, cost estimates, resources, quality, risk and communication plans are prepared, and a baseline is set.

3. Project execution (implementation): The planned work is carried out: analysis, design, coding, testing and deployment, and the team is organised and directed.

4. Monitoring and control: Progress is compared with the plan (for example by earned value), problems are identified and corrective actions are taken. This runs in parallel with execution, and it often leads to replanning.

5. Project closure (completion): Deliverables are handed over and accepted, contracts are closed, resources are released, documentation is archived and lessons learned are recorded for future projects.

Initiation -> Planning -> Execution -> Closure
                 ^           |
                 +-- Monitoring & Control --+

In the Stepwise/Cadle-Yeates view, the cycle is: set objectives, identify infrastructure, analyse characteristics, identify products and activities, estimate effort, identify risks, allocate resources, review/publicise the plan, and execute and lower-level planning. This cycle is repeated at lower levels of detail as the project moves ahead.

Leadership style is the manner in which a leader gives direction, makes decisions and motivates people. The main styles are as follows.

1. Autocratic (authoritarian): The leader makes decisions alone and tells the team what to do, with close supervision. It is fast and suits crises or inexperienced teams, but it reduces creativity and morale.

2. Democratic (participative): The leader consults the team and shares decision making. It raises commitment, creativity and satisfaction, but decisions may take longer.

3. Laissez-faire (free-rein): The leader gives the team almost complete freedom. It works with highly skilled, self-motivated people but may lead to lack of direction.

4. Transactional: The leader uses rewards and penalties and focuses on clear tasks, targets and performance.

5. Transformational: The leader inspires people with a vision, encourages innovation and develops followers.

6. Task-oriented vs people-oriented: A task-oriented leader focuses on getting the work done and a people-oriented leader focuses on relationships and the team's needs. (Blake and Mouton's managerial grid combines concern for production with concern for people.)

7. Situational (contingency) leadership: The leader adapts the style to the maturity of the followers and the situation (telling, selling, participating, delegating, as in Hersey and Blanchard).

Which style is best depends on the task, the team's experience and the situation. In software projects, with skilled and creative developers, a democratic or situational style is generally effective.

Verification vs validation

Testing principles

1. Testing shows the presence of defects, not their absence.
2. Exhaustive testing is impossible, so tests are selected using risk and priorities.
3. Early testing: start testing activities early in the life cycle to find defects cheaply.
4. Defect clustering: a small number of modules usually contains most of the defects.
5. Pesticide paradox: repeating the same tests stops finding new defects, so tests must be reviewed and updated.
6. Testing is context dependent: different kinds of software need different testing.
7. Absence-of-errors fallacy: a defect-free product is still useless if it does not meet the users' needs.

Baseline

A baseline is a specification or work product that has been formally reviewed and agreed upon, and which thereafter serves as the basis for further development. It can be changed only through a formal change control procedure. Examples are the approved requirements specification, the design document and a tested source-code release. A baseline provides a fixed reference point, so that the team can always return to a known stable state.

Why Software Configuration Management (SCM) is critical

Software changes constantly and many people work on the same items, so without control the result would be chaos. SCM is critical because it:

• Controls change: A formal change process (request, impact analysis, approval, implementation) stops uncontrolled and unauthorized changes.
• Manages versions: It keeps all versions of the code and documents, so it is possible to go back to an earlier version when a new change fails.
• Supports team work: It prevents developers from overwriting each other's work (check-in/check-out, branching and merging).
• Ensures integrity and consistency: The correct versions of the components are always put together in each build and release.
• Provides traceability: It is known what changed, when, why and by whom, linking requirements, design, code and tests.
• Reduces cost and risk: Fewer defects and less rework result from the control, and the maintenance effort is reduced.
• Supports audits and releases: The exact content of each delivered product can be reproduced.

Why PERT is efficient

PERT (Program Evaluation and Review Technique) is efficient because it deals with uncertainty in activity durations by using three estimates rather than one. It finds the critical path and slack, shows the activities that need close management and gives the probability of finishing by a given date. It also helps in "what-if" analysis, resource allocation and monitoring, and it focuses the manager's attention on the critical activities.

Estimated time

With optimistic time $a$, most likely time $m$ and pessimistic time $b$, the activity duration is assumed to follow a beta distribution, and the expected time is

$t_e = \frac{a+4m+b}{6}$

Standard deviation

The standard deviation of an activity is

$\sigma = \frac{b-a}{6}$

and the variance is $\sigma^2$. For the critical path the variances add, so

$\sigma_{path} = \sqrt{\sum \sigma^2_{critical\ activities}}$

Z-value

Z measures how many standard deviations the target date $T$ is from the expected completion time $T_e$ of the project:

$Z = \frac{T - T_e}{\sigma_{path}}$

The probability of completing by the target date is read from the standard normal table. For example, $Z=0$ gives 50%, $Z=1$ gives about 84%, and $Z=2$ about 97.7%. A negative Z means the target is earlier than the expected time, so the probability is below 50%.

a) Annual worth

Annual worth (annual equivalent worth) converts all the cash flows of a project into an equivalent uniform annual amount over the life of the project, using the discount rate $r$:

$AW = NPV \times \frac{r(1+r)^n}{(1+r)^n-1}$

where $n$ is the project life in years and the fraction is the capital recovery factor. A project is acceptable if $AW > 0$, and among alternatives the one with the highest AW is chosen. It is particularly useful for comparing projects with different lives, because each is expressed per year. Example: if $NPV =$ Rs 100,000 over 5 years at 10%, the factor is 0.2638, so $AW =$ Rs 26,380 per year.

b) Risk exposure

Risk exposure (RE), also called risk value, is a measure of the size of a risk, found by multiplying the probability of the risk occurring by the loss it would cause:

$RE = P(\text{loss}) \times L(\text{loss})$

For example, a risk with probability 0.4 and a loss of Rs 50,000 has $RE =$ Rs 20,000. Risks are ranked by RE so that the management effort goes first to the highest exposure risks. It helps in deciding the contingency plans, reserves and how much to spend on risk reduction.

Strategic assessment

Strategic assessment checks whether a proposed project fits the long-term objectives and strategy of the organisation. It is normally done at programme/portfolio level before the detailed project evaluation. The following issues and questions are considered.

• Objectives: How does the project contribute to the organisation's corporate objectives and strategic plan? Is the objective clear and measurable?
• IS plan: Is the project consistent with the organisation's information systems plan and architecture? Does it fit with existing and planned systems?
• Organisational structure and processes: How will the system change the way the organisation is organised and works, and are the people ready for the changes?
• Stakeholders and users: Who are the stakeholders? Are they committed? Will the users accept it?
• Business case and benefits: What benefits are expected and are they realistic? Are the costs justified?
• Alternatives: Have other ways of meeting the need been compared (buy, outsource, do nothing)?
• Risks and constraints: What are the main technical, financial and organisational risks? Are the resources, skills and technology available?
• Timing: Is the timing right with respect to other projects and the market?
• Responsibility: Who owns the project and who takes responsibility for the benefits?

Categories of direct costs and benefits

Direct costs

Direct benefits

(Direct benefits are those that are directly measurable from the system's use, while indirect and intangible benefits such as better decisions are harder to measure.)

Categories of resources

Resources are everything required to carry out the project activities. The main categories are:

1. Labour (human resources): People with the needed skills: analysts, designers, programmers, testers, project managers. Their number, skills and availability are planned.
2. Equipment: Hardware, development and test machines, servers, networks and workstations needed for the work.
3. Materials: Consumable items used up in the project, such as supplies and media.
4. Space (accommodation): Office, laboratory and meeting space for the team.
5. Services: Services such as network connectivity, power, consultancy or outsourced work.
6. Time: The time allowed for the activities.
7. Money (budget): The funds available to pay for the above.

(Software and tools, such as licences, tools and reusable components, are also commonly listed.)

Resource histogram and equalization (levelling)

A resource histogram is a bar chart that shows the amount of a resource (for example the number of programmers) needed in each time period, based on the activity schedule. Peaks and troughs show over-allocation and under-use.

The process of resource histogram equalization (resource smoothing or levelling) is:

1. Prepare the activity schedule (for example earliest-start) and the resources needed by each activity.
2. Draw the resource histogram for each resource and mark the periods where the demand exceeds supply or is uneven.
3. Find the non-critical activities with float that are scheduled in the peak periods.
4. Shift (delay) those activities within their float, or stretch them, to move work from peaks to troughs, without changing the project end date. Critical activities are not moved.
5. Where peaks remain, add resources, change the sequence or accept a longer duration.
6. Redraw the histogram and repeat until the profile is as level as possible and within the resource limits.

Why it is crucial

• Resources are limited, and over-allocation causes delays and makes the schedule unachievable.
• A smooth demand avoids hiring and releasing staff repeatedly, which saves cost and keeps morale and productivity high.
• It avoids idle (wasted) resources and overtime.
• It makes the schedule realistic and gives better cost control and predictability.

The discount rate is not given, so a rate of 10% is assumed.

Discount factor $=\dfrac{1}{(1.10)^t}$.

The cumulative discounted cash flow changes sign during year 4. After year 3 the amount still to be recovered is Rs 30,203, and the discounted inflow in year 4 is Rs 68,301.

$\text{Discounted payback} = 3 + \frac{30203}{68301} = 3 + 0.442 \approx 3.44 \text{ years}$

The investment is recovered, in present-value terms, in about 3.44 years (roughly 3 years and 5 months). For comparison, the ordinary payback period is $3 + \frac{200000-200000}{} = 3$ years exactly (100,000 + 50,000 + 50,000 = 200,000), and the discounted payback is longer because future inflows are discounted.

Activity planning is the stage where the project's work is broken down, sequenced, scheduled and resourced. It aims to achieve the following objectives.

1. Feasibility assessment: To check whether the project can be completed by the required date with the available resources and cost. If not, the plan must be changed or the targets renegotiated.
2. Resource allocation: To decide when and how many of each resource (people, equipment) are required, and to allocate them in the best way so that there are no conflicts or idle periods.
3. Detailed costing: Once the resource use and timing are known, to calculate the cost of the project, including its cash flow over time.
4. Motivation: A schedule with clear, realistic targets motivates the staff, because they know what is expected and when.
5. Co-ordination: To co-ordinate the efforts of different people and teams, and the work of different departments or suppliers, so that activities start when their predecessors finish and the right people are available.
6. Control and monitoring: To provide a baseline against which the actual progress can be compared, so that the delays and problems are noticed early and corrective action can be taken.
7. Risk reduction: To find the critical activities and the float, so that the risks to the schedule can be identified and managed.

The software project management (SPM) framework is the structure within which a software project is planned, organised, executed and controlled. It brings together the main elements that a manager has to deal with.

1. The four Ps

• People: The team, stakeholders, customers and users: their skills, motivation and communication.
• Product: The software to be built: its scope, requirements, size and quality.
• Process: The development life-cycle model and the set of framework activities, tasks and milestones (for example waterfall, incremental or agile).
• Project: The plan, schedule, cost, risks and control needed to deliver the product.

2. Management activities (the project management cycle)

• Planning: Scope, WBS, schedule, estimates, resource and quality plans.
• Organising: Defining roles, team structure and responsibilities.
• Staffing: Selecting, training and motivating people.
• Directing/leading: Guiding and motivating the team, and communication.
• Monitoring and controlling: Tracking progress (for example by earned value), managing change and corrective action.
• Closing: Acceptance, handover and lessons learned.

3. Knowledge areas Integration, scope, time (schedule), cost, quality, human resource, communications, risk, procurement and stakeholder management (as in PMBOK) cover the aspects to be managed. Software-specific issues such as configuration management, estimation of size and effort, and testing are added.

4. Planning framework (Stepwise) Select the project, identify its scope and objectives, identify the infrastructure, analyse the characteristics, identify the products and activities, estimate effort, identify risks, allocate resources, review the plan, and execute the lower-level plans.

The framework gives the manager a systematic way to ensure that the project is delivered on time, within budget and with the required quality.

A contract is a legally binding agreement between a customer (buyer) and a supplier (developer) for the delivery of software or services. In software projects, contracts are classified mainly by how risk and payment are shared.

1. Fixed price contract

• The price is agreed in advance for a precisely defined set of requirements.
• The customer knows the cost, and the supplier carries the risk of overrun.
• Suits well-understood requirements; changes need formal, costly change requests.
• Drawback: suppliers may add a large risk margin or cut quality to protect profit.

2. Time and materials contract

• The customer pays an agreed rate per unit of time (hour, day, month) for staff, plus the cost of materials.
• Requirements may be vague or evolving, so it is flexible.
• The customer carries the cost risk, and there is little incentive to finish early. A ceiling price is often added.

3. Fixed price per delivered unit contract

• The price is fixed per unit delivered, for example per function point or per line of code.
• Total cost is known once the size is measured, e.g. Rs 5,000 per function point $\times$ 400 FP = Rs 2,000,000.
• Needs an agreed counting method (such as IFPUG function points). Changes in requirements simply change the size and so the price.

4. Cost-plus (cost reimbursement) contract

• The customer reimburses the actual cost plus an agreed fee or percentage.
• Used where the work is new and the scope uncertain. It gives the supplier little incentive to control cost, so a fixed fee or incentive clause is sometimes used.

Other forms: bespoke versus off-the-shelf (COTS) supply, and outsourcing or offshore contracts, where one party delivers a complete service under a service-level agreement.

The Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, describes how mature an organization's software process is, and gives a path for improving it. Its aim is predictable, repeatable quality, cost and schedule.

It defines five maturity levels:

1. Initial: processes are ad hoc and chaotic. Success depends on individual heroics.
2. Repeatable: basic project management is in place (requirements management, planning, tracking, subcontract management, quality assurance and configuration management). Earlier success on similar projects can be repeated.
3. Defined: the process is documented, standardized and integrated across the organization, with training and peer reviews. Projects use a tailored version of the standard process.
4. Managed: processes and product quality are measured quantitatively, and are controlled using those metrics.
5. Optimizing: continuous improvement, driven by quantitative feedback, defect prevention and the introduction of new technology.

Each level (except 1) has Key Process Areas (KPAs) that must be satisfied, organized by common features: commitment to perform, ability to perform, activities performed, measurement and analysis, and verification.

Importance: it gives an objective way to assess suppliers and to find weaknesses, and it improves quality while reducing risk. It was later extended into CMMI.

Software Configuration Management (SCM) identifies, organizes and controls the changes to the work products (code, documents, test data) of a project. It supports change control and version control as follows.

Version control

• Each configuration item (source file, design document, test plan) is stored in a repository and given a unique identifier, e.g. 2.3.1 (release, version, revision).
• Every change creates a new version, so history is kept and any earlier version can be retrieved or rolled back.
• Check-in / check-out (locking or merging) prevents two developers from overwriting each other's work.
• Branching and merging lets parallel development (new features and bug fixes) happen without disturbing the stable line.
• Baselines and labels freeze a consistent set of versions that make up a release. Tools such as Git, SVN or CVS do this.

Change control

1. A change request is raised and logged, stating the reason and the affected items.
2. Its impact on cost, schedule and other components is analysed.
3. A Change Control Board (CCB) approves, rejects or defers it.
4. The approved change is made on a controlled copy, and the item is checked out and tested.
5. The new version is checked in, the baseline is updated, and the change is recorded and reported.

Together they prevent uncontrolled changes, keep a traceable record, protect baselines, and ensure that everyone works on the correct version.

Risk Exposure (RE) is a quantitative measure of how serious a risk is:

$RE = P \times L$

where $P$ is the probability that the risk occurs and $L$ is the loss (impact in cost or time) if it does. For example, a 30% chance of a Rs 500,000 loss gives $RE = 0.3 \times 500{,}000 =$ Rs 150,000.

Practical implications:

1. Prioritization. Risks are ranked by RE, so management attention goes to the highest exposures first (a risk exposure matrix or Pareto 80:20 approach).
2. Contingency budget. The total of the expected losses guides the size of the contingency reserve in cost and schedule.
3. Choosing responses. A mitigation action is worthwhile only if its cost is less than the reduction in exposure ($RE_{before} - RE_{after}$). It shows whether to avoid, reduce, transfer or accept a risk.
4. Comparing options. Different design or supplier choices can be compared by the risks they carry.
5. Monitoring. Exposure is re-evaluated through the project (risk register), so trends show if risks are getting better or worse.
6. Limitations. Estimates of $P$ and $L$ are subjective. Low-probability, very high-impact events may look small by RE yet be fatal, so they need separate attention.

1. Future worth (FW)

Future worth is the value at a specified future date of a cash flow or series of cash flows, when compounded at the interest rate $i$ for $n$ periods:

$F = P(1+i)^n$

For a uniform series $A$ per period:

$F = A\,\frac{(1+i)^n - 1}{i}$

Example: Rs 10,000 invested at 10% for 3 years gives $F = 10000 \times 1.331 =$ Rs 13,310. Projects with FW greater than zero are economically acceptable, and FW lets alternatives be compared at the same end date. It is the compounded equivalent of present worth $P$.

2. Bubble chart

A bubble chart is a network diagram used in project planning in which each bubble (circle) represents an activity or an event (a node) and the arrows joining them show the dependencies and the order of work. Durations or activity names are written inside or beside the bubbles.

• It shows which activities can run in parallel and which must wait for others.
• With durations added, a forward and backward pass over the bubbles gives earliest and latest times, float, and the critical path.
• Advantages: it is easy to read, shows the overall structure of the project, and exposes missing or circular dependencies.
• Limitation: it becomes cluttered for large projects.

The same bubble notation is used for the activity-on-node and activity-on-arrow forms of the precedence network, and for process bubbles in a data flow diagram.

Forward and backward pass:

ES(E) = max(EF(C), EF(D)) = max(6, 2) = 6. ES(G) = max(3, 10, 3) = 10. Project duration = 14 weeks.

Precedence network (activity-on-node):

Start --> A(1) --> B(2) ----------------+
            \                            v
             +--> C(5) --> E(4) -------> G(4) --> End
Start --> D(2) -----^                    ^
Start --> F(3) --------------------------+

Paths:

• A-C-E-G: $1+5+4+4 = 14$ weeks
• D-E-G: $2+4+4 = 10$ weeks
• A-B-G: $1+2+4 = 7$ weeks
• F-G: $3+4 = 7$ weeks

Critical path: A - C - E - G, 14 weeks (zero float).

Shortening the project duration

1. Only activities on the critical path can reduce the duration: A, C, E or G.
2. Choose the activities that are cheapest to speed up per week saved (crashing) by adding resources or overtime, or by assigning more skilled staff.
3. Other options: fast-tracking (do activities in parallel, e.g. start E's work in part before C finishes, if the dependency allows), splitting activities, reducing scope, or removing a dependency.
4. After each reduction, recalculate. The second-longest path is D-E-G (10 weeks), so the critical path can be shortened by at most $14 - 10 = 4$ weeks before D-E-G also becomes critical. Beyond that, both paths must be shortened together.
5. Watch for new risks: crashing raises cost and may reduce quality, and the shortened network should be re-checked for resource conflicts.

Why economic analysis is important

Software projects use money, staff and time that could be used elsewhere. Economic analysis compares costs and benefits, taking the time value of money into account, to decide whether a project is worth doing and which of several alternatives is best. It helps to:

• justify and select projects (go/no-go decisions) and rank competing proposals;
• estimate profit, payback and return on the investment;
• support budgeting and funding decisions;
• compare alternatives with different timing of cash flows on an equal basis;
• reveal the risk of overruns before the commitment is made.

Present worth (PW): the equivalent value now (time 0) of all cash flows, discounted at interest rate $i$:

$PW = \sum_{t=0}^{n} \frac{C_t}{(1+i)^t}$

A project is acceptable if $PW > 0$.

Future worth (FW): the equivalent value of all cash flows at the end of the study period $n$:

$FW = PW\,(1+i)^n$

Annual worth (AW): the equivalent uniform amount per period over the project life:

$AW = PW\,\frac{i(1+i)^n}{(1+i)^n-1}$

Uniform gradient cash flow

A gradient series increases by a constant amount $G$ each period: $0, G, 2G, \dots, (n-1)G$ at the end of periods $1, 2, \dots, n$. The formulas are:

$P = G\,\frac{(1+i)^n - i n - 1}{i^2(1+i)^n}, \qquad F = G\left[\frac{(1+i)^n-1}{i^2} - \frac{n}{i}\right], \qquad A = G\left[\frac{1}{i} - \frac{n}{(1+i)^n-1}\right]$

Example. Maintenance cost is Rs 0 in year 1 and grows by Rs 1,000 each year for $n=5$ years, $i = 10\%$, $G = 1000$. Here $(1.1)^5 = 1.61051$.

$P = 1000\times\frac{1.61051 - 0.5 - 1}{0.01\times 1.61051} = 1000\times 6.8618 = \text{Rs } 6{,}861.8$

$F = 1000\left[\frac{0.61051}{0.01} - 50\right] = \text{Rs } 11{,}051$

$A = 1000\left[10 - \frac{5}{0.61051}\right] = 1000\,(10 - 8.1899) = \text{Rs } 1{,}810.1$

Check: $F = P(1.1)^5 = 6861.8\times1.61051 \approx 11{,}051$.

Testing principles

1. Testing shows the presence of defects, not their absence.
2. Exhaustive testing is impossible, so tests are chosen using risk and priorities.
3. Test early (start in the requirements phase) to reduce the cost of fixing defects.
4. Defects cluster: a small number of modules contain most defects (Pareto principle).
5. Pesticide paradox: repeated identical tests stop finding new bugs, so test cases must be reviewed and updated.
6. Testing is context dependent (a banking system is tested differently from a game).
7. Absence-of-errors fallacy: a system with no known defects is still useless if it does not meet user needs.
8. Tests should be traceable to requirements and planned independently of the developers.

Test strategies

• Unit testing (white box, by developers) of single modules.
• Integration testing (top-down, bottom-up, big-bang, sandwich).
• System testing (functional, performance, security, stress, usability, recovery).
• Acceptance testing (alpha, beta, user acceptance).
• Regression testing after changes.
• Approaches: black-box, white-box and grey-box testing; static testing (reviews, inspections, walkthroughs) and dynamic testing.

SQA plan

The Software Quality Assurance plan describes how the project will ensure that the product and the process meet the required quality standards (for example IEEE 730). Its main contents are:

1. Purpose and scope, and the documents referenced.
2. Management: organization, roles and responsibilities of the QA team, and tasks.
3. Documentation: list of the required documents (SRS, design, test plans, user manual).
4. Standards, practices and metrics to be used (coding standards, quality metrics).
5. Reviews and audits: technical reviews, inspections, walkthroughs and audits, with a schedule.
6. Testing: the test strategy and the plan to verify each requirement.
7. Problem reporting and corrective action: how defects are recorded, tracked and closed.
8. Tools, techniques and methodologies used.
9. Configuration management, supplier control, records, training and risk management.

The plan is reviewed and updated through the project, and the QA team reports its findings to senior management.

A project plan documents how the project will be carried out. Different types are produced for different purposes:

1. Software project management plan (SPMP): the master plan covering scope, objectives, organization, schedule, budget, risks, deliverables and the approach.
2. Quality plan (SQA plan): the quality standards, reviews, audits and measures to be used.
3. Verification and validation / test plan: what will be tested, how, by whom, with what environment, and the entry and exit criteria.
4. Configuration management plan: how items are identified, versioned, baselined and changes controlled.
5. Risk management plan: how risks are identified, analysed, prioritized, mitigated and monitored.
6. Resource (staffing) plan: the people, equipment and tools needed, and when.
7. Schedule (activity) plan: activities, durations, dependencies and milestones, shown as Gantt or network charts.
8. Communication plan: who gets which information, how, and how often.
9. Maintenance and training plans: support after delivery, and user and staff training.

Plans are also divided by horizon: a strategic/high-level plan for the whole project, and detailed plans for the next stage, which are made when more information is known.

Return on Investment (ROI) is the net profit expressed as a percentage of the investment:

$ROI = \frac{\text{Net profit}}{\text{Total investment}}\times 100\%$

Total cost (investment):

$1000 \times \text{Rs } 1000 + \text{Rs } 2000 = \text{Rs } 1{,}002{,}000$

Revenue:

$1000 \times \text{Rs } 1500 = \text{Rs } 1{,}500{,}000$

Net profit:

$1{,}500{,}000 - 1{,}002{,}000 = \text{Rs } 498{,}000$

ROI:

$ROI = \frac{498{,}000}{1{,}002{,}000}\times 100 \approx 49.70\%$

The venture returns about 49.7% on the money invested.

Why they are required

When a schedule is drawn from activity durations and dependencies alone, the resource demand is usually uneven. Some periods need far more staff than are available (over-allocation) and other periods are idle. This causes overtime, burnout, delays and cost. Resource smoothing and balancing remove these peaks.

• Resource smoothing (time-limited): the project end date is fixed. Activities are moved only within their float, so the resource profile becomes level without changing the finish date.
• Resource balancing / levelling (resource-limited): the resource limit is fixed. Activities are delayed (and the end date may extend) so that demand never exceeds the available resources.

Together they give a steadier workload, better utilisation, less hiring and firing, lower cost, and a realistic schedule.

How it is carried out

1. Build the schedule and the critical path; identify float of each activity.
2. Draw a resource histogram (demand per period for each resource) and mark where it exceeds the limit.
3. Resolve the over-allocation by moving non-critical activities within float, starting with the one with most float or lowest priority.
4. If still over-allocated, delay activities beyond their float (extending the project), split or lengthen them, assign substitute resources, or add resources or overtime.
5. Recalculate the schedule and histogram after each change, repeating until the demand is within limits and the profile is smooth.
6. Re-check the critical path, since levelling can create new critical activities, and update the plan.

1. Gantt chart

A bar chart with activities listed down the side and time along the horizontal axis. Each activity is a horizontal bar from planned start to planned end. Progress is shown by shading the part of the bar completed, and a vertical today line shows the current date. Activities where shading is behind the today line are late. It is simple, and shows the plan against actual progress and overlapping tasks, but it does not show dependencies clearly.

2. Slip chart

A line chart with the actual date along the horizontal axis and the planned (target) completion dates of milestones on the vertical axis. A line is plotted joining the points as the project proceeds. A flat or downward line means the project is on time, and an upward-turning line shows the milestones slipping, so the trend is easy to see. A steep line warns that corrective action is needed.

(Other methods are the timeline chart, the ball chart showing milestones as red, amber or green, and the earned value chart.)

The contract process follows these stages (Hughes and Cotterell):

1. Requirements analysis: the customer decides what is needed, with functional and quality requirements, constraints and the intended budget. This becomes the basis of the Invitation to Tender.
2. Invitation to tender (ITT): the customer sends the requirement document, with instructions, to the potential suppliers (open, restricted or negotiated tendering).
3. Evaluation of proposals: suppliers prepare proposals (technical solution, price, schedule, experience). The customer compares them against criteria, scoring each on cost, functionality, quality, supplier track record and risk, perhaps with demonstrations or trials.
4. Negotiation and selection: the best proposal(s) are selected, and the price, schedule, payment terms and responsibilities are negotiated.
5. Contract award and signing: the legal agreement is signed with terms and conditions, deliverables, acceptance criteria, payment, intellectual property, warranty, penalties and termination.
6. Contract management: monitoring delivery, change control, acceptance testing, payment, and handling disputes up to delivery and closure.

Within the contract, work is usually broken into stages, each with deliverables, review points and payment milestones, so that the customer can control the risk.

SEI-CMM is the Capability Maturity Model for Software developed by the Software Engineering Institute (SEI) of Carnegie Mellon University, with funding from the US Department of Defense, to assess and improve the maturity of software development processes of an organization.

It has five maturity levels:

1. Initial: ad hoc, unpredictable, depends on individuals.
2. Repeatable: project management processes (planning, tracking, requirements, QA, configuration management) are established, so success can be repeated.
3. Defined: an organization-wide, documented and standard process exists, with training and peer reviews.
4. Managed: processes and products are measured quantitatively and controlled.
5. Optimizing: continuous process improvement through feedback, defect prevention and new technologies.

Each level (2 to 5) consists of Key Process Areas, with goals and key practices, grouped in five common features.

Importance

• It gives a common framework and language to assess process maturity, and a clear road map for improvement.
• Higher maturity leads to better predictability of cost and schedule, higher quality and productivity, and fewer defects and less rework.
• Customers use maturity level to select reliable suppliers (a requirement in many tenders), giving an advantage in outsourcing.
• It reduces dependence on individuals and risk of project failure, and helps to benchmark against other organizations.
• It led to CMMI, which integrates several models.

Configuration management (CM) is the discipline of controlling the items that make up the software and the changes made to them. Its responsibilities are:

1. Configuration identification: deciding which items (source code, documents, test data, tools) are configuration items, and giving each a unique name and version number.
2. Version control: storing items in a repository, managing versions, branches and merges, and controlling check-in and check-out.
3. Baseline management: defining and freezing approved sets of items at milestones, so that later changes are formally controlled.
4. Change control: receiving change requests, assessing their impact, getting approval from the change control board, and verifying implementation.
5. Configuration status accounting: recording and reporting the status of items and changes, i.e. what version exists, what changed, when and by whom.
6. Configuration audits: checking (functional and physical audits) that the delivered product matches the requirements and the documentation.
7. Build and release management: producing builds and releases reproducibly and deploying the correct version.
8. Planning and tools: writing the CM plan, choosing and administering tools, backup and access control, and training the team.

Risk analysis (assessment) determines how likely each identified risk is and how much damage it would cause, so that risks can be ranked and managed. The process is:

1. Risk identification: list the possible risks by checklists, brainstorming, past project experience and analysis of assumptions. Typical categories are people, requirements, technology, estimation and organization. The result is a risk register.
2. Risk analysis / estimation: for each risk, estimate the probability $P$ and the loss $L$ (cost, time or quality). Qualitative scales (high, medium, low) or numbers can be used. The risk exposure is $RE = P \times L$
3. Risk evaluation and prioritization: rank risks by exposure (for example in a probability-impact matrix), and select the top risks for action.
4. Risk planning: for the important risks decide the strategy: avoid, reduce (mitigate), transfer (insurance, contracts) or accept, and prepare contingency plans.
5. Risk monitoring and control: track risks and the effect of actions through the project, review the register regularly, and add newly arising risks.

Risk analysis may also use PERT/Monte Carlo simulation for schedule risk and decision trees for choices under uncertainty.

a. Baseline

A baseline is a formally reviewed and approved version of a configuration item (or set of items) that serves as the basis for further development, and can be changed only through formal change control. Examples are the requirements baseline (the approved SRS), the design baseline and the product baseline. Baselines give a stable reference, make it possible to return to a known good state, and let changes be tracked. In project management the performance measurement baseline is the approved scope, schedule and cost plan against which progress is compared.

b. Schedule variance

In earned value analysis, schedule variance (SV) compares the work actually done with the work planned up to the same date:

$SV = EV - PV$

where EV is the earned value (budgeted cost of work performed) and PV is the planned value (budgeted cost of work scheduled). Also $SPI = EV/PV$.

• $SV > 0$ (or $SPI>1$): ahead of schedule.
• $SV = 0$: on schedule.
• $SV < 0$: behind schedule.

Example: PV = Rs 100,000, EV = Rs 80,000, so $SV = -$Rs 20,000 and $SPI = 0.8$, meaning the project is behind schedule.

Categories of software projects

Software projects can be grouped in several ways:

1. By nature of the work
   • Information systems versus embedded systems: information systems (payroll, banking) support an organization's business functions, while embedded/real-time systems control hardware (a washing machine, a car's ECU) and have strict timing and reliability needs.
   • Objective-driven versus product-driven: an objective-driven project achieves a goal for a specific customer, while a product-driven project builds a product for a market.
2. By relationship with the customer
   • Bespoke (custom) software: written for one customer's specific requirements.
   • Off-the-shelf (COTS) software: a general product bought as is.
   • In-house versus outsourced projects.
3. By the development activity
   • New development, maintenance/enhancement (corrective, adaptive, perfective), migration/conversion, and re-engineering.
4. By size and complexity: small, medium and large projects, and the COCOMO classes organic, semi-detached and embedded.
5. By domain: web and mobile applications, scientific, data processing, AI and game software.

Why categorization is necessary

• Different types need different methods and process models (an embedded system suits a plan-driven approach, an evolving web product suits agile).
• It guides estimation, since effort models and productivity data differ between classes.
• Each category carries different risks (changing requirements in bespoke work, market risk for products), so risk planning can be targeted.
• It determines the staff skills, tools, and the type of contract and quality standards needed.
• It lets managers reuse experience from similar projects and compare against benchmarks, and set realistic schedules and budgets.

Visualization presents progress data graphically, so that deviations from the plan are seen quickly and corrective action taken. Three techniques are:

1. Gantt chart

Activities are listed on the vertical axis and time on the horizontal axis. Each activity is a bar from planned start to finish; the completed part is shaded, and a vertical today line marks the current date. Any bar whose shading ends before the today line is behind schedule. It is easy to read, and shows the schedule, overlap and progress together. It is weak in showing dependencies. It is updated at each reporting period and used in status meetings.

2. Slip chart

The horizontal axis shows the actual (current) date, and the vertical axis shows the planned dates of milestones. Each time progress is reported, the revised target date is plotted and joined to the earlier points. A line running level means the milestone is on time. A line that bends upward away from the baseline shows that the target date is slipping, and the steeper it is the worse the slippage. It makes the trend visible early, so management can act.

3. Earned value analysis (S-curve)

Three curves are plotted against time: planned value (PV, budgeted work scheduled), earned value (EV, budgeted value of work done) and actual cost (AC).

• Schedule variance $SV = EV - PV$ and $SPI = EV/PV$.
• Cost variance $CV = EV - AC$ and $CPI = EV/AC$.

If $EV < PV$ the project is behind schedule, and if $AC > EV$ it is over cost. The forecast cost at completion, $EAC = BAC/CPI$, can also be shown. It integrates cost and schedule in one picture.

(Other aids are the timeline chart showing changes of milestone dates, and the traffic-light/ball chart in which each milestone is coloured red, amber or green.)

Break Even Point (BEP)

The break even point is the level of activity (units sold, or time) at which total revenue equals total cost, so that there is neither profit nor loss:

$BEP\ (\text{units}) = \frac{\text{Fixed cost}}{\text{Selling price per unit} - \text{Variable cost per unit}}$

Above the BEP the project makes a profit; below it, a loss. For an investment, it is also the point at which cumulative cash inflows recover the initial outlay.

Internal Rate of Return (IRR)

The IRR is the discount rate $r$ at which the net present value of all the cash flows of the project is zero:

$\sum_{t=0}^{n}\frac{C_t}{(1+r)^t} = 0$

A project is acceptable if IRR is above the required rate of return (cost of capital). It is found by trial and interpolation.

Payback period

The cumulative cash flow turns positive during year 4. At the end of year 3, Rs 15,000 remains to be recovered, and year 4 brings 25,000:

$\text{Payback} = 3 + \frac{15{,}000}{25{,}000} = 3.6\text{ years}$

ROI

Total inflows $= 20000+5000+10000+25000+30000 = 90{,}000$. Net profit $= 90{,}000 - 50{,}000 = 40{,}000$. Average annual profit $= 40{,}000/5 = 8{,}000$.

$ROI = \frac{8{,}000}{50{,}000}\times 100 = 16\%\ \text{per year}$

(The total return over the five years is $40{,}000/50{,}000 = 80\%$.)

IRR for this project (for reference)

At $r = 20\%$: $\frac{20000}{1.2}+\frac{5000}{1.44}+\frac{10000}{1.728}+\frac{25000}{2.0736}+\frac{30000}{2.48832} = 16{,}667+3{,}472+5{,}787+12{,}056+12{,}056 = 50{,}039$, so NPV $\approx +39$.

At $r=21\%$: NPV $\approx 48{,}818 - 50{,}000 = -1{,}182$.

Interpolating, $IRR \approx 20 + \frac{39}{39+1182} \approx 20.03\%$, i.e. about 20%.

Resources are everything needed to carry out project activities. The main categories are:

1. Human resources (labour): the people with the needed skills, such as analysts, designers, programmers, testers and managers. Their availability, skill level and cost per time are planned.
2. Equipment (hardware): computers, servers, networking devices, test devices and workspace.
3. Materials and software tools: development tools, licences, libraries, platforms, cloud services and supplies. Software is a reusable input, while materials like consumables are used up.
4. Space and facilities: offices, labs, power, and connectivity.
5. Services and external resources: consultants, contractors, outsourced or cloud services, training.
6. Money (financial resources): the budget and cash flow.
7. Time: also treated as a limited resource in scheduling.
8. Information and knowledge: requirements, documentation, reusable components and expertise.

In resource planning another classification is used: renewable resources (people, machines, which can be reused in other periods) versus non-renewable resources (money, consumables, which are used up), and shared versus dedicated resources.

For each resource type the manager estimates the quantity needed, the period, and the cost, and then allocates them to activities, checking for over-allocation.

PERT chart

PERT (Program Evaluation and Review Technique) is a network-based technique for schedule planning when activity durations are uncertain. For each activity three estimates are made:

• $a$: optimistic time
• $m$: most likely time
• $b$: pessimistic time

$t_e = \frac{a + 4m + b}{6}, \qquad \sigma = \frac{b-a}{6}, \qquad \text{variance}=\sigma^2$

Significance

• It handles uncertainty, giving the expected project duration (sum of $t_e$ along the critical path).
• It identifies the critical path and the slack of each activity.
• It gives the probability of finishing by a given date, and shows risky activities with high variance.
• It supports scheduling, resource planning and "what-if" analysis, and gives early warning of delay.

Z-values

The variance of the project duration is the sum of the variances of activities on the critical path:

$\sigma_P = \sqrt{\sum \sigma_i^2}$

For a target date $T$ and expected duration $T_E$, the Z-value is

$Z = \frac{T - T_E}{\sigma_P}$

Z is the number of standard deviations by which the target differs from the expected duration. Using the standard normal table, the probability of completing by $T$ is $P(Z)$.

Example. Expected duration $T_E = 40$ days, $\sigma_P = 4$ days.

• Target $T=44$: $Z = 1$, probability about 84%.
• Target $T = 40$: $Z = 0$, probability 50%.
• Target $T=36$: $Z=-1$, probability about 16%.
• Target $T=48$: $Z = 2$, probability about 97.7%.

A positive Z means the target has slack (probable), a negative Z means the target is risky. Managers use it to decide a safe commitment date, such as the date with Z = 1.64 for 95% confidence.

Testing is done at several levels, each checking the system at a different scale; they correspond to the V-model.

1. Unit testing: tests a single module, function or class in isolation, usually by the developer, with white-box techniques (statement, branch and path coverage), using drivers and stubs. It finds logic and coding errors early.
2. Integration testing: tests the interfaces and interaction between modules once they are combined. Approaches are top-down (using stubs), bottom-up (using drivers), big-bang and sandwich. It finds interface and data-flow defects.
3. System testing: tests the complete integrated system against the specified requirements, in an environment like the real one. It covers functional tests and non-functional tests, such as performance, load, stress, security, usability, compatibility and recovery. It is done by an independent test team, as black-box testing.
4. Acceptance testing: done by the customer or users to decide whether to accept the system.
   • Alpha testing at the developer's site by internal users.
   • Beta testing at the user's site in the real environment.
   • User acceptance testing (UAT) and contract acceptance testing against the agreed criteria.

Regression testing is performed at every level after changes to confirm that existing functions still work.

Each level has its own test plan, test cases and entry and exit criteria, and defects found are reported and tracked until fixed.

Software Configuration Management (SCM) is the set of activities to identify, control, track and report on the changes made to software work products throughout the life cycle. Software changes continually, and without control this leads to confusion. The purposes are:

1. Identify the items: define the configuration items (code, documents, test cases, tools), and give each a unique name and version, so everyone knows what the product consists of.
2. Control changes: make sure that changes are requested, assessed for impact, approved by a change control board, and implemented in a disciplined way, preventing uncontrolled or conflicting changes.
3. Version control: keep all versions and history, so that earlier versions can be recovered and parallel development (branches, merging) is supported.
4. Baseline management: create stable, approved reference points (such as the approved SRS, the release) for later work.
5. Support teamwork: prevent developers overwriting each other's work and keep every member working on the right version.
6. Traceability and status reporting: record what changed, why, when and by whom, and give management accurate status information.
7. Auditing and quality: verify that the product matches the requirements and documents, which supports quality assurance and reduces errors.
8. Reproducible builds and releases: allow any released version to be rebuilt exactly, which helps in maintenance, fault fixing and delivery.
9. Reduce cost and risk: less rework, fewer integration problems and more reliable releases.

Motivation model: Herzberg's Two-Factor (Motivation-Hygiene) Theory

Frederick Herzberg studied what makes people satisfied and dissatisfied at work and concluded that satisfaction and dissatisfaction are not opposite ends of one scale. They are driven by two different sets of factors.

1. Hygiene factors (maintenance factors)

These prevent dissatisfaction but do not by themselves motivate. If they are poor, people become unhappy. If they are good, people are only "not dissatisfied".

• Salary and benefits
• Company policy and administration
• Working conditions and equipment
• Job security
• Quality of supervision
• Relationships with colleagues and managers

2. Motivators (satisfiers)

These create real satisfaction and push people to perform better.

• Achievement
• Recognition
• The work itself (interesting, challenging)
• Responsibility
• Advancement and promotion
• Personal growth

Key ideas

• Removing dissatisfaction (better pay, better office) does not produce motivation. It only brings people to a neutral state.
• Motivation comes from making the job itself meaningful, through job enrichment, such as giving more responsibility, autonomy and chances to grow.

Application in software projects

• Hygiene: give developers proper machines, fair pay, a clear company policy and a good working environment so that they are not unhappy.
• Motivators: assign challenging modules, let developers take ownership of a component, recognise good work publicly, give training and a clear career path, and let them take part in design decisions.

A project manager should therefore first fix the hygiene factors and then actively use motivators, so that team members stay productive and committed to the project.

Definition of risk

A risk is an uncertain event or condition that, if it occurs, has a negative effect on the project objectives such as cost, schedule, quality or scope. It is described by two properties:

• Probability (likelihood) that the event occurs.
• Impact (loss) if it occurs.

$\text{Risk exposure} = \text{Probability of loss} \times \text{Size of loss}$

For example, if there is a 20% chance that a key developer leaves and the loss would be Rs 500,000, the risk exposure is $0.2 \times 500000 =$ Rs 100,000.

Examples of software project risks: requirement changes, staff turnover, unrealistic schedule, technology failure, cost overrun, poor estimation.

How risk is handled (risk management)

Risk management is a structured process with the following steps.

1. Risk identification

List all possible risks using checklists, brainstorming, expert interviews (Delphi technique), past project data and risk taxonomies (project, technical, business risks).

2. Risk analysis and assessment

• Qualitative: rate probability and impact as high, medium or low and build a probability-impact matrix.
• Quantitative: compute risk exposure for each risk and rank them.

3. Risk prioritisation

Order the risks by exposure so that the top few risks get attention first. This is the Pareto idea: a small number of risks cause most of the potential loss.

4. Risk planning (response strategies)

• Avoidance: change the plan so that the risk cannot occur, such as dropping a risky feature or using proven technology.
• Mitigation (reduction): lower the probability or impact, for example with training, prototyping, or cross-training staff.
• Transfer: shift the risk to a third party through insurance, outsourcing or fixed-price contracts.
• Acceptance: do nothing but prepare a contingency plan (reserve time and money).

5. Risk monitoring and control

Track identified risks, watch for trigger events, review the risk register regularly, update it with new risks, and apply the contingency plan when a risk materialises.

The result is documented in a risk register (risk, probability, impact, exposure, owner, response, status), which is reviewed throughout the project life cycle.

Strategic and technical assessment are part of the feasibility study and project evaluation done before a project is approved. Their purpose is to decide whether the project is worth starting.

Strategic assessment

It checks whether the project fits the long-term goals and strategy of the organisation. It is usually done for a programme or a portfolio of projects, and looks at:

• Alignment of the project with the organisation's objectives and business plan.
• Need for the project, expected benefits and the contribution to the organisation's position in the market.
• Priority of the project compared with other candidate projects.
• Information systems strategy, so the new system fits with existing systems.

Importance of strategic assessment

• Ensures resources are spent only on projects that support the business strategy.
• Avoids isolated systems that do not integrate with other systems.
• Helps to rank competing projects and use limited funds wisely.
• Gives top management a clear justification and keeps their support.

Technical assessment

It evaluates whether the proposed system can be built and operated with the available or obtainable technology and resources. It looks at:

• Functionality required against the hardware and software available.
• Suitability of the platform, tools, languages and architecture.
• Technical skills of the team, and the need for training or hiring.
• Performance, security, reliability and scalability requirements.
• Integration with existing systems and the limits of the existing infrastructure.
• Technical risks and the cost of the technical solution.

Importance of technical assessment

• Confirms the project is technically achievable before heavy investment.
• Identifies the technology and skill gaps early, reducing later failure.
• Gives realistic input for cost, time and risk estimation.
• Helps in choosing the best technical alternative.

Overall importance

Together, the two assessments reduce the chance of undertaking a project that is either not wanted by the business or not feasible technically. They support the go/no-go decision, improve the accuracy of the business case (which is then followed by cost-benefit analysis) and increase the project's chance of success.

Why software quality assurance (SQA) is carried out

Software quality assurance is a planned set of activities applied throughout the software process to ensure that the products and processes conform to the specified requirements and standards. It is carried out because:

• Defects found late are much more costly to fix than defects found early.
• It gives confidence that the software meets customer requirements and standards.
• It improves the reliability, maintainability and usability of the product.
• It reduces rework, delays and cost overruns.
• It checks that the development process is followed correctly and helps to improve it.
• It reduces the risk of failure in operation, especially for critical systems.
• It increases customer satisfaction and the reputation of the organisation.

QA organisation structure

The QA function should be organised so that it can report problems independently of the development pressure. A common structure is:

1. Top management / Quality council: sets the quality policy and provides resources.
2. QA manager (head of quality): leads the QA department, reports directly to senior management and not to the project manager, so that quality problems are not hidden.
3. QA group (SQA team): an independent group that plans QA, prepares standards and procedures, audits processes and work products, and reviews compliance.
4. Project-level QA / quality engineers: assigned to each project to take part in reviews, inspections and testing, and to report non-conformances.
5. Testing team: carries out verification and validation (unit, integration, system, acceptance testing).
6. Software engineers and project team: responsible for building quality in, performing peer reviews and fixing defects.
7. Configuration management and process improvement group: controls changes and baselines, and maintains the process data for improvement (such as the Software Engineering Process Group).

Main activities of the QA organisation

• Prepare the SQA plan and quality standards.
• Review and audit the process and work products.
• Conduct formal technical reviews, walkthroughs and inspections.
• Make sure deviations are documented and handled, and report to management.
• Collect and analyse defect and quality metrics.

Key principle

The QA group should be independent of the development team, with a reporting line to senior management, so that it can act objectively. In small organisations the QA role may be combined with other roles but still done by people not responsible for the work being checked.

(a) Critical path

The critical path is the longest path through the project activity network (from start to finish). It determines the shortest possible time in which the whole project can be completed. Activities on this path have zero total float (slack), so any delay in them delays the whole project.

Critical Path Method (CPM) steps:

1. List the activities and their durations, and draw the network showing dependencies.
2. Forward pass: compute the earliest start (ES) and earliest finish (EF).

$EF = ES + \text{duration}$

3. Backward pass: compute the latest finish (LF) and latest start (LS).

$LS = LF - \text{duration}$

4. Compute the float:

$\text{Float} = LS - ES = LF - EF$

5. Activities with float $= 0$ form the critical path.

Example: A (3 days) followed by B (4 days) and C (2 days) in parallel, then D (2 days) after both. Path A-B-D takes $3+4+2 = 9$ days and A-C-D takes $3+2+2 = 7$ days. The critical path is A-B-D with 9 days, and C has a float of 2 days.

Uses: it shows which activities need close management, helps to decide where to add resources for crashing the schedule, and gives the project duration. There can be more than one critical path, and the critical path may change as the project progresses.

(b) Capability Maturity Model (CMM)

The Capability Maturity Model was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University. It is a framework used to assess and improve the maturity of an organisation's software development process. Its successor is CMMI (Capability Maturity Model Integration).

It defines five maturity levels:

1. Initial: processes are ad hoc and chaotic; success depends on individual effort.
2. Repeatable (Managed): basic project management is established (requirements management, planning, tracking, configuration management, QA), so earlier successes can be repeated.
3. Defined: the process is documented, standardised and integrated across the organisation, with training and peer reviews.
4. Managed (Quantitatively managed): detailed process and product metrics are collected and used to control quality and performance.
5. Optimising: continuous process improvement is built in, based on quantitative feedback and new ideas and technologies; defect prevention is practised.

Each level (except level 1) has Key Process Areas (KPAs) that must be satisfied to reach the level.

Benefits: better predictability of cost and schedule, higher quality, fewer defects, a clear path for process improvement, and a recognised way for customers to judge a supplier's capability.