UNIT-2 (Project life cycle and effort estimation )

Project Lifecycle and various stages

0. Selecting project
• Choose a viable project based on business needs and feasibility
1. Identify the project objective
• Define project objectives and Scope
• Identify stakeholders
2. Identify project infrastructure
• Define tools, technology, and environment.
3. Analyze Project Characteristics
• Project Complexity – Is the project simple, moderate, or very complex?
• Size of the Project – How big is it? How many features will it have?
• Dependencies – Are there any external factors (like third-party software, APIs, or
teams) that the project depends on?
• Constraints – What are the limitations (like budget, time, or resources)?
4. Identify Products and Activities
• What you are going to deliver at the end of the project to the client, whether it is
Mobile app, Website or Software.
5. Estimate Effort for Activity
• Determine time, cost, and resources needed.
6. Identify Activity Risks
• By identifying risks early, the team can plan solutions to avoid delays and failures.
• Technical Risks – Issues with software bugs, compatibility, or performance.
• Resource Risks – Lack of skilled developers, designers, or testers.
• Time Risks – Deadlines might be missed due to unexpected delays.
• Cost Risks – Project might go over budget due to extra work.
• External Risks – Dependencies on third-party tools, APIs, or vendors.
7. Allocate Resources
• Assign tasks, team members, and required assets
8. Review/Publicize Plan
• This step is about checking the project plan carefully and then sharing it with the
team and stakeholders.
9. Execute Plan
• Implement project tasks as per the plan.
10. Lower-Level Planning
• This step is about breaking down the big plan into smaller, more detailed tasks to
improve execution.
• Makes complex tasks easier to manage
TOPIC:
Software Process and Process Models: A Software process is a set of related activities that
leads to the production of the software.
These may involve the development of the software from Scratch or modifying the existing
one.
Activities of any software process are:

1. Software specification: Define the functionalities of software and constraints

2. Software design and implementation: The software is to be designed and
programmed.
3. Verification and validation: Customer must confirm its specification and meet
customer needs.
4. Software maintenance: Software is being modifying according to Market
requirements.

TOPIC:
Software process model:
• A Software Process Model is a structured approach to software development that
defines the steps, activities.
• It helps in planning, managing, and executing software projects effectively.
• There are many kinds of process models for meeting different requirements. We
refer to these as SDLC models (Software Development Life Cycle models). The
most popular and important SDLC models are as follows:
1. Waterfall model
2. V model Incremental model
3. RAD model
4. Agile model
5. Iterative model
6. Prototype model
7. Spiral model

TOPIC:
Factors in choosing a software process:
1. Choosing the right software process model for your project can be difficult.
2. If you know your requirements well, then it will be easier to select a model.

// Factors we already discussed above from 0 to 10 points.

TOPIC:
RAD-Rapid Application Development:
1. Firstly proposed by IBM in 1980s (James Martin)
2. It use powerful development tools and techniques.
3. A project can be broken down into small modules, where each module can be
assigned independently to separate team.
4. Modules are developed in parallel and are integrated to make the complete product
for faster product delivery.
5. Now these modules can finally be combined to form the final product
6. Each module involves various basic steps as in the waterfall model i.e analyzing,
designing, coding, and then testing.
7. Good for Fast development
8. Can be deliver in the short period of time.
9. It uses quick prototyping and iterative delivery with minimal planning.
10. Rapid prototyping means: creating a model of a product or service to test and refine
the design
11. Modules are developed in parallel and are integrated to make the complete product
for faster product delivery.

Following are the various key phases of the RAD Model

• Business Modeling → Understanding business needs and workflows.
• Data Modeling → Structuring the data for the application.
• Process Modeling → Designing workflows and system operations.
• Application Development → Rapid prototyping and coding.
• Testing & Deployment → Continuous testing and final implementation
Advantages of RAD Model
1. Faster Development & Delivery
o Parallel development of modules speeds up the process.
o Ideal for projects with tight deadlines.
2. Better User Involvement & Feedback
o Continuous user participation ensures the product meets expectations.
o Reduces risk of software mismatch with user needs.
3. Flexibility to Changes
o Requirements can be modified at any stage.
o Suitable for projects with evolving needs.
4. Component Reusability
o Uses pre-built modules, reducing coding effort.
o Saves development time and cost.
5. Reduces Testing Time
o Continuous testing during module development minimizes major bugs.
o Early defect detection improves quality.
6. Encourages Prototyping
o Users can visualize and interact with prototypes before the final version.
o Reduces misunderstandings and ensures better design.

Disadvantages of RAD Model

1. Requires Strong User Commitment
o Success depends on active user participation.
o Delays in feedback can slow development.
2. Not Suitable for Large & Complex Projects
o Managing too many parallel modules can become chaotic.
o Hard to integrate multiple modules in massive systems.
3. High Resource Dependency
o Requires skilled developers, designers, and domain experts.
o Lack of expertise can lead to project failure.
4. Less Focus on Documentation
o Rapid iterations may lead to poor documentation.
o Can create maintenance issues in the long run.
5. Difficult to Manage Scalability
o Works best for small-to-medium projects.
o Scaling the system later can be challenging.
Questions related to RAD model:
1. What are the key phases of the RAD model?
2. What are the main objectives of using RAD in software development?
3. What are the main objectives of using RAD? (reducing development time, flexibility to
change)
4. What types of projects are best suited for the RAD model?
• Projects with frequent requirement changes.
• Small to medium-sized applications.

5. What industries commonly use the RAD model?

Banking & finance (e.g., online banking apps)
Mobile & web applications
E-commerce platforms
Healthcare systems requiring frequent updates

TOPIC:
Agile Model:
Key Features of the Agile Model:
1. Agile means swift or versatile (able to adapt )
2. Software development based on iterative development
3. Agile methods break tasks into smaller iterations, or parts do not directly involve long
term planning.
4. Frequent communication with stakeholders ensures that the final product meets their
needs.
5. Agile allows changes at any stage of development based on feedback.
6. Continuous Testing – Testing happens throughout the development cycle to ensure
quality.
7. Project scope and requirements are laid down at the beginning of the development
process.
8. Plans regarding the number of iterations, duration and scope of each iteration
defined in advance.
9. Each iteration considered as a short time “frame” in Agile process model (last from
one to four week)
10. Division of the entire project into smaller parts helps in minimize project risk and
reduce overall time delivery.
Following are the phases in the Agile model are as follows:
1. Requirements gathering:
• You must define the requirements.
• Explain the time and the effort needed to build the project
2. Design the requirements
• When you identify the requirements
• Sit with the stakeholders, explain the project, show them UML (Unified Modeling
Language) diagram
• Show them Mockup design, Prototypes for the project
• The design remains flexible, allowing changes as the project progresses.
3. Construction/iteration
• This is the development phase, where coding takes place in small iterations.
• Where designing and the developments starts, Small modules distributed to
the development team to process it individual.
4. Testing/ Quality assurance
• The Quality Assurance team examines the product's performance and looks for
thee bug.
5. Deployment
 • In this phase, the team issues a product for the user's work environment.
6. Feedback
• After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.

Agile Methodologies in SPM:

1. Scrum – Uses sprints (short work cycle to complete tasks), daily stand-up meetings,
and a product backlog.
2. Kanban – Visual workflow management with a Kanban board (a visual tool that helps
manage and organize work).
3. Extreme Programming (XP) – Focuses on coding best practices, frequent releases,
and customer involvement.
4. Lean Development – Minimizes waste and optimizes efficiency.
5. Feature-Driven Development (FDD) – Focuses on developing features in short cycles.

Advantages of the Agile Model:

1. Faster Delivery – Delivers working software quickly.
2. Flexible & Adaptable – Can handle changing requirements.
3. Better Quality – Continuous testing ensures fewer bugs.
4. Customer Satisfaction – Regular feedback improves the final product.
5. Reduced Risks – Issues are identified and fixed early.
6. Improved Teamwork – Encourages collaboration and self-organizing teams.
Disadvantages of the Agile Model:
1. Uncertain Budget & Timeline – Hard to predict exact costs and deadlines.
2. High Customer Involvement – Needs frequent feedback, which may not be possible.
3. Not Ideal for Large Projects – Complex, large-scale projects may struggle with
constant changes.
4. Less Documentation – Can make future maintenance harder.
5. Scope Creep – Frequent changes may lead to uncontrolled feature additions.
Classical Iterative Prototype Incremental Evolutionary RAD model Spiral model Agile model
waterfall model model model model
Basic, Inflexible, After User Module by Same as Time and Risk(If any Flexible,
Not for real every requirement module incremental cost question (Advanced
project. stages is not clear delivery but used for constraints related to And new
(No interaction feedback (means user (customer Large project (If the Risk like Technology)
between the can be itself don’t says if you (Requirement deadline or where is the
project with the given to know the are not able is not locked, the cost of risk (Parallel work)
user, Only user the exact to create it at at each the project evaluated at (Process
can interact in previous requirement once then module is given in every phase Divided into
the beginning stages. or user is you can requirement the then we Sprints or
of the project) Rest is confused like create one is prepared) question must go for Modules)
(Not flexible, same as this also I module and then RAD spiral
means once waterfall want, this deliver me model is model)
the model may be or then another suitable)
documentation not be) and lastly (Not for
is ready, you combine) (user small project
cannot modify (So for those interaction – obviously
inbetween the user, we use (easy to test, at every risk
project) to create a easy to level) evaluation is
sample or debug (reusability) not easy so
dummy because we we prefer
model to are this for large
show the developing project)
user , if it is module and (No early
liked by user performing lock on
then okay testing) requirement
otherwise (Requirement – means it is
again is locked at flexible to
modify and the change or
show to the beginning ) modify the
user until he requirement)
finalize)
(Less
(More costly, experience
time taking) developer
(No early team can
lock on work
requirement) because we
already
(High user analyzed the
involvement) risk at the
beginning of
the project)
TOPIC:

Dynamic Systems Development technique (DSDM):

DSDM is an Agile framework used for software development, focusing on business needs,
on-time delivery, and active user involvement. It ensures projects are delivered quickly and
efficiently while maintaining quality.

Key Principles of DSDM:

1. Focus on Business Needs – The project must provide real business value.
2. Deliver on Time – Uses timeboxing to ensure timely delivery.
3. Collaborate – Encourages teamwork and stakeholder involvement.
4. Never Compromise Quality – Quality is built-in from the start.
5. Build Iteratively – Develop in small cycles with continuous feedback.
6. Develop Incrementally – Deliver working software in parts.
7. Communicate Continuously & Clearly – Regular and open discussions.
8. Demonstrate Control – Project progress is monitored throughout.

Phases of DSDM:
1. Pre-Project – Define business goals
and project feasibility.
2. Feasibility Study – Assess technical
and financial viability.
3. Business Study – Define high-level
requirements and priorities.
4. Functional Model Iteration –
Develop prototypes and refine
requirements.
5. Design & Build Iteration – Finalize
design and develop working
software.
6. Implementation – Deploy the
solution and gather feedback.
7. Post-Project – Maintenance and
continuous improvement.
 Advantages of DSDM:

✔ Ensures business value and customer involvement.

✔ Fast delivery with clear priorities.
✔ Flexible and adapts to changes.
✔ Continuous testing ensures high quality.

Disadvantages of DSDM:

Requires active user involvement, which may be difficult.

Strict timeboxing may limit feature development.
Not suitable for small projects due to high overhead.

TOPIC:

Extreme Programming:

1. It is also a framework of Agile model.

2. It is used to improve software quality and responsiveness to customer requirements.
3. It emphasizes frequent releases, continuous feedback, and close collaboration
between developers and customers.

Key Principles of XP in SPM:

1. Continuous Feedback – Regular communication with stakeholders ensures quick
adjustments.
2. Simplicity – The simplest possible solution is implemented first.
3. Incremental Changes – Small, manageable updates reduce risks.
4. Customer Involvement – Continuous user feedback improves the final product.
5. Embracing Change – Requirements can evolve at any stage of development.
6. Quality Focus – Rigorous testing and pair programming ensure high-quality code.

Core Practices of XP:

Pair Programming – Two developers work together on the same code to improve quality.
Test-Driven Development (TDD) – Write tests before writing code to ensure correctness.
Continuous Integration (CI) – Frequent code integration to prevent conflicts.
Small Releases – Deliver working software frequently.
 Refactoring – Regularly improving code without changing its behavior.
Collective Code Ownership – Everyone is responsible for the codebase.
40-Hour Work Week – Avoids developer burnout.
On-Site Customer – A customer representative works closely with the team.
Coding Standards – Ensures consistency across the project.

XP Development Lifecycle in SPM:

1. Planning Phase – User stories are collected and prioritized.
2. Design Phase – Simple system architecture is created.
3. Coding Phase – Pair programming and continuous integration are applied.
4. Testing Phase – Automated unit tests validate functionality.
5. Release & Feedback – Small, frequent releases allow quick improvements.

Applications of Extreme Programming (XP): Some of the projects that are suitable to
develop using the XP model are given below:
• Small projects: XP model is very useful in small projects consisting of small teams as
face-toface meeting is easier to achieve.
• Projects involving new technology or Research projects: This type of project face
changing requirements rapidly and technical problems. So the XP model is used to
complete this type of project.
TOPIC:

Managing Interactive Processes:

Grady Booch, describes two levels of development for managing interactive processes:
1. The Macro Process
2. The Micro Process

1. The Macro Process (High-Level Management)

• Establish core requirements (conceptualization).

• Develop a model of the desired behavior (analysis).
• Create architecture (design).
• Evolve the implementation (evolution).
• Manage post delivery evolution (maintenance).

Key Characteristics:

Long-term planning and decision-making.

Defines major phases of development (e.g., requirement analysis, design, implementation,
testing, deployment).
Manages project risks, scheduling, and team coordination.
Uses iterative and incremental development to refine software over multiple cycles.

Example Activities in Macro Process:

• Project initiation and feasibility study.

• Architectural design and technology selection.
• Release planning and version control.
• Risk assessment and mitigation strategies.

2. The Micro Process (Low-Level Development Activities)

• The micro process focuses on the detailed technical work within each iteration or
phase of development.
• It deals with coding, debugging, unit testing, and small-scale design decisions.
Key Characteristics:

Short-term, iterative, and incremental development.

Continuous refinement of system components.
Applies object-oriented principles for modularity and reusability.
Includes tasks such as class design, function implementation, and debugging.
Example Activities in Micro Process:

• Writing and refactoring code.

• Implementing software components and objects.
• Performing unit tests and debugging.
• Applying design patterns for optimized solutions.

TOPIC:
Basics of Software Estimation:
Software estimation is a crucial aspect of Software Project Management (SPM) that helps in
planning, budgeting, and scheduling software projects. It involves predicting cost, effort,
time, and resources required for successful project completion.

The four basic steps in Software Project Estimation are –

• Estimate the size of the development product.
1. Determines the size of the software in terms of Lines of Code (LOC) or Function
Points (FP).
2. Used for effort and cost estimation.
• Estimate the effort in person-months or person-hours.
1. Predicts the person-months required to complete the project.
2. Common models: COCOMO, Function Point Analysis, Use Case Points.
• Estimate the schedule in calendar months.
1. Estimates the total time required for different phases (Requirement Analysis,
Design, Development, Testing).
• Estimate the project cost in agreed currency.
2. Determines the financial budget for development, testing, deployment, and
maintenance.
3. Can be done using techniques like COCOMO (Constructive Cost Model).

General project approach:

Project estimation is the process of predicting the time, effort, cost, and resources required to
complete a project successfully. A structured estimation approach helps in better planning,
budgeting, and risk management.
1. Define Project Scope
• Understand project requirements, objectives, and deliverables.
• Identify functional and non-functional requirements.
• Break down the project into modules and tasks (Work Breakdown Structure - WBS).
2. Generate an estimate of the software size
• Start with the statement of scope.
• Decompose the software into functions that can each be estimated individually.
• Calculate the size of each function.
• Derive effort and cost estimates by applying the size values to your baseline
productivity metrics.
• Combine function estimates to produce an overall estimate for the entire project.
3. Generate an Estimate of the Effort and Cost

• Identify the sequence of activities that need to be performed for the project to be
completed. Divide activities into tasks that can be measured.
• Estimate the effort (in person hours/days) required to complete each task.
• Combine effort estimates of tasks of activity to produce an estimate for the activity.
• Obtain cost units (i.e., cost/unit effort) for each activity from the database.
• Compute the total effort and cost for each activity.
• Combine effort and cost estimates for each activity to produce an overall effort and
cost estimate for the entire project.
4. Reconcile Estimates
1. Compare Estimates
o Compare the effort and cost estimates obtained from Step 3 with those from
Step 2.
o If both sets of estimates agree, the numbers are considered highly reliable.
2. Investigate Divergence (if estimates differ significantly)
o Check if the project scope is unclear or misinterpreted.
o Verify the function and activity breakdown for accuracy.
o Ensure that the historical data used is relevant, up-to-date, and correctly
applied.
5. Resolve Discrepancies and Finalize Estimates
1. Identify the Cause of Divergence
o Analyze discrepancies in estimation results.
o Find out if incorrect assumptions, outdated data, or missing factors caused the
variation.
2. Reconcile Estimates
o Adjust the estimates based on findings from the investigation.
o Ensure alignment between all estimation techniques to produce a final,
reliable project estimate.
Estimation Accuracy in SPM (Simplified Points)
• Estimation Accuracy shows how close the estimated values (effort, cost, time, or
resources) are to the actual values after project completion.
• High accuracy → Estimates are close to actual values (more reliable).
• Low accuracy → Estimates are far from actual values (more deviation).
• Helps in better planning, budgeting, and risk management.

Estimation Issues:
Project estimation involves several challenges that can impact accuracy and project
success. Below are some of the key challenges:
1. Uncertainty in Requirements
o At the beginning of the project, requirements are often unclear.
o Clients may not have a complete understanding of what they need.
o Without clear requirements, estimating effort and time becomes difficult.
2. Not Splitting Bigger Tasks
o Estimations are sometimes done at a high level, without breaking tasks into
smaller units.
o Lack of task breakdown can lead to overlooked activities and incorrect
estimates.
o Smaller, well-defined tasks provide better accuracy in estimation.
3. Idealistic & Optimistic Estimation
o Many estimations assume perfect conditions, ignoring real-world challenges.
o Issues like version maintenance, resource unavailability, and delays are often
overlooked.
o Over-optimistic estimates result in missed deadlines and cost overruns.
4. Estimation by the Wrong Person
o Estimation should be done by the developer or with their assistance.
o If estimation is done by someone unfamiliar with technical complexities, it can
lead to huge mismatches.
o Developers understand the actual effort required and can provide realistic
estimates.
5. Buffer & Dependencies
A buffer in project estimation is extra time or effort added to the estimate to handle
unexpected delays or risks.
o It is uncertain how much buffer should be included in an estimate.
o A 15-20% buffer is typically taken to account for unexpected project changes
as it progresses.
o External dependencies (third-party tools, APIs, vendor support) can also affect
timelines.
( A dependency in project estimation means that one task depends on another task,
resource, or external factor to be completed before it can start.
Example:
• A login page cannot be tested until the coding of the login functionality is complete.
• A project may depend on a third-party API that must be ready before integration. )

Numerical Problem on Estimation Accuracy in Software Project Management (SPM)

Problem Statement:
A software project was initially estimated to require 800 person-hours to complete. However,
after execution, the actual effort required turned out to be 900 person-hours.
Calculate:
1. Estimation Error (%)
2. Estimation Accuracy (%)
3. Estimate-to-Actual Ratio
Effort and Cost Estimation Techniques

Effort and cost estimation is essential for effective project planning. Below are five common
estimation techniques:

1. Top-Down Estimation

• The project effort is estimated as a whole first.

• Then, the total estimate is broken down into individual tasks.
• Pros: Quick and useful for early-stage planning.
• Cons: May be inaccurate if detailed task-level breakdown is not done.
Example:
• Estimated effort for a software project = 1000 hours
• Split into: Design (200h), Development (500h), Testing (300h)
2. Bottom-Up Estimation
• Individual tasks are identified first, and effort is estimated for each modules.
• Then we combine all estimations of modules together to form total project effort.
• Pros: More accurate since each task is considered separately.
• Cons: Time-consuming as it requires detailed task analysis.
Example:
• Task 1: Database design = 50 hours
• Task 2: API development = 120 hours
• Total Project Estimate = 50 + 120 + … = Final Estimate

3. Expert Judgment
• Relies on the experience of skilled professionals.
• Experts provide estimates based on past knowledge.
• Pros: Quick and useful when historical data is unavailable.
• Cons: Subjective and varies based on the expert’s experience.
Example:
• A senior developer estimates that building an eCommerce site will take 4 months
based on past experience.

4. Analogous Estimation (Historical Data-Based)

• Compare the estimation based on the similar existing project as a reference.
• Effort and cost are compared and adjusted based on differences.
• Pros: Useful when similar projects exist.
• Cons: May not be accurate if the new project differs significantly.
Example:
• A previous inventory management system took 6 months to develop.
• A new, similar project is expected to take approximately the same time.

5. Three-Point Estimation
• Uses three estimates:
o Optimistic (O) – Best-case scenario
o Most Likely (M) – Expected scenario
o Pessimistic (P) – Worst-case scenario
• The final estimate is calculated as:

• Pros: Reduces uncertainty and considers risk factors.

• Cons: Requires expert inputs for all three estimates.
Example:
• Optimistic estimate = 3 months
• Most likely estimate = 5 months
• Pessimistic estimate = 7 months
• Final Estimate = (3 + 4(5) + 7) / 6 = 5 months

Which Technique to Use?

• Early-stage estimation? → Top-Down, Expert Judgment
• Detailed task-level estimation? → Bottom-Up
• Reference from past projects? → Analogy
• Uncertain or risky projects? → Three-Point Estimation

Numerical Problems on Effort and Cost Estimation Techniques

Here are some numerical examples based on different estimation techniques:

1. Top-Down Estimation Example

A project is estimated to take 1200 person-hours. The project is broken into three main
phases:
• Design: 20% of total effort
• Development: 50% of total effort
• Testing: 30% of total effort
Solution:
• Design Effort = 20% of 1200 = 240 hours
• Development Effort = 50% of 1200 = 600 hours
• Testing Effort = 30% of 1200 = 360 hours
Total Effort: 240 + 600 + 360 = 1200 hours ✅

2. Bottom-Up Estimation Example

A project consists of four main tasks. Each task is estimated separately:
Task Name Estimated Effort (Person-Hours)
UI Design 100
Backend Development 300
Database Setup 200
Testing 150
Total Effort = 100 + 300 + 200 + 150 = 750 hours ✅

3. Expert Judgment Example

A senior developer estimates a mobile app development project based on past experience:
• Similar project took 8 months with 5 developers
 • The new project has more complex features, so an additional 2 months is added
Final Estimate: 8 + 2 = 10 months ✅

4. Analogous Estimation Example

A company previously developed a hotel booking system in 6 months with a cost of
$100,000.
Now, they are developing a restaurant reservation system, which is 80% similar to the
previous project.
Estimate Calculation:
• Estimated cost = 80% of $100,000 = $80,000 ✅
• Estimated time = 80% of 6 months = 4.8 months (~5 months) ✅

5. Three-Point Estimation Example

A project manager estimates a task using three estimates:
• Optimistic (O) = 20 days
• Most Likely (M) = 30 days
• Pessimistic (P) = 50 days
Using the formula:

Final Effort Estimate: 32 days ✅

TOPIC:
Cosmic function points:
• Cosmic Function Points (COSMIC FP) is a software sizing methodology used to
measure the functional size of software based on its data movement.
• Used to major the size and the complexity of the project
• Focus on the functionality of the project rather than going on the LOC or technical
details.
• Weight has been assigned to the projects according to their complexity.
• Total cosmic function points has been calculated by adding weight of all projects.
• Can be used for effort estimation, benchmarking, and productivity analysis.

Key Concepts of COSMIC FP

1. Data Movements: The functional size is determined based on how data moves within
the system. There are four types:
o Entry (E): Data enters the system from an external source.
o Exit (X): Data leaves the system to an external destination.
o Read (R): Data is retrieved from persistent storage.
o Write (W): Data is stored in persistent storage.

DIAGRAM SHOULD BE PASETED OVER HERE…..

TOPIC
COCOMO Model (Constructive cost model):
• It helps estimate the effort, cost, and schedule required for software development
based on the project size in thousands of lines of code (KLOC).
• Developed by Barry Boehm in 1981
• Using this model we can estimate the time (month) and number of people needed to
develop the project.

Types of COCOMO Models

COCOMO has three models based on the project complexity:
1. Basic COCOMO
o Provides a rough estimate based on the project size (KLOC).
o Uses a simple equation to estimate effort and time.
o Project Categories:
▪ Organic (Small, simple projects, e.g., payroll system)
▪ Semi-Detached (Medium complexity, e.g., operating systems)
▪ Embedded (Highly complex, e.g., real-time systems)
 2. Intermediate COCOMO
o Includes 15 cost drivers that adjust estimates based on factors like team
experience, tools, and project constraints.
[ Cost drivers are factors that influence the effort, cost, and time required for
software development. In COCOMO II, there are 17 cost drivers ]
3. Detailed COCOMO
o Extends Intermediate COCOMO with phase-wise effort estimation (analysis,
design, coding, testing).
o More precise and detailed.

COCOMO I vs COCOMO II:

COCOMO II Effort Estimation Formula

Where:
• E = Effort in Person-Months
• A = Constant (usually 2.94)
• Size = Estimated project size in KLOC (Thousands of Lines of Code)
• E = Exponent derived from Scale Factors (SF)
• EAF = Effort Adjustment Factor from Cost Drivers

################# END OF UNIT 2######################