Unit 2: Cost Estimation and Life Cycle Models

I. Orientation — Project cost and development control

Software project management coordinates people, money, technology, time, and risks to deliver a defined product. Cost estimation connects the planned scope and schedule with required resources, while life cycle models define how work moves from requirements to operation. Modern practice combines predictive planning, iterative delivery, automation, and evidence-based decision-making.

A. Meaning

Software project management is the application of planning, organizing, monitoring, and controlling techniques to achieve project objectives within agreed constraints.

• Core constraints: Scope, cost, time, quality, resources, and risk influence one another; adding features without changing time or resources usually increases cost or reduces quality.
• Cost estimate: A forecast of money, effort, and resources needed to complete work; effort is commonly measured in person-hours or person-months.
• Life cycle: The sequence of stages through which software passes, such as requirements, design, implementation, testing, deployment, and maintenance.
• Management principle: Plans are revised using actual performance data, because estimates become more reliable as project knowledge increases.

B. Introduction to Life Cycle Models

A life cycle model provides a structured way to organize software activities and control dependencies between them.

• Predictive models: Define much of the scope and sequence early; the V-Process Model is suitable when requirements and compliance obligations are stable.
• Adaptive models: Deliver working increments and respond to feedback; Agile is useful where requirements change frequently.
• Automated delivery: DevOps and CI/CD connect development, testing, deployment, and operations into a continuous flow.
• Selection basis: The model should reflect uncertainty, regulatory needs, stakeholder availability, technical complexity, and release frequency.

II. Cost and Resource Management — Building a feasible plan

Cost management converts project objectives into an affordable plan. It requires identifying resources, estimating their consumption, assigning responsibilities, and comparing actual spending with the approved budget.

A. Managing allocation of resources

Resource allocation assigns limited people, equipment, services, and funds to activities so that project objectives can be met.

• Resource types: Developers, testers, analysts, cloud services, licenses, hardware, training, and external suppliers all create measurable cost.
• Capacity constraint: A developer available for 120 hours in a month cannot be scheduled for 160 hours without overtime, delay, or reassignment.
• Allocation principle: Assign scarce skills to activities on the critical path or activities with the greatest risk reduction.
• Resource leveling: Move or sequence tasks to remove over-allocation; this may extend the schedule but produces a more realistic plan.
• Responsibility mapping: A responsibility assignment matrix links each work package to responsible and accountable roles.

B. Creating programme

Creating programme means organizing related projects and operational activities under coordinated governance to achieve benefits that individual projects cannot achieve alone.

• Programme scope: A programme may include a billing-system project, a mobile-app project, and a data-migration project serving one business transformation.
• Shared resources: A common security architect or test environment must be scheduled across projects to prevent conflicts.
• Benefits focus: Programme success is measured by outcomes such as reduced processing time or increased revenue, not merely by delivering separate project outputs.
• Governance structure: A programme manager coordinates priorities, dependencies, funding, risks, and decisions across projects.
• Roadmap: A time-based roadmap shows milestones, releases, dependency relationships, and expected benefits.

C. Individual projects

An individual project is a temporary, controlled effort undertaken to produce a defined software product, service, or result.

• Defined objective: “Deliver a payment API supporting 1,000 transactions per minute” is more controllable than “improve payments.”
• Work breakdown: The objective is decomposed into requirements, design, coding, testing, deployment, and documentation work packages.
• Baseline: The approved scope, schedule, and budget form a baseline against which performance is measured.
• Project manager’s role: The manager coordinates resources, manages changes, reports status, and resolves issues within delegated authority.
• Acceptance condition: Completion requires agreed evidence, such as passed acceptance tests and signed stakeholder approval.

D. Program management

Program management coordinates related projects and manages their interdependencies, shared resources, risks, and strategic benefits.

• Dependency control: A data-migration project may need to finish before a reporting project can use reliable data.
• Priority decisions: If two projects need the same specialist, programme governance assigns the specialist according to strategic value and urgency.
• Change coordination: A change to a shared architecture must be assessed for its effect on every dependent project.
• Benefit realization: Benefits are tracked after delivery, for example comparing actual support-cost reduction with the programme forecast.
• Difference from project management: Project management delivers a specific result; program management coordinates multiple results to achieve broader organizational change.

III. Project Evaluation and Decision-Making — Selecting worthwhile work

Project evaluation determines whether a proposed project is financially justified, strategically suitable, and sufficiently feasible before substantial resources are committed.

A. Risk evaluation

Risk evaluation identifies uncertain events, estimates their effects, and prioritizes responses.

• Risk exposure: A simple quantitative measure is:

Risk Exposure = Probability of occurrence × Impact

Probability is a value from 0 to 1, and impact may be measured in currency, days, or quality loss.

• Worked example: A 0.25 probability of a $20,000 integration failure gives an expected exposure of $5,000.
• Risk categories: Technical complexity, requirements change, staffing, suppliers, security, compliance, schedule, and financial risks require different owners.
• Response strategies: Avoid the risk, reduce its probability or impact, transfer it through contracts or insurance, or accept it with a contingency plan.
• Monitoring: Risk registers record probability, impact, owner, trigger, response, and review date.

B. Cost benefit analysis

Cost benefit analysis compares expected project costs with quantifiable and non-quantifiable benefits.

• Cost categories: Include development labor, infrastructure, licenses, training, migration, support, maintenance, and opportunity cost.
• Benefit categories: Include increased revenue, reduced labor, fewer failures, faster service, regulatory compliance, and improved customer retention.
• Net benefit: A basic calculation is:

Net Benefit = Total Benefits - Total Costs

• Benefit-cost ratio:
  
  TEXT

    Benefit-Cost Ratio = Present Value of Benefits / Present Value of Costs

  
  A ratio above 1 generally indicates that benefits exceed costs.
• Time value: Discounting recognizes that money received later is worth less than money received now; discount rate, cash-flow timing, and project life must be stated.
• Limitation: Strategic or compliance benefits may be real but difficult to express accurately in monetary units.

C. Evaluation of individual projects

Evaluation of individual projects examines feasibility and expected performance against organizational criteria.

• Strategic fit: The project should support a stated business objective, such as entering a market or reducing transaction errors.
• Technical feasibility: Assess architecture, integration, performance, security, skills, and technology maturity.
• Schedule feasibility: Compare required completion date with estimated effort, dependencies, team capacity, and contingency.
• Financial feasibility: Examine budget, cash flow, payback period, net present value, and sensitivity to changed assumptions.
• Quality and compliance: Identify acceptance criteria, legal obligations, accessibility requirements, data protection, and audit evidence.
• Decision outcome: The project may be approved, rejected, deferred, rescoped, or approved conditionally with risk controls.

D. Multi-Criteria Decision Analysis (MCDA)

MCDA evaluates alternatives using several weighted criteria rather than relying on cost alone.

• Scoring process: Define criteria, assign weights, score each option, multiply scores by weights, and sum the results.
• Typical criteria: Cost, strategic alignment, technical feasibility, risk, delivery speed, maintainability, and expected benefit.
• Formula:
  
  TEXT

    Weighted Score(option) = Σ [Weight(criteria) × Score(option, criteria)]

• Worked example: If speed has weight 0.3 and an option scores 8/10, its contribution is 2.4 points; all criterion contributions are added.
• Decision quality: Criteria and weights should be agreed before scoring to reduce favoritism and hidden assumptions.
• Sensitivity analysis: Recalculate rankings after changing important weights; an option that wins only under one weighting scheme deserves cautious approval.

IV. AI-Enhanced Cost Estimation — Data-supported forecasting

AI-enhanced estimation uses historical project data and machine-learning techniques to identify relationships between project characteristics, effort, duration, and resource demand.

A. AI-Enhanced Cost Estimation: Predictive cost estimation and resource prediction

Predictive estimation produces a forecast from features such as function points, team size, complexity, defect history, technology, and delivery constraints.

• Input data: Historical effort, actual cost, task duration, requirements size, team experience, and change frequency must be consistent and labeled.
• Prediction output: A model may estimate 8,400 person-hours and provide a confidence interval rather than a single unquestionable value.
• Model types: Regression predicts numeric cost; classification can predict risk categories; time-series models can forecast staffing or expenditure over months.
• Resource prediction: The system can estimate the number and type of developers, testers, analysts, cloud instances, or support staff required at each stage.
• Validation: Hold out historical examples for testing and compare predicted values with actual values using measures such as mean absolute error.
• Governance: Human review is required because biased historical data, changing technologies, or missing requirements can produce misleading forecasts.
• Practical rule: AI should support expert judgment and expose assumptions; it should not replace approval authority or risk analysis.

V. Project Approach — Choosing how work will be organized

Project approach describes the management and delivery strategy used to transform requirements into an accepted software product.

A. Project approach

The approach should match uncertainty, stakeholder needs, technical risk, and the required delivery cadence.

• Predictive approach: Scope and activities are planned early, with formal change control; it suits stable requirements and contractual milestones.
• Iterative approach: The solution is refined through repeated cycles, allowing learning before final completion.
• Incremental approach: Functionality is delivered in usable portions, such as releasing login, payments, and reporting separately.
• Adaptive approach: Teams use short feedback cycles when requirements or priorities are uncertain.
• Selection factors: Consider customer availability, regulatory evidence, architectural uncertainty, team maturity, integration complexity, and cost of late change.

VI. V-Process Model — Verification and validation alignment

The V-Process Model is a sequential life cycle in which each development activity is paired with a corresponding testing activity. It emphasizes early test planning, traceability, and controlled approval.

A. V-Process Model

The model descends through specification and design, reaches implementation, and ascends through progressively broader testing.

• Left side: Requirements lead to system design, architectural design, and detailed design before coding.
• Bottom point: Implementation or coding connects design activities with test execution.
• Right side: Unit testing checks modules, integration testing checks interfaces, system testing checks the complete system, and acceptance testing checks user needs.
• Traceability: A requirement such as “response time under two seconds” should map to a design element and a measurable performance test.
• Strength: Early verification planning improves defect detection and supports regulated projects.
• Limitation: Frequent late changes are expensive because completed specifications and test plans may need rework.

VII. Agile Model — Adaptive and incremental delivery

The Agile Model delivers software in short cycles and uses frequent stakeholder feedback to manage changing requirements and evolving understanding.

A. Agile Model

Agile organizes work around a prioritized product backlog, small increments, continuous collaboration, and regular inspection and adaptation.

• Iteration: A sprint may last two weeks and produce a tested increment rather than unfinished partial code.
• Prioritization: Product owners order backlog items by value, urgency, risk, and dependencies.
• Feedback loop: Reviews reveal whether delivered behavior meets user needs; retrospectives improve the team’s working process.
• Estimation: Teams may estimate relative size using story points, then forecast using observed velocity.
• Strength: Agile reduces the cost of discovering wrong assumptions early.
• Limitation: It needs active stakeholder participation, disciplined backlog management, technical quality practices, and a clear product vision.

VIII. Devops — Integrating delivery and operations

DevOps is a culture and set of practices that bring development and operations together to improve delivery speed, reliability, feedback, and shared accountability.

A. Devops

DevOps treats software delivery and operation as one continuous system supported by automation and measurement.

• Collaboration: Development, operations, security, and quality roles share responsibility for production outcomes.
• Infrastructure automation: Infrastructure as code records environments in version-controlled definitions, reducing configuration drift.
• Observability: Logs, metrics, traces, and alerts reveal service health after deployment.
• Operational feedback: Production failure data informs backlog priorities and future design decisions.
• Measures: Deployment frequency, lead time for changes, change failure rate, and mean time to restore indicate delivery performance.
• Security integration: Secure coding, dependency scanning, secret management, and compliance checks should occur throughout the pipeline.

IX. CI/CD Pipeline — Automated build, test, and release

A CI/CD pipeline is an automated sequence that validates code and moves it through controlled environments toward release or deployment.

A. CI/CD Pipeline

Continuous integration frequently merges code into a shared repository, while continuous delivery keeps software release-ready; continuous deployment automatically releases approved changes.

• Source stage: A commit or pull request triggers the pipeline and records the exact revision.
• Build stage: Dependencies are resolved and an immutable artifact, such as a container image, is created.
• Test stage: Unit, integration, security, performance, and acceptance checks provide progressively stronger evidence.
• Release stage: The artifact is promoted to staging and production using approvals, feature flags, or automated policies.
• Feedback: Failed tests stop promotion and report the failing stage to developers.
• Example flow:

Commit -> Build -> Unit Test -> Integration Test -> Security Scan
       -> Staging Deploy -> Acceptance Test -> Production Deploy

• Pipeline quality: Fast feedback, reproducible environments, rollback capability, versioned configuration, and secrets stored outside source code make automation dependable.