Software Project Management

Incremental delivery

In the incremental delivery approach the system is developed and delivered in a series of increments (small working releases) instead of one big delivery at the end. The requirements and overall architecture are defined first, and the system is divided into increments, each adding a useful part of the functionality. The highest-priority or most-needed features are built first. Each increment is designed, built, tested and delivered to the user, and later increments build on earlier ones.

Requirements and architecture
        |
        v
+-------------+   +-------------+   +-------------+
| Increment 1 |-->| Increment 2 |-->| Increment 3 |--> ... final system
| design      |   | design      |   | design      |
| build       |   | build       |   | build       |
| test        |   | test        |   | test        |
| deliver     |   | deliver     |   | deliver     |
+-------------+   +-------------+   +-------------+
  Release 1         Release 2         Release 3

Each increment may be developed in a waterfall-like mini-cycle; the user gets feedback after every delivery, which is used to adjust the next increments.

Advantages

• Users get working software early and can start using it.
• Early increments act as prototypes, giving feedback on requirements.
• Lower risk of total failure; problems are found early in small parts.
• Highest-priority features are tested the most because they are delivered first.
• Changing requirements are easier to accommodate.
• Better cash flow, since benefits start early.

Disadvantages

• Needs good planning and an overall architecture defined up front; poor design makes integration hard.
• Increments may be difficult to divide, because features are often interdependent.
• Later increments may require rework of earlier ones, increasing cost ("software decay").
• Total cost may be higher than a single delivery, and management/documentation overhead increases.
• Users may be satisfied with early increments and lose interest in the rest.

Cost estimation

Cost estimation is the process of predicting the effort, time and money needed to develop a software system. Since software cost is mainly staff effort, estimates are made as effort in person-months, then converted to schedule and cost (effort multiplied by salary rates plus other costs). Accurate estimates are needed for budgeting, bidding, planning and monitoring.

COCOMO II

COCOMO II (Constructive Cost Model II, by Barry Boehm) is an algorithmic model with three submodels: Application Composition (early prototyping), Early Design and Post-Architecture (used once the architecture is available; most detailed). Size is measured in KSLOC (or function points/object points).

The Post-Architecture effort equation is

$PM = A \times Size^{E} \times \prod_{i=1}^{17} EM_i$

where $A = 2.94$, $Size$ is in KSLOC, and the exponent is

$E = B + 0.01 \sum_{j=1}^{5} SF_j,\quad B = 0.91$

with five scale factors (PREC, FLEX, RESL, TEAM, PMAT). Schedule is $TDEV = 3.67 \times PM^{F}$.

Post-architecture effort multipliers (17)

• Product factors: RELY (required reliability), DATA (database size), CPLX (product complexity), RUSE (required reusability), DOCU (documentation match to life-cycle needs).
• Platform factors: TIME (execution time constraint), STOR (main storage constraint), PVOL (platform volatility).
• Personnel factors: ACAP (analyst capability), PCAP (programmer capability), PCON (personnel continuity), APEX (applications experience), PLEX (platform experience), LTEX (language and tool experience).
• Project factors: TOOL (use of software tools), SITE (multisite development), SCED (required development schedule).

Each is rated from Very Low to Extra High with a numeric value; the nominal rating is 1.0. Ratings above nominal for undesirable attributes (e.g. high complexity) multiply effort by more than 1, and good ratings (e.g. high analyst capability) by less than 1.

Advantages

• Well documented, widely used and calibrated on many projects.
• Takes into account modern practices (reuse, COTS, iterative development).
• Detailed cost drivers capture product, platform, personnel and project effects.
• Can be calibrated to an organisation's own data.
• Gives repeatable estimates and supports what-if analysis.

Activity-on-arrow (AOA) diagram

In an AOA network, arrows are activities and circles are events (nodes). Activities: A (2), B (3, after A), C (4, after A), D (5, after B and C), E (2, after D).

                    B (3)
              +---------------+
              |               v
(1) --A(2)--> (2) --C(4)--> (3) --D(5)--> (4) --E(2)--> (5)

Event 3 is reached by both B and C. Since two activities cannot share the same start and end events, B is drawn from event 2 to a separate event 2' and joined to event 3 by a dummy activity of zero duration (or equivalently, C is routed through the dummy). The timing is unchanged by the dummy:

• Event 1: start. Event 2: after A. Event 3: after B and C. Event 4: after D. Event 5: finish, after E.

Forward pass (earliest event times)

$ES_1 = 0,\quad ES_2 = 2,\quad ES_3 = \max(2+3,\ 2+4) = 6,\quad ES_4 = 6+5 = 11$

$ES_5 = 11 + 2 = 13$

Backward pass (latest event times)

$LS_5 = 13,\quad LS_4 = 11,\quad LS_3 = 6,\quad LS_2 = \min(6-3,\ 6-4) = 2,\quad LS_1 = 0$

Float

Critical path: the activities with zero float are A, C, D and E:

$A \rightarrow C \rightarrow D \rightarrow E,\quad 2 + 4 + 5 + 2 = 13 \text{ weeks}$

The project duration is 13 weeks. The path through B (A, B, D, E) takes 12 weeks, so B has 1 week of float.

Selecting the right person for a job (recruitment and selection) is done in a structured sequence:

1. Create a job specification: define the role, the tasks, the responsibilities, and the qualifications, skills, experience, and personal attributes required. Separate essential from desirable requirements.
2. Create a job holder profile: translate the specification into the characteristics of the ideal candidate (education, experience, skills, communication, teamwork, and so on).
3. Obtain candidates (recruit): advertise internally or externally, use agencies, referrals and online job portals, and collect application forms or CVs.
4. Examine the CVs and shortlist: compare applications against the profile and eliminate unsuitable candidates.
5. Assess candidates: interviews (structured, behavioural), technical tests and exercises, aptitude and psychological tests, presentations, and group tasks.
6. Check references: confirm qualifications, past performance and character with previous employers.
7. Decide and offer: rank the candidates against the profile, make the offer and agree terms.

Good practice includes using more than one selection method, involving more than one interviewer, asking the same questions of every candidate, and considering fit with the team and the likelihood that the person will stay. In software projects, the specific technical skills (language, tools, domain), previous project experience and ability to work in a team are especially important. A well-chosen person reduces training time, errors and staff turnover, and improves project success.

A contract is a legally binding agreement between two or more parties in which one party (the supplier/contractor) agrees to provide goods or services and the other (the customer) agrees to pay for them. It states scope, price, time, quality, responsibilities, and remedies if either party fails.

Contract management process

1. Requirements definition: the customer defines what is needed (scope, quality, deadline, budget).
2. Tendering/supplier selection: requests for proposals or invitations to tender are issued, bids are evaluated, and a supplier is chosen.
3. Contract negotiation and signing: terms such as price, payment schedule, delivery dates, acceptance criteria, penalties, IPR and change-control are agreed in writing.
4. Contract execution and monitoring: delivery is tracked against milestones; progress reports, reviews and quality checks are carried out.
5. Change control: any change to scope, cost or time is formally requested, assessed and approved by amending the contract.
6. Acceptance and payment: deliverables are tested against acceptance criteria and payments are released.
7. Closure: final delivery, handover, resolving disputes or claims, and recording lessons learned.

Modern project management practices treat a project as a temporary endeavour with a defined goal, managed through planned and controlled activities. Typical modern practices are:

• Using lifecycle models matched to the project (waterfall for stable requirements, iterative/agile for changing ones such as Scrum and XP).
• Breaking work into a work breakdown structure and scheduling with CPM/PERT and Gantt charts.
• Early and continuous risk management and stakeholder communication.
• Cross-functional, self-organising teams with short iterations, regular reviews and retrospectives.
• Continuous integration, automated testing and configuration management.
• Tracking progress with tools (Jira, MS Project), earned value and dashboards.
• Process improvement based on standards such as PMBOK, PRINCE2, CMMI.

Importance of project management

• Clear objectives, scope and deliverables.
• Better estimation of cost, effort and time, and control against the plan.
• Efficient use of people and resources.
• Early identification and reduction of risks.
• Better quality and customer satisfaction.
• Better communication and coordination among stakeholders.
• Reduced chance of overruns and project failure.

Two methods to visualize project progress are the Gantt chart and the slip chart.

1. Gantt chart. A bar chart in which each activity is a horizontal bar on a calendar axis. The bar length shows planned duration. Progress is shown by shading the part of the bar completed, and a vertical "today" line shows the current date. Activities whose shading ends left of the today line are behind schedule, and those ending to the right are ahead. It also shows milestones and dependencies.

2. Slip chart. A chart that plots the planned completion dates of activities against the current date. For each reporting date, a line joins the expected dates of the activities. A line that bends away from the vertical (towards the right) shows that activities are slipping. The steeper the slip, the worse the delay. It gives an easy overview of the trend of delays, which a Gantt chart does not show.

(A timeline chart and the ball chart are other options.)

Coordination dependencies are relationships between activities or units that must be managed so that work fits together. They are classified as follows.

1. Shared resources: several tasks or teams need the same resource (people, machine, budget, test environment). Coordination uses scheduling and allocation.
2. Producer/consumer (prerequisite) dependencies: one activity produces something another needs, e.g. design before coding. Managed by sequencing and handover procedures.
3. Simultaneity constraints: activities must happen at the same time or not at the same time, e.g. a meeting needing all members, or integration at a fixed time.
4. Task/subtask dependencies: a larger goal is broken into subtasks and the parts must be combined correctly.
5. Fit dependencies: separately produced components must fit together, e.g. interfaces between modules, which is managed through standards and integration testing.
6. Accessibility/usability dependencies: the output of one activity must be usable by the next one (format, documentation, training).

Such dependencies are handled through planning, meetings, communication channels, shared standards and tools.

Break Even Point (BEP) is the volume of sales (or the time) at which total revenue equals total cost, so there is neither profit nor loss. For a product with fixed cost $F$, price per unit $P$ and variable cost per unit $V$:

$BEP = \frac{F}{P - V}$

Significance: it shows the minimum sales needed to avoid loss, helps in pricing and costing decisions, shows the risk (margin of safety) of a project, and helps decide whether a project or product is worth starting. For a software project it shows when cumulative benefits cover the development cost.

Return on Investment (ROI) measures the profitability of an investment:

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

Significance: it gives a simple percentage measure to compare projects, helps management select the project with the best return, justifies the investment against the cost of capital, and can be used to track performance after completion.

Both are used in the financial evaluation of projects, BEP for risk and timing and ROI for profitability.

Risk can be handled using the following approaches.

1. Risk avoidance: change the plan so the risk cannot occur, e.g. drop a risky feature, use proven technology, or not bid for the project.
2. Risk reduction (mitigation): take steps to lower the probability or impact, e.g. prototyping, training, extra testing, adding experienced staff.
3. Risk transfer: shift the risk to another party, e.g. insurance, fixed-price contract, outsourcing.
4. Risk acceptance: accept the risk and do nothing in advance because its impact is small or its cost to prevent is higher than the loss.
5. Contingency planning: prepare a fallback plan and reserves (time and money) to be used if the risk happens.
6. Risk monitoring: continually watch risk indicators and review the risk register so that actions can be started early.

The best approach is chosen according to the risk exposure (probability multiplied by impact) and the cost of the action.

Techniques for enhancing software quality are as follows.

• Reviews and inspections: walkthroughs, peer reviews and Fagan inspections find defects early in requirements, design and code.
• Testing: unit, integration, system and acceptance testing, with test automation and regression testing.
• Quality standards and process improvement: ISO 9001, CMMI and Six Sigma give a defined, repeatable process.
• Quality assurance and quality control: audits, checklists and metrics monitor that the process and product meet standards.
• Configuration and change management: version control prevents uncontrolled changes.
• Software reuse and component-based development: use of already tested components.
• Modern practices: continuous integration, pair programming, test-driven development and static code analysis.
• Defect tracking and metrics: defect density and similar measures guide improvement.
• Training and capable staff, and clear requirements agreed with users.

(a) Scrum

Scrum is an agile framework for iterative development of products. Work is done in fixed-length iterations of 1 to 4 weeks called sprints.

• Roles: Product Owner (manages the product backlog and priorities), Scrum Master (facilitates, removes obstacles), Development Team (self-organising, builds the increment).
• Artifacts: product backlog, sprint backlog, product increment.
• Events: sprint planning, daily scrum (15 minutes), sprint review, and sprint retrospective.

At the end of each sprint a potentially shippable increment is delivered, and feedback is used to adapt the next sprint. Scrum suits changing requirements.

(b) Resource schedule

A resource schedule shows when each resource (people, equipment) is needed in the project, built from the activity plan and the resource requirements of each activity. It is normally shown as a resource-allocation chart or a resource histogram, which plots the number of resources needed per time period. It is used to detect over-allocation or under-use and to level the resources (for example by delaying activities that have float), so that the demand on resources is smooth and realistic.

Net Present Value (NPV) is the sum of the discounted future cash flows of a project minus the initial investment:

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

where $C_t$ is the net cash flow in year $t$ and $r$ is the discount rate. A project with positive NPV adds value and is acceptable; when choosing between projects, the one with the higher NPV is preferred. NPV accounts for the time value of money, which simple payback and ROI ignore.

Example. Discount rate 10%, investment Rs 100,000 each.

$NPV_A = 122,765 - 100,000 =$ Rs 22,765 and $NPV_B = 110,143 - 100,000 =$ Rs 10,143. Both are positive, but A has the higher NPV (B returns cash earlier but the total is smaller), so A is chosen.

ROI calculation. Investment = Rs 5,00,000; total benefit = 5 x Rs 2,00,000 = Rs 10,00,000.

$ROI = \frac{\text{Net profit}}{\text{Investment}} \times 100 = \frac{10,00,000-5,00,000}{5,00,000}\times 100 = 100\%$

Average annual ROI = $100/5 = 20\%$ per year.

Why effort estimation is needed

• To prepare the project budget, price a bid and decide whether the project is financially worthwhile.
• To plan the schedule, decide how many staff are needed and when.
• To allocate resources and negotiate realistic deadlines with the customer.
• To monitor progress: actual effort can be compared with the estimate and corrective action taken.
• To assess risk: poor estimates (too low) cause overruns, poor quality and demotivated staff; too high estimates lose business or waste resources.

COCOMO (Constructive Cost Model) - Basic model

Developed by Barry Boehm, COCOMO is an algorithmic model that estimates effort from size in thousands of delivered source instructions (KDSI/KLOC):

$Effort\ (E) = a\,(KLOC)^b \ \text{person-months},\qquad Time\ (D) = c\,E^d \ \text{months}$

Example: an organic project of 32 KLOC gives $E = 2.4\times 32^{1.05} \approx 2.4\times 38.0 \approx 91$ person-months, and $D = 2.5\times 91^{0.38}\approx 14$ months. Staff required is $E/D \approx 6.5$ persons.

Intermediate COCOMO multiplies the nominal effort by an effort adjustment factor (EAF) built from 15 cost drivers (product, hardware, personnel and project attributes), while detailed COCOMO applies the drivers phase by phase.

Rapid Application Development (RAD) is an incremental software process model that emphasizes a very short development cycle (typically 60-90 days) using component-based construction, prototyping and a high degree of user involvement. It is suitable when requirements are well understood and the project scope can be modularized.

Phases of RAD

1. Business modelling: the information flow among business functions is modelled.
2. Data modelling: information is refined into data objects and their relationships.
3. Process modelling: data objects are transformed into processing functions (add, modify, delete, retrieve).
4. Application generation: fourth-generation tools and reusable components are used to build the system; prototypes are created.
5. Testing and turnover: since components are reused, many are already tested; only new components and interfaces need testing.

Several teams work in parallel, each on a different module, and the modules are integrated at the end.

Advantages

• Very fast delivery and reduced development time.
• Reuse of components lowers effort and cost.
• Continuous user feedback through prototypes means the product meets user needs.
• Risks are identified and handled early; changes are easy to accommodate.

Disadvantages

• Needs a large number of skilled developers to form multiple teams.
• Requires strong commitment from developers and customers to rapid-fire activities.
• Not suitable for systems that cannot be modularized, or with high technical risk (e.g. heavy use of new technology).
• Not appropriate for very large projects; may sacrifice performance and documentation quality.
• Needs heavy user participation, which may not always be available.

Software projects are often late, over budget and of poor quality, so management is essential. Software project management is important because:

• Software is complex and intangible: progress cannot be seen physically, so planning and tracking are required to know the true status.
• Meets time and cost targets: estimation, scheduling and monitoring keep the project within the budget and deadline.
• Manages scarce resources: people, tools and hardware are allocated efficiently.
• Controls risks: risks (staff turnover, changing requirements, technology) are identified and handled early.
• Manages change: requirements usually change; change control keeps scope under control.
• Ensures quality: quality standards, reviews and testing are planned.
• Improves communication and customer satisfaction: stakeholders are kept informed and the delivered product matches their needs.
• Most project failures (as shown by many surveys) arise from poor management rather than purely technical causes.

Cash flow forecasting estimates the amount and timing of expected income (inflows) and expenditure (outflows) over the life of the project, so that the project's financial viability can be judged.

Steps

1. Estimate costs: development costs (staff, hardware, software, training), implementation costs and later operating, maintenance and support costs, each by the year or period in which they occur.
2. Estimate benefits/income: revenue, cost savings, increased productivity, avoided costs, each by period.
3. Compute net cash flow for each period: inflow minus outflow. Negative values are common in early years because of development spending.
4. Record cumulative cash flow to see when the project becomes cash-positive.
5. Evaluate using techniques such as payback period, ROI, NPV and IRR.

Example

The forecast is uncertain because it relies on estimates, so sensitivity analysis and periodic revision are used; the forecast also helps in arranging finance to avoid a shortage of funds.

A resource histogram is a bar chart showing the amount of a resource (e.g. number of programmers) required in each time period of the schedule.

Resource histogram equalization (levelling) is the process of rescheduling activities - using their float (slack) - so that the resource demand is as smooth as possible, avoiding sharp peaks and troughs. Critical-path activities are not moved; non-critical activities are shifted within their float.

Why it is carried out

• Avoids the situation where a resource is over-allocated in one period (impossible to supply) and idle in another.
• Reduces the costs of hiring and releasing staff at short notice, and avoids paying idle staff.
• Keeps resource use within availability limits.
• Gives a stable, efficient and more predictable workload, improving productivity and morale.
• Can also be used to resolve resource conflicts when the same person is needed for parallel activities.

Risk assessment identifies the hazards that may affect the project and judges how serious each is. It is carried out in three steps.

1. Risk identification: list possible risks using checklists, brainstorming, past project experience and risk taxonomies.
2. Risk analysis and prioritization: for each risk estimate the likelihood (probability) and the impact (cost of the damage), then compute the risk exposure:

$RE = \text{Probability} \times \text{Impact}$

3. Rank risks by exposure and plan action (avoid, reduce, transfer, accept) for the highest ones. Risks are recorded in a risk register.

Example

Requirements change has the highest exposure (Rs 75,000), so it gets the highest priority, for example by prototyping and a formal change-control procedure.

In a time and materials (T&M) contract the customer pays for the actual time spent by the supplier's staff at agreed rates (e.g. per hour/day) plus the cost of materials, rather than a fixed price for the deliverable.

When it is beneficial

• When requirements are unclear or likely to change, so the scope cannot be defined precisely in advance.
• When the size of the job is difficult to estimate, or exploratory work/research is involved.
• When the customer wants flexibility and close involvement, with the freedom to stop at any time.
• It avoids the supplier padding a fixed price to cover risk, and avoids disputes over changes.

Example: a bank wants a mobile app with new features to be defined as it sees user feedback. Effort cannot be fixed in advance, so it hires a developer team at Rs 5,000 per person-day. If the team spends 120 person-days, the charge is Rs 600,000 plus any purchased materials (e.g. licences). Because the customer bears the cost risk, it must monitor the work closely; the supplier is protected against under-estimation.

A timeline chart plots activities as horizontal bars against the time axis, and records the actual start/finish of each activity alongside planned dates, so schedule changes can be seen over time. It is used for monitoring and controlling as follows:

• Shows progress at a glance: planned versus actual start and completion of each task is displayed, so late activities are immediately visible.
• Records the history of slippage: the way target dates have moved at each review is retained, showing whether delays are growing or being recovered.
• Early warning: allows the manager to detect delay on critical activities and take corrective action (add resources, reschedule, cut scope).
• Communication: a simple, visual tool for reporting status to the team and stakeholders.
• Supports replanning and control: revised plans can be compared against the baseline, and the effect of delays on later dependent activities is seen.
• Helps judge the reliability of estimates for future planning.

Software quality can be enhanced by building quality into the process and the product:

• Quality management/standards: adopt a quality management system (e.g. ISO 9001, CMMI) with defined processes and a quality plan.
• Clear requirements: careful requirements elicitation and validation, with prototypes and customer reviews.
• Reviews and inspections: walkthroughs, Fagan inspections and peer reviews of requirements, design and code detect defects early when they are cheap to fix.
• Testing: unit, integration, system and acceptance testing, with test automation and regression testing.
• Good design and coding practices: modular design, coding standards, reuse of tested components, and pair programming.
• Configuration and change management: version control and controlled changes.
• Measurement and metrics: track defect density, reliability and other metrics, and use them for process improvement.
• Skilled and motivated staff, and training, together with continuous process improvement based on lessons learnt.

Leadership style describes how a manager influences and directs the team. Common styles are:

• Autocratic (authoritarian): the leader makes decisions alone and tells people what to do. Quick, useful in crises or with inexperienced staff, but demotivating and stifles creativity.
• Democratic (participative): decisions are made after consulting the team. Raises morale, commitment and quality of ideas, but is slower.
• Laissez-faire (free rein): the leader gives little direction and the team decides for itself. Works with highly skilled, self-motivated professionals but can lead to lack of direction.
• Task-oriented vs people-oriented: the former focuses on completing work and schedules; the latter focuses on relationships, support and team needs.
• Transformational: inspires the team with vision and encourages innovation and growth.
• Transactional: relies on rewards and penalties linked to achieving agreed targets.

The best style depends on the situation (Fiedler's contingency theory, Hersey-Blanchard): team experience, task urgency and project type.

(a) Product-based approach

In the product-based approach, development is planned around the products (deliverables) that the project must produce, rather than around activities. A product breakdown structure (PBS) is drawn showing all products (e.g. requirements document, design, code modules, test reports, user manual), and a product flow diagram shows the order in which they are made. From these, the activities needed to produce each product and the work breakdown structure are derived. It is the approach used in PRINCE2. It makes the scope clear, avoids missing deliverables and links quality checking to each product.

(b) Project planning

Project planning is the process of defining how a project will be carried out to achieve its objectives within time, cost and quality limits. It includes defining scope and objectives, identifying activities (WBS), estimating effort and cost, sequencing activities, scheduling (Gantt/PERT/CPM), allocating resources, planning risks, quality and communication, and producing the project plan against which progress is monitored. Planning is iterative and is revised as more information becomes available.

Why estimation is carried out

• To decide whether the project is feasible and to prepare the budget and the bid price.
• To plan the schedule and staffing, and to allocate resources.
• To monitor progress and control cost by comparing actuals with estimates.
• To manage risk, since poor estimates cause over-runs and quality problems.

COCOMO II is the revised version of COCOMO for modern development (reuse, rapid development, component-based). It has three stage models, used progressively as more is known about the project:

1. Application Composition model: used in the early prototyping stage, when user interfaces, components and tools are used for rapid development. Size is measured in object points (screens, reports, 3GL modules); effort is $PM = \frac{NOP}{PROD}$ where $NOP = OP\times\frac{100-\%reuse}{100}$ (new object points) and $PROD$ is productivity based on developer experience and tool maturity.

2. Early Design model: used once requirements are stable and a basic architecture is being chosen. Size is estimated in function points converted to KLOC. Effort: $PM = A \times Size^{B}\times M$ with $A = 2.94$, $B$ derived from five scale factors, and $M$ a product of seven multipliers (product reliability and complexity, required reuse, platform difficulty, personnel capability, personnel experience, schedule, support facilities).

3. Post-Architecture model: used when the system architecture is designed and the most accurate estimates are needed. It uses the same formula as the early design model but with 17 cost drivers (product, platform, personnel, project attributes) as multipliers and size in KLOC (adjusted for reuse and requirements volatility). The exponent $B = 0.91 + 0.01\sum SF_i$ uses five scale factors (precedentedness, development flexibility, architecture/risk resolution, team cohesion, process maturity).

The schedule is estimated as $TDEV = 3.67\times PM^{\,0.28+0.2(B-0.91)}$.

Risk is an uncertain event that, if it occurs, has a negative effect on the project. Risks can be categorized as follows.

By source (Boehm's / project categories)

• Project risks: threaten the schedule and resources - budget, staffing, turnover of key staff, customer involvement, management changes, and unrealistic schedules.
• Technical risks: threaten quality and timeliness - design, implementation, interfacing, verification and maintenance problems; new, unproven or complex technology; poor specifications.
• Business risks: threaten viability of the software - market risk (building a product nobody wants), strategic risk (no longer fits company strategy), sales risk, management risk (loss of support), and budget risk.

By knowledge (Pressman)

• Known risks: discovered after careful evaluation of the project plan and environment (e.g. unrealistic delivery date).
• Predictable risks: extrapolated from past experience (e.g. staff turnover).
• Unpredictable risks: very difficult to identify in advance.

By generic/product-specific

• Generic risks: common to all projects (e.g. changing requirements).
• Product-specific risks: exist only with a particular product, technology or team.

By area (Hughes and Cotterell)

• Application/requirements risks, development environment, staff, estimation, and external (legal, supplier) risks.

Categorizing risks helps use checklists for identification, and assign owners and mitigation actions to each.

Atern process model. Atern is the later name for DSDM (Dynamic Systems Development Method), an agile framework that fixes time and cost (with resources) and varies the features delivered. Work is delivered in timeboxes and prioritized with MoSCoW (Must have, Should have, Could have, Won't have this time).

Phases of the lifecycle

1. Pre-project: the project is identified and funding ensured.
2. Feasibility: assesses whether the project is technically and economically viable.
3. Foundations: establishes the business case, high-level requirements and architecture, and delivery approach.
4. Exploration: iterative refinement of requirements and prototypes with users.
5. Engineering: development and technical solution built and tested in timeboxes.
6. Deployment: the solution is released into operation.
7. Post-project: benefits are reviewed.

Development within timeboxes follows the cycle of investigate, refine and consolidate.

Principles of Atern/DSDM

1. Focus on the business need.
2. Deliver on time (timeboxing).
3. Collaborate - involve stakeholders actively.
4. Never compromise quality.
5. Build incrementally from firm foundations.
6. Develop iteratively, with feedback.
7. Communicate continuously and clearly.
8. Demonstrate control.

In short: a plan says what to do in a project, a method says how to do a task, and a methodology is the system of methods and principles used in a field.

An iterative process develops a system through repeated cycles. The product is built in a series of passes, each pass producing a refined or extended version, with feedback from the previous cycle used to improve the next (e.g. spiral, RUP, prototyping). Each iteration includes analysis, design, coding and testing.

Managing iterative processes

• Timeboxing: fix the duration of each iteration (e.g. 2-4 weeks) and fit the work into it, varying scope rather than time.
• Plan at two levels: an overall plan with iteration goals, and a detailed plan for the current iteration, revised after each one.
• Prioritize requirements/risks: high-risk or high-value items go in the early iterations.
• Set clear objectives and exit criteria for every iteration and review them at the end.
• Control change: use configuration management and baselining for each iteration's results.
• Measure progress: use velocity, burn-down charts and the number of completed requirements.
• Involve users: gather feedback after each iteration and adapt the next one.
• Avoid endless iteration: the number of iterations is limited by planning and the stop criteria.

Estimation models

• Algorithmic/parametric models: COCOMO, COCOMO II, function points, use-case points.
• Expert judgement (including Delphi technique).
• Estimation by analogy.
• Top-down and bottom-up estimation.
• Parkinson's law and price-to-win.
• Machine-learning/regression-based models.

Estimation by analogy

The estimator finds one or more completed (source) projects similar to the new (target) project, takes their actual effort, and adjusts it for differences in size and characteristics.

Steps: (1) characterize the new project (size, technology, complexity, team); (2) find similar past projects in a database; (3) take their actual effort; (4) scale for differences; (5) adjust with judgement.

Example. A past project for a hospital system of 40 screens took 80 person-months. The new project, a clinic system of 30 screens with similar technology, is estimated as

$Effort = 80\times\frac{30}{40} = 60 \text{ person-months}$

If the new team is less experienced, the estimate may be increased by about 10%, giving about 66 person-months. The method is fast and uses real data, but depends on the availability and relevance of past projects.

Creating a project schedule is done in stages.

1. Define the activities: use the work breakdown structure (WBS) to list all tasks needed to produce the deliverables.
2. Estimate the duration and effort of each activity.
3. Identify dependencies and sequence the activities: determine which tasks must finish before others start (finish-to-start, start-to-start, etc.) and draw the network diagram (PERT/CPM, precedence network).
4. Perform forward and backward pass: compute earliest and latest start/finish times, float (slack), and the critical path.
5. Allocate resources: assign people and equipment to activities, check conflicts and over-allocation.
6. Resource levelling / smoothing: adjust using float to even out resource use (resource histograms); re-calculate the schedule.
7. Prepare the schedule: present as a Gantt/bar chart with milestones; fix the baseline.
8. Review, publish and update: get approval and revise as progress is monitored.

A resource histogram shows how many units of a resource are needed in each period. Equalization (levelling) is necessary because an uneven histogram has problems:

• Peaks may exceed the number of available staff, so the schedule is not feasible.
• Troughs mean idle staff paid for no work.
• Frequent hiring and releasing of staff is expensive and disrupts the team.

By moving non-critical activities within their float, the demand is smoothed without delaying the project end date.

Example. Activities A (critical), B and C (both non-critical, 3 weeks each, 1 float of 3 weeks). Each needs 2 programmers. Total available is 4.

Before levelling: weeks 1-3: A, B, C all run = 2+2+2 = 6 programmers (above the limit of 4). Weeks 4-6: only A... demand 2. Peak 6, trough 2.

After shifting C to start after week 3 (using its float): weeks 1-3: A + B = 4, weeks 4-6: A + C is not simultaneous... if A lasts 6 weeks, weeks 4-6 are A + C = 4. Demand is a steady 4 programmers across all 6 weeks, within the limit, and the project end date is unchanged.

Slip chart

A slip chart is a graph of planned versus actual progress, where the activity lines are shown against the time axis and the actual (current) date line is drawn. Each activity's bar/line is plotted and, when targets are revised, the line "slips" to the right. The more jagged or steeply sloping the line, the more the project is behind schedule; a line that is straight and vertical shows the project is on time. It gives a quick visual of slippage trend, and of whether the project is moving to the right (late) or recovering.

Timeline chart

A timeline chart records, for each activity, the planned start/end bar and then the actual dates. At each review the revised target dates are added, so the chart shows how the plan has changed over time. It helps to see which activities are the cause of delays and how delays on one activity affect later ones.

How they help visualize progress

• Present progress in a simple graphical form understandable by non-technical stakeholders.
• Show the history of date changes, enabling analysis of why slippage occurs.
• Give early warning of delay so corrective action can be taken.
• Support reporting and decisions on replanning.

A dispersed (distributed/virtual) team works from different geographic locations, linked by communication technology.

Advantages

• Access to a wider pool of skilled people, regardless of location.
• Lower costs (office space, relocation, cheaper labour in some locations).
• Round-the-clock development using time-zone differences ("follow the sun").
• Greater flexibility for staff, improving satisfaction and retention.
• Can be located close to the customer or local market.

Challenges

• Communication difficulties - lack of face-to-face contact, language and cultural differences, misunderstandings.
• Time-zone differences make meetings hard to arrange.
• Lack of trust and team cohesion, feelings of isolation.
• Coordination and monitoring of work is harder; version control and integration problems.
• Dependence on technology and network reliability, and security of shared data.
• Unclear responsibility and differing work practices.

Cash flows (Rs): Year 0 = -100,000; Year 1 = 50,000; Year 2 = 30,000; Year 3 = 10,000; Year 4 = 20,000; Year 5 = 20,000.

Payback period

The investment is recovered during year 4. Remaining at end of year 3 = Rs 10,000.

$\text{Payback} = 3 + \frac{10,000}{20,000} = 3.5 \text{ years}$

ROI

Total inflows = 50,000 + 30,000 + 10,000 + 20,000 + 20,000 = Rs 130,000. Net profit = 130,000 - 100,000 = Rs 30,000.

$ROI = \frac{30,000}{100,000}\times 100 = 30\%$

Average annual ROI = $30\%/5 = 6\%$ per year.

(a) Restricted tendering process

In restricted tendering, the customer invites bids only from a limited list of suppliers who are known to be capable, instead of advertising openly. Invitations go to shortlisted suppliers, usually selected after pre-qualification on the basis of experience, financial standing and technical capability. Advantages: saves time and evaluation cost, fewer unsuitable bids, quality suppliers. Disadvantages: less competition, possibility of favouritism, new suppliers are excluded. It differs from open tendering (anyone may bid) and negotiated procedure (negotiation with a single supplier).

Stages: invitation to tender (with requirements document) -> suppliers prepare proposals -> evaluation of proposals -> selection and contract award.

(b) Project closure

Project closure is the final phase where the project is formally ended. Activities: obtain customer acceptance of deliverables, hand over the product and documentation, release resources and staff, settle contracts and payments, archive project records, and carry out a post-implementation/post-project review to record lessons learnt, assess whether the objectives and benefits were achieved, and compare actual with planned time, cost and quality. Closure ensures nothing is left unfinished and that knowledge is kept for future projects.