SOFTWARE PROJECT MANAGEMENT

UNIT -2

SYLLABUS: Project Life Cycle and Effort Estimation : Software process and
Process Models – Choice of Process models – Rapid Application development –
Agile methods – Dynamic System Development Method – Extreme
Programming– Managing interactive processes – Basics of Software estimation –
Effort and Cost estimation techniques – COSMIC Full function points – COCOMO
II – a Parametric Productivity Model.
Project Management Life Cycle (PMLC)
The Project Management Life Cycle refers to the structured stages a project goes through from
initiation to completion. It helps in managing the project efficiently and delivering desired
outcomes.
Phases of Project Management Life Cycle
1.Initiation Phase
1. Define project goals and objectives
2. Identify stakeholders
3. Conduct feasibility study
4. Prepare Project Charter (official authorization to start the project)
2.Planning Phase
1. Develop Project Management Plan
2. Define project scope, schedule (timeline), cost, quality, and resources
3. Risk management planning
4. Communication and procurement planning
3.Execution Phase
1. Perform the tasks defined in the plan
2. Allocate and manage resources
3. Ensure product or service delivery
4. Stakeholder communication and team management
4.Monitoring and Controlling Phase
1. Track project performance (Time, Cost, Scope, Quality)
2. Compare actual performance with plan
3. Identify variances and take corrective actions
4. Manage change requests
5.Closure Phase
1. Complete and deliver final product/service
2. Obtain client acceptance
3. Release project resources
4. Conduct post-project evaluation (Lessons Learned)
5. Close contracts and documentation
Key Benefits:
• Structured project flow
• Clear deliverables at each stage
• Better control and communication
• Timely identification of issues
Software Process Models
A Software Process Model is a standard framework used to plan, structure, and control
the process of developing software systems.
Common Software Process Models:
1.Waterfall Model
1. Linear and sequential model
2. Each phase must be completed before the next begins
2.Iterative Model
1. Software is developed in repeated cycles (iterations)
2. Enhancements are added in each iteration
3.Spiral Model
1. Combines iterative model with risk analysis
2. Focus on risk identification and management
4.V-Model (Validation & Verification Model)
1. Extension of Waterfall with parallel testing phases
2. Emphasizes early testing and validation
5.Agile Model
1. Based on iterative and incremental development
2. Promotes flexibility, customer collaboration, and rapid delivery
SDLC (Software Development Life Cycle):
• Definition:
SDLC is a framework that defines the phases involved in the development of
software — from requirements gathering to maintenance.
• Phases in SDLC:
• Requirement Gathering and Analysis
• System Design
• Implementation (Coding)
• Testing
• Deployment
• Maintenance
Waterfall Model
Definition:
• The Waterfall Model is a linear and sequential software development methodology.
In this model, each phase must be completed before the next begins, resembling a
waterfall's flow. It's one of the earliest SDLC models and is best suited for projects
with well-defined requirements.
Advantages of the Waterfall Model:
• Simplicity and Clarity:
• Easy to understand and manage due to its linear nature.
• Structured Approach:
• Each phase has specific deliverables and a review process.
• Well-Documented:
• Comprehensive documentation at each phase aids in understanding and future maintenance.
• Discipline:
• Encourages disciplined engineering practices.
• Ideal for Small Projects:
• Works well when requirements are well-understood and unlikely to change.
Disadvantages of the Waterfall Model:
• Inflexibility:
• Difficult to accommodate changes once the process is underway.
• Late Testing:
• Testing occurs after development, making it hard to identify issues early.
• Client Involvement:
• Limited client interaction during development; feedback is received late.
• Risk of Misinterpretation:
• Misunderstood requirements can lead to significant issues, discovered only at later stages.
• Not Ideal for Complex Projects:
• Less suited for projects where requirements are expected to evolve.
When to Use the Waterfall Model:
• Clear and Fixed Requirements:
• When the project's requirements are well-understood and unlikely to change.
• Short-Term Projects:
• Suitable for projects with a short duration and limited scope.
• Regulatory Compliance:
• Projects requiring thorough documentation and compliance with standards.
• Stable Technology:
• When the technology stack is well-known and stable.
Phases of the Waterfall Model:
1.Requirement Gathering and Analysis:
1. Collect and document all software requirements.
2. Understand the client's needs and expectations.
3. Output: Software Requirement Specification (SRS) document.
2.System Design:
1. Translate requirements into system architecture.
2. Define hardware and software specifications.
3. Output: Design documents detailing system architecture and components.
3.Implementation (Coding):
1. Developers write code based on the design documents.
2. Each module is developed and tested individually (unit testing).
4.Integration and Testing:
1. Integrate all modules into a complete system.
2. Conduct system testing to identify and fix defects.
5.Deployment:
1. Deploy the fully developed system to the production environment.
2. Ensure the system operates as intended in the real-world setting.
6.Maintenance:
1. Perform ongoing maintenance to fix issues and update the system as needed.
2. Handle any post-deployment problems or enhancements.
Prototyping Model
Definition:
The Prototyping Model is a software development approach where a prototype
(working model) of the system is built early in the development process. It
allows users to interact with the prototype, provide feedback, and refine
requirements before actual development begins.
• This model helps in understanding unclear or changing requirements by
building successive versions of the software.
When is the Prototyping Model Used?
• When requirements are not clear at the beginning.
• When user interaction with the system is critical (e.g., UI-heavy applications).
• In research and development projects where innovation is involved.
• When frequent changes in requirements are expected.
• Suitable for complex systems where the customer needs to “see” a version
before final development.
Phases of the Prototyping Model:
1.Requirement Gathering and Analysis:
1. Initial requirements are collected from the customer.
2. Focus is on aspects that are not well understood.
2.Quick Design:
1. Create a basic design of the system (user interface, process flow).
2. It is not a complete design but a rough mock-up.
3.Build Prototype:
1. Develop a simple, functional version of the system.
2. It demonstrates limited features or interfaces.
4.User Evaluation:
1. The user interacts with the prototype and provides feedback.
2. Requirements are refined based on user input.
5.Refinement:
1. Adjust the prototype or develop a new one based on feedback.
2. Repeat the cycle until requirements are well-understood.
6.Final Product Development:
1. Once requirements are clear, the actual system is developed using the Waterfall or another suitable
model.
7.Testing and Maintenance:
1. Test the final product and maintain it post-deployment.
Advantages:
• Improves requirement clarity through user feedback
• Early detection of missing or misunderstood requirements
• Increased user involvement and satisfaction
• Reduces risk of failure
• Enhances communication between developers and users
Disadvantages:
• May lead to incomplete or incorrect final system if the prototype is mistaken as the final
version
• Frequent changes can increase development time and cost
• Requires skilled developers for quick prototype creation
• Not suitable for large systems with very strict performance or reliability constraints
Example Use Cases:
• Web applications and mobile apps
• Customer-facing portals where UI/UX is crucial
• Innovative or startup product ideas
• Systems with evolving or unclear user needs
V-Model (Verification and Validation Model)
Definition:
The V-Model is an extension of the Waterfall Model, where each development phase is associated with a corresponding
testing phase. The process is structured in a "V" shape to emphasize the relationship between development and testing.
• This model focuses on validation and verification activities alongside the development process.
Phases of the V-Model:
The model consists of two main paths:
Left Side – Development Phases (Verification):
1. Requirement Analysis
1. Understand user requirements.
2. Output: Requirement Specification Document.
2. System Design
1. Define the complete system architecture.
2. Output: System Architecture Design.
3. High-Level Design (HLD)
1. Break system into modules or components.
2. Output: Module Design.
4. Low-Level Design (LLD)
1. Detailed internal design of individual modules.
2. Output: Program Specifications.
5. Coding
1. Actual coding of modules based on LLD.
Right Side – Testing Phases (Validation):
6.Unit Testing
6. Test individual modules (from LLD).
7.Integration Testing
6. Test interactions between modules (from HLD).
8.System Testing
6. Test the entire system functionality (from System Design).
9.Acceptance Testing
6. Final testing with user requirements (from Requirement Analysis).
Key Characteristics:
• Testing activities start early in the life cycle.
• Development and testing activities are planned in parallel.
• Emphasizes early detection of defects.
• Each phase is verified before moving to the next.
Advantages of the V-Model:
• Simple and easy to understand.
• Improves quality due to early testing.
• Better requirement traceability.
• Defects are found at early stages.
• Clear mapping between development and testing.
Disadvantages of the V-Model:
• Not flexible to requirement changes.
• Costly and time-consuming for large projects.
• Not suitable for projects with unclear requirements.
• Little user involvement once requirements are finalized.
When to Use the V-Model:
• When requirements are clear and well-documented.
• For mission-critical systems like banking, medical, or defense software.
• When testing is a priority.
• When quality assurance is strictly required.
Spiral Model
Definition:
The Spiral Model is a risk-driven software development process model that combines features of the
Waterfall Model and Prototyping Model. It is used for large, complex, and high-risk projects where
frequent changes are expected.
• The process is represented as a spiral with many loops. Each loop represents a phase of the software
process, and the number of loops is not fixed.
Phases of the Spiral Model (in each loop):
Each loop (or phase) of the spiral consists of four main activities:
1.Planning:
1. Define objectives, alternatives, and constraints for that phase.
2. Estimate cost, schedule, and resources.
2.Risk Analysis:
1. Identify and analyze risks (technical, management, operational).
2. Develop strategies to reduce or eliminate risks.
3.Engineering (Development and Testing):
1. Develop a prototype or actual system based on the plan.
2. Perform coding, verification, and validation.
4.Evaluation:
1. Review progress with the customer.
2. Get feedback and plan the next phase (next loop of the spiral).
Repetition of Spiral Cycles:
• Each cycle builds on the previous one and brings the project closer to the final
product. With every spiral loop, the system is refined and expanded until the final
version is complete.
Key Characteristics:
• Risk assessment is central to the process.
• Combines iterative development (like Agile) with systematic aspects of the Waterfall
model.
• Emphasizes customer feedback at each stage.
Advantages of the Spiral Model:
• Effective for high-risk, complex, and large-scale projects.
• Risk analysis and mitigation are integral to the process.
• Allows for early identification of potential problems.
• Strong user involvement and continuous feedback.
• Flexibility to change requirements at any stage.
Disadvantages of the Spiral Model:
• Can be expensive due to repeated cycles and risk analysis.
• Not suitable for small or low-budget projects.
• Requires high-level expertise in risk assessment.
• Project success depends heavily on proper risk management.
When to Use the Spiral Model:
• When the project is large, complex, and high-risk.
• When requirements are unclear or likely to evolve.
• When regular customer feedback is important.
• For mission-critical systems (e.g., military, aerospace, banking).
Incremental Life Cycle Model
Definition:
The Incremental Model divides the software development process into multiple small parts (increments). Each increment
adds functionality and is delivered to the customer after completion.
Key Features:
• Product is built in steps (increments).
• Each increment contains part of the full functionality.
• The first increment is a core product; later increments add features.
Advantages:
• Early partial product delivery.
• Easier testing and debugging.
• Flexible to changes in requirements.
• Risk is reduced due to smaller builds.
Disadvantages:
• Requires good planning and design.
• Integration of multiple increments may be complex.
• Not suitable for small projects.
When to Use:
• When basic functionality is required early.
• For projects with clear overall requirements, but detailed features may evolve.
Evolutionary Life Cycle Model
Definition:
The Evolutionary Model builds the final system gradually by developing successive versions based on user feedback and
evolving requirements.
Key Features:
• Focuses on developing the system in versions.
• Continuous customer interaction is required.
• Each version is improved based on feedback.
Advantages:
• Suitable for changing requirements.
• Useful for complex systems.
• Continuous improvement of product quality.
• Early working system available.
Disadvantages:
• May be hard to manage versions.
• Requires user involvement throughout.
• Documentation may be less complete.
When to Use:
• When requirements are not well understood initially.
• For R&D-based, dynamic, or real-time systems.
Iterative Enhancement Model
Definition:
In this model, software is developed and delivered in small functional parts called iterations. Each iteration involves design,
coding, and testing. It is refined in successive cycles.
Key Features:
• Each iteration builds on the previous one.
• Enhancements are added in each cycle.
• Feedback is used to improve the next iteration.
Advantages:
• Progressive delivery of the system.
• Feedback-driven development.
• Reduces risk and cost of failure.
• Better error detection.
Disadvantages:
• May require redesign after every iteration.
• Not suitable for very small projects.
• Requires good planning to manage iterations.
When to Use:
• For medium to large projects with evolving needs.
• Where feedback is essential after each cycle.
Rapid Application Development (RAD) Model
Definition:
The Rapid Application Development (RAD) model is a type of incremental model that
emphasizes quick development and delivery of high-quality software through
prototyping and user involvement.
• It minimizes planning time and focuses on rapid construction using reusable
components and strong collaboration between developers and users.
Key Characteristics:
• Emphasis on speed and agility.
• Involves user participation throughout.
• Uses prototypes and reusable components.
• Short development cycles (30-90 days typical).
When to Use the RAD Model:
• When project needs to be developed quickly.
• When requirements are well understood and not too complex.
• When users are available to give continuous feedback.
• For small to medium-sized applications with short development timelines.
Phases of the RAD Model:
1.Business Modeling:
1. Understand the business functions and data flow.
2. Identify critical business needs.
2.Data Modeling:
1. Define data objects and relationships.
2. Use data flow diagrams or ER diagrams.
3.Process Modeling:
1. Convert data models into processes.
2. Define inputs, outputs, and how data is transformed.
4.Application Generation:
1. Use automated tools or CASE tools to quickly build the actual system.
2. Code generation happens through software tools.
5.Testing and Turnover:
1. Each component is tested immediately after development.
2. Since components are already tested during iterations, final testing is faster.
Advantages:
• Faster development and delivery.
• High user satisfaction due to constant involvement.
• Encourages reusability of components.
• Easier to incorporate changes.
Disadvantages:
• Not suitable for large or complex projects.
• Depends on strong team coordination.
• Requires highly skilled developers and designers.
• Less control over processes due to quick iterations.
What is Agile?
The Agile Model is a modern software development approach that focuses on iterative development, customer collaboration, early delivery, and
responding to changes quickly.
• Agile promotes breaking the project into small, manageable units (iterations or sprints) and delivering working software frequently.
Agile Model Phases:
1. Concept / Requirement Gathering:
1. Collect initial, high-level user requirements.
2. Define the business need and prioritize features.
2. Iteration / Sprint Planning:
1. Break down the work into small iterations (typically 1–4 weeks).
2. Team selects which tasks to complete in that sprint.
3. Design:
1. Lightweight design for the selected features in the sprint.
2. Emphasis on simplicity and flexibility.
4. Development / Coding:
1. Code is written for selected features using incremental and iterative practices.
2. Continuous integration may be used.
5. Testing:
1. Continuous testing is performed within the sprint.
2. Bugs are fixed immediately.
6. Release / Deployment:
1. Working software is delivered at the end of each sprint.
7. Review / Feedback:
1. Product owner and stakeholders review the outcome.
2. Feedback is used for improvement in the next sprint.
8. Retrospective:
1. Team reflects on what went well and what can be improved.
Agile Testing Methods:
Agile testing is continuous and occurs parallel to development. It involves:
1.Test-Driven Development (TDD):
1. Write tests before writing the code.
2. Ensures code meets the test from the start.
2.Acceptance Test-Driven Development (ATDD):
1. Acceptance criteria are written before coding.
2. Ensures software meets user expectations.
3.Behavior-Driven Development (BDD):
1. Focuses on the behavior of the application.
2. Uses natural language for test cases.
4.Exploratory Testing:
1. Simultaneous learning and test design.
2. Encourages creative and unscripted testing.
5.Unit Testing:
1. Performed by developers to test individual components.
6.Regression Testing:
1. Ensures new changes haven’t broken existing functionality.
Advantages of Agile Model:
• Faster delivery of working software.
• Encourages customer feedback and involvement.
• Better adaptability to changing requirements.
• Continuous testing improves quality.
• Higher transparency and team collaboration.
• Motivated and self-organizing teams.
Disadvantages of Agile Model:
• Difficult to predict cost and time in large projects.
• Not suitable for complex systems requiring strict documentation.
• Needs experienced developers and team collaboration.
• Customer availability is necessary throughout the process.
• Risk of scope creep due to flexible requirements.
When to Use Agile:
• When requirements are likely to change frequently.
• When early and continuous delivery of software is important.
• When the project demands customer interaction and quick releases.
• For startups, web applications, and modern enterprise software.
Software Configuration Management (SCM)
Definition:
Software Configuration Management (SCM) is a discipline of software
engineering that focuses on identifying, organizing, and controlling changes in
software during the development life cycle.
• It ensures that changes made to the software are properly tracked, managed,
and documented without affecting the integrity and quality of the final product.
Objectives of Software Configuration Management:
1.Control changes systematically in software components.
2.Maintain integrity and consistency of the software product.
3.Ensure the software product is reproducible and manageable.
4.Provide a systematic approach to handle revisions and updates.
5.Prevent unauthorized changes to software artifacts.
6.Ensure that the correct version of the software is used at all times.
Goals of Software Configuration Management:
1.Configuration Identification:
1. Identify and define the configuration items (CIs) such as code, documents, data, etc.
2.Configuration Control:
1. Control the changes to configuration items using formal procedures (like change control boards).
3.Configuration Status Accounting:
1. Keep records of the current and historical states of configuration items.
2. Track what has been changed, when, why, and by whom.
4.Configuration Auditing:
1. Verify that software components conform to their specifications.
2. Ensure completeness, correctness, and consistency.
5.Version Control:
1. Maintain different versions of software artifacts to manage parallel development and rollback if
needed.
6.Build Management:
1. Ensure that builds are created correctly using the right components and configurations.
7.Release Management and Delivery:
1. Ensure that the correct and approved software versions are delivered to users.
Importance of SCM:
• Prevents conflicts during team collaboration.
• Maintains quality and traceability.
• Helps in handling complex projects with many contributors.
• Essential for regulatory compliance and audits.
What is Software Project Estimation?
Software project estimation is the process of predicting the effort, time, and
cost required to develop a software project. It helps project managers plan
resources, schedules, and budgets effectively.
It involves estimating:
• Effort (person-months)
• Time (calendar months)
• Cost (in currency)
• Resources (human, hardware, software)
Objectives of Estimation:
1.To determine how much time and effort will be needed.
2.To estimate cost and resources required.
3.To help in project planning and scheduling.
4.To support decision-making regarding feasibility and scope.
5.To control project risks by identifying possible constraints early.
Software Project Estimation Techniques
1.Expert Judgment
1. Based on experience of experts or senior team members.
2. Quick but may be subjective.
2.Delphi Technique
1. Anonymous estimates from multiple experts.
2. Repeated until consensus is reached.
3.Function Point Analysis (FPA)
1. Estimates based on user functions (inputs, outputs, files, etc.).
2. Independent of programming language.
4.COCOMO (Constructive Cost Model)
1. Mathematical model using project size (KLOC) to estimate effort.
2. Variants: Basic, Intermediate, Detailed.
5.Use Case Points (UCP)
1. Estimation based on use cases in the software.
2. Suitable for object-oriented systems.
6.Wideband Delphi
1. Enhanced Delphi method with open discussions among experts.
2. More structured and accurate.
Cost Estimation Techniques
1.Expert Judgment
1. Based on prior experience and intuition of experts.
2. Quick but may be biased or inaccurate.
2.Delphi Technique
1. Estimates collected from a panel of experts anonymously.
2. Repeated until a consensus is reached.
3.Function Point Analysis (FPA)
1. Measures software size based on functions delivered to the user.
2. Considers inputs, outputs, files, interfaces, and inquiries.
3. Technology-independent.
4.COCOMO Model (Constructive Cost Model)
1. Developed by Barry Boehm.
2. Estimates effort, cost, and time based on size (KLOC).
3. Types:
1. Basic COCOMO
2. Intermediate COCOMO
3. Detailed COCOMO
5.Use Case Points (UCP)
1. Estimates based on the number and complexity of use cases.
2. Suitable for object-oriented projects.
6.Top-Down Estimation
1. Estimate total cost first, then break it down into subcomponents.
2. Good for early stages; may lack accuracy.
7.Bottom-Up Estimation
1. Estimate cost of individual components first, then sum up.
2. More accurate but time-consuming.
8.Analogous Estimation
1. Based on comparison with similar past projects.
2. Requires historical project data.
9.Parametric Estimation
1. Uses statistical models and parameters (like cost per LOC or per hour).
2. Needs accurate historical data.
Heuristic Techniques in Software Cost Estimation
Heuristic techniques use rules of thumb, expert judgment, and approximate methods
to estimate software project cost, effort, or duration. They are often based on past
experience and informal logic rather than strict formulas.
Advantages of Heuristic Techniques:
1.Simple and Quick:
1. Easy to apply and understand; suitable for early-stage estimation.
2.Low Cost:
1. Requires fewer resources compared to complex models.
3.Useful with Limited Data:
1. Effective when detailed project information is not yet available.
4.Flexible:
1. Can be adapted to different types of projects and domains.
5.Based on Experience:
1. Leverages domain expertise, which may be highly valuable in practice.
6.Applicable Early:
1. Can be used in the feasibility or concept phase of the project.
Disadvantages of Heuristic Techniques:
1.Less Accurate:
1. Estimates may vary greatly due to subjective judgment.
2.Not Scalable:
1. May not work well for large or complex projects.
3.Bias and Inconsistency:
1. Prone to human error, intuition bias, or overconfidence.
4.Lack of Standardization:
1. No uniform process or formula; difficult to validate.
5.Hard to Justify:
1. Since it lacks data-driven backing, it's hard to defend in audits or reports.
COSMIC Function Points (Common Software Measurement International Consortium)
Definition:
COSMIC Function Points (CFP) is a software sizing method used to measure the functional size
of software by quantifying the data movements involved in user requirements.
• It is an advanced version of traditional Function Point Analysis (FPA) and is independent of
programming language, technology, or development method.
Key Concepts:
1.Functional User Requirements (FUR):
1. The basis for measuring functional size.
2. Focuses on what the system does, not how it does it.
2.Data Movements in COSMIC:
COSMIC measures four types of data movements:
1. Entry (E): Data moves from user to software.
2. Exit (X): Data moves from software to user.
3. Read (R): Data moves from persistent storage to software.
4. Write (W): Data moves from software to persistent storage.
3.Measurement Unit:
1. Size is measured in COSMIC Function Points (CFP).
2. Each data movement = 1 CFP.
Advantages:
• Suitable for modern software systems (real-time, business, etc.).
• Technology-independent.
• Good for object-oriented and layered architectures.
• Aligns well with Agile and iterative development models.
Applications:
• Project estimation and planning.
• Performance benchmarking.
• Project productivity analysis.
COCOMO Model (Constructive Cost Model)
Developed by: Barry W. Boehm
• Purpose: To estimate effort, time, and cost of software development based on
the size of the project (in KLOC – Thousands of Lines of Code).
Types of COCOMO Models:
1.Basic COCOMO:
1. Estimates effort based only on size of software (KLOC).
2.Intermediate COCOMO:
1. Includes cost drivers like complexity, experience, tools.
3.Detailed COCOMO:
1. Includes all factors from intermediate model + cost estimation at each phase of the
project.
Basic COCOMO Model Formulae:
1.Effort (E) = a × (KLOC)^b → in Person-Months
2.Development Time (T) = c × (E)^d → in Months
3.People Required (P) = Effort / Time
• Values of a, b, c, d depend on the project type:
Project Type a b c d
Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Example of Basic COCOMO Model (Organic Project)
• Suppose a software project has a size of 32 KLOC (thousands of lines of code).
• The project type is Organic (simple, small teams, familiar environment).
Using the Basic COCOMO formulas and constants for Organic projects:
• Effort (E) = 2.4 × (Size)^1.05
= 2.4 × (32)^1.05
= 2.4 × 36.26
= 87 person-months (approx)
• Development Time (T) = 2.5 × (Effort)^0.38
= 2.5 × (87)^0.38
= 2.5 × 6.23
= 15.6 months (approx)
• Team Size (P) = Effort / Time
= 87 / 15.6
= 5.6 ≈ 6 persons
• Summary:
For a 32 KLOC Organic project, the estimated effort is about 87 person-months, the
project will take approximately 15.6 months, and the team size required is around 6
people.
Parametric Productivity Model
• Definition:
A software estimation technique that uses mathematical formulas and statistical
relationships between project parameters (like size, effort, cost) to predict
productivity and project metrics.
• How it works:
It establishes a relationship between input variables (such as lines of code, function
points) and output variables (effort, cost, duration) using historical project data.
• Example:
Effort = Productivity factor × Size (e.g., person-months per function point)
• Advantages:
• Quantitative and objective.
• Can be automated and reused.
• Useful for large projects with available historical data.
• Disadvantages:
• Requires accurate and relevant historical data.
• May not adapt well to new or unique projects.
• Model parameters must be calibrated properly.
THANKS FOR WATCHING

BEST OF LUCK FOR EXAM