Module 4

Software Project Planning &

Software Cost
Estimation
Business Case
● A business case provides justification for undertaking a project,
programme.
● It evaluates the benefit, cost and risk of alternative options and provides a
rationale for the preferred.
● It is first deliverable in IT project lifecycle.
● It provides an analysis of the organizational value, feasibility, costs,
benefits and risks of the project plan.
● For large project a business case may be large and formal document.
● The purpose of a business case is to show how an IT solution can create
business value.
Business Case
● Good IT business case should be—
1. Details all possible impacts, costs, benefits
2. Clearly compares alternatives
3. Objective includes all relevent information
4. Systematic in terms of summarizing findings
Business Case

● An IT project may be undertaken to:

1. Reduce cost
2. Create a new product or services
3. Improve customer service
4. Improve communication
5. Improve decision making
6. Improve processes
7. Improve reporting capabilities
Business Case
● A common way of thinking about a business case is using these five
elements:
1. Strategic context: The compelling case for change.
2. Economic analysis: Return on investment based on investment
appraisal of options.
3. Commercial approach: Derived from the sourcing strategy and
procurement strategy.
4. Financial case: Affordability to the organization in the time frame.
5. Management approach: Roles, governance structure, life cycle
choice, etc.
Business Case
● The business case is reviewed and revised at decision gates as
more mature estimates and information become available. The
approved business case provides a record of the decisions made
by governance about how to achieve the required return on
investment from the work. It documents the options considered
and it is normal practice to include the ‘do-nothing’ option as a
reference. Through this approach, the business case becomes a
record of the recommended option with rationale and evidence
to support the decision.
Business Case
● The presentation of the business case, if approved, results in the
formal startup of the project, programme or portfolio. The
sponsor owns the business case.
● It brings together the investment appraisal with evidence of
how the investment is intended to lead to realisation of the
intended benefits. All projects must have a business case that
demonstrates the value of the work and it is outlined during the
concept phase of the life cycle.
Process for Developing the Business Case :-
Step 1: select core team :-
● Developing the business case should include many of
stakeholders affected by project or involved in it’s delivery.
● Core team include managers, business specialist and users who
understand the requirement to be met and IT specialist who
understand the opportunities, limitations and risk associated
with IT.
•Advantages:
•Credibility :
A team made up of individuals from various organizational areas or
departments can provide access to critical expertise and information
that may not be readily accessible to others outside the particular
area.
•Alignment with organizational goals :
higher level managers can help connect the business case with the
organization’s long term strategic plan and mission. This alignment
may be beneficial in understanding and presenting how the
expected business value of the IT project will support the overall
goals and mission of the organization.
•Access to the real costs(salaries, training requirements etc) :
core members with certain expertise or access to important
information can help build more realistic estimates in areas such as
salaries, training requirements etc.
•Ownership :
A cross- functional team can spread a sense of ownership for the
business case. A project that includes other areas from the outset has
a better chance of reducing the political problems associated with
territorial domains.
•Agreement : if you develop a business case in isolation, it is very
likely that you will have to defend your assumptions and subjective
judgements in a competitive or political setting.
•Bridge building :- the core team may serve as an effective tool for
handling critics of the business case. one tactic may include critics
on the core team or to at least allow recognition and consideration
for their positions. this may lead to fewer surprises and attacks.
Step2: Define Measurable Organizational Value :-
Core team objective is to define the problem/opportunity & then
identify several alternatives that will provide direct and measurable
value to the organization.
Project’s overall goal and measure of success is referred as project’s
measurable organizational value(MOV)
•MOV must
•Measurable-measurement provides focus for the project team in
terms of actions.
•Provide value to organization– resources and time should not be
devoted to a project unless they provide some kind of value to the
organization.
•Be agreed on– all project stakeholders understand & agree to project
MOV
•Be verifiable– MOV must be verified to see project success
•Process for Developing MOV :-
[Link] the Desired Area of Impact :-
•The first step involves identifying the desired area of impact on IT
project such that it will play a supporting role to organization.
•One approach might be to adapt the criteria used by CIO magazine’s
Enterprise Value Awards.
•The guidelines summarized in Table below are used by the judges to
define IT value and provide a good starting point for developing the
MOV and business case.
2. Identify the Desired Value of the IT Project :-
● Once the desired area of impact is identified, the next step involves determining
the desired value the IT project will bring to the organization.
● This area can be tricky, but having a process helps. In simplest terms, we can
identify the value of an IT project by providing answers to the following four
questions:
1. Better—What does the organization want to do better? (For example, improve
quality or increase effectiveness?)
2. Faster—What does the organization want to do faster? (Increase speed, increase
efficiency, or reduce cycle times?)
3. Cheaper—What does the organization want to do cheaper? (Reduce costs?)
4. Do more—What does the organization want to do more than it is currently?
(Growth or expansion
3. Develop an Appropriate Metric :-
● Once there is agreement as to the value the IT project will bring
to the organization, the next step is to develop a metric or set of
metrics that are:
1. provides the project team with a target or directive,
2. sets expectations among all stakeholders,
3. provides a means for evaluating whether the project is a success
later on.
● In general, tangible benefits to the organization are easier to
define than intangible ones; however, this can be done with some
creativity.
[Link] a Time Frame for Achieving the MOV :-
● Once you have agreement on the target metrics that will provide the desired
impact to the organization, the next step is to agree on a specific time frame.
● For example, a company may focus on increasing profits or reducing costs,
but the question is: When will these results be achieved? Keep in mind that
the scheduled completion of the project is not the same thing as the agreed
upon time frame for achieving the MOV.
5. Verify and Get Agreement from the Project Stakeholders :-
● The next step in developing the MOV is to ensure that it is
accurate and realistic.
● In short, will the successful completion of this project provide
the intended value to the organization? And is the MOV
realistic? The development of the MOV requires a close
working relationship between the project manager and the
sponsor.
6. Summarize the MOV in a Clear, Concise Statement or Table :-
● After all stakeholders agree on the project’s impact and value, the MOV
(Measurable Organizational Value) should be written as one clear
statement or a table.
● This summary helps:
1. Ensure final agreement from everyone.
2. Give the project team a clear direction.
3. Set clear expectations for all stakeholders.
● The easiest way to write the MOV is to complete this sentence: “This
project will be successful if…”
● Example MOV:“This project will be successful if the website provides a
20% return on investment and attracts 500 new customers in its first year.”
MOV Table
Step 3: Identify Alternatives :-
1. Base Case Alternative – Understanding how things will
continue to work if the organization does nothing and keeps
everything the same.
● Determine costs of maintaining the current system over time
● Increased maintenance costs of hardware and software
● Possibility of more frequent system failures and downtime
[Link] Alternative Strategies-
•Changing the existing business processes without investing in IT
•Adopting or adapting an application developed by a different area or
department within the organization
•Reengineering the existing system
•Purchasing an off-the-shelf application package from a software vendor
•Custom building a new application using internal resources or
outsourcing the development to another company
Step 4: Define feasibility and Assess Risk :-
● Feasibility should focuses on whether a particular alternative is worth doing.
● Risk focuses on what can go wrong? What can go right?
1) Economic feasibility – too costly and/or not provide expected benefits
2) Technical feasibility – can infrastructure, IT staff, vendor support the
solution
3) Organizational feasibility – will solution be accepted by staff, will business
be disrupted
4) Other feasibilities - legal/ethical issues considered
 ● Risk focus on
1) Identification :- what can go wrong? What can go right?
2) Assessment :- What is the impact of each risk?
3) Response :- How can organization avoid or minimize the risk?
Step 5: Define Total Cost of Ownership(TCO) :-
● It refers to the total cost of acquiring , developing, maintaining, and
supporting the application system.
● TCO includes such cost as
1. Direct or Up-front costs : Initial purchase price of all h/w,s/w,
telecommunication equipment, all development and installation
cost etc..
2. Ongoing Costs : Salaries, training, upgrades, supplies,
maintenance etc..
3. Indirect Costs : Initial lost of productivity, time lost by user etc..
Step 6: Define Total Benefits of Ownership(TBO) :-
Benefits can arise from:
● Increasing high-value work—For example, a salesperson may
spend less time on paperwork and more time calling on customers.
● Improving accuracy and efficiency—For example, reducing
errors, duplication, or the number of steps in a process.
● Improving decision making—For example, providing timely and
accurate information.
● Improving customer service—For example, new products or
services, faster or more reliable service, convenience, and so on.
Step 7 – Analyze Alternative : Organizations analyze different project
alternatives mainly using financial models and scoring models.
1. Financial Models: These models focus on profitability and cash
flow. They help decide whether a project is financially worthwhile.
Common financial methods:
Payback Period: Time taken to recover the initial investment.
Break-even Point: When the project starts covering its own costs.
Return on Investment (ROI): Measures financial performance and
profitability.
Net Present Value (NPV): Considers the time value of money—money
today is worth more than money later.
2. Scoring Models: These models compare alternatives using multiple
criteria with assigned weights.
Key points:
● Combine quantitative (measurable) and qualitative (intangible) factors.
● Weights must total 100%, and multiplying weights × scores gives a
composite score.
● Useful for including intangible benefits that financial models may miss.
● Subjective—depends on management’s judgment or priorities.
● Can include reverse scoring (e.g., lower risk = higher score).
● Help create a more balanced and realistic business case, especially when
guided by past experience.
Step 8: Propose and Support the Recommendation :-
● Recommend one of the options, must be supported by your
analysis
● Opportunity to make an impression on the client or plan
sponsor
● Use template on next slide
Business Case Template :-
 Project Scope management
● Scope refers to all the work involved in creating the products of the
project and the processes used to create them.
● A deliverable is a product produced as part of a project, such as hardware
or software, planning documents, or meeting minutes.
● Project scope management includes the processes involved in
defining and controlling what is or is not included in a project.
● There are five main processes involved in scope management
1) Planning the scope
2) Defining the scope
3) Creating the WBS
4) Scope verification
5) Scope control
1) Scope Planning and the Scope Management Plan :-
● The scope management plan is a document that includes
descriptions of how the team will prepare the project scope
statement, create the WBS, verify completion of the project
deliverables, and control requests for changes to the project
scope.
● Key inputs include the project charter, preliminary scope
statement, and project management plan.
● Project Scope Initiation & Planning :-
1. Planning begins with the process that formally authorizes the
project manager and team to develop the scope management plan
2. Planning is a process for defining and documenting the
project work.
3. This involves Conceptualizing the Scope Boundary and
Developing the Scope Statement
• The Scope Boundary
1. Defining the scope boundary is the first step to establish what is,
and what is not , part of the project work to be completed by
project team.
2. Scope boundary act as fence to keep certain things in and other
things out.
• The Scope Statement :-
1. Provides a way to define the scope boundary.
2. A narrative of what deliverables or work-products the project
team will and will not provide throughout the project.
3. A first step that provides a high-level abstraction of the project’s
scope that will be defined in greater detail as the project
● Scope also clarifies what work is not included — meaning what
is outside the project.
● Scope is defined during requirement gathering.
A requirement is a condition or capability the system/product must
have to meet a contract, standard, or specification.
● There are several ways to collect requirements.
• Interviewing is effective ,very expensive and time consuming
• Group creativity and decision making tech are fast and less
expensive
• Questionnaires and survey.
● To do Document of the Requirement :-
To document requirements, the project team first reviews the
project charter and the stakeholder register.
Requirements are divided into categories like functional, service,
performance, quality, and training.
The requirements management plan explains how requirements
will be analyzed, documented, and managed.
A requirements traceability matrix (RTM) is a table that lists
each requirement, its details, and its status to ensure all
requirements are fulfilled.
● Example of Requirements traceability matrix (RTM)
2. Scope Definition :-
• Good scope definition is very important to project success because it
helps to improve the accuracy of time, cost and resource
estimates, it defines baseline for performance measurement and
project control .
• The main tool and techniques used in defining scope include
expert judgment, product analysis, alternative identification.
• Outputs are project scope statement and project document updates.
• Project scope can be defined in terms of deliverables.
• These deliverables can be divided into project-oriented
deliverables and product oriented deliverables.
• Project-Oriented Scope/ deliverables
• Deliverables that support the project management and IT
development processes defined in the Information
Technology Project Methodology (ITPM).
• Examples :- Business case, project charter and project plan,
etc.
• Product-Oriented Scope / deliverables
• Focuses on identifying High-level features and
functionality of the application system
• Examples :- Add new customer, look up customer balance,
print daily sales report by region, etc.
3. Creating the Work Breakdown structure :-
● A WBS is a deliverable-oriented grouping of the work involved in
a project that defines the total scope of the project.
● A WBS is a foundation document that provides the basis for planning
and managing project schedules, costs, resources, and changes.
● Decomposition is subdividing project deliverables into smaller pieces.
● The WBS represents a logical decomposition of the work to be
performs and focuses on how the product, service, or result is naturally
subdivided
● It is an outline of what work is to be performed.
● The WBS decomposes , or subdivides the project into smaller
components and more manageable unit of work called work package.
● A work package is a task at the lowest level of the WBS
• Developing WBS :-
• Take example of electronic commerce project.
• Following are activities that we need to do in order to produce test result
• Review the test plan with client– to decide what will be testing?,
how will be testing?, when the test will carried out?
• Once we have inform the client that we will test the system ,
we basically carried out test outlined in the test plan
• Once we have collect the test result we need to analyze them
• After we analyze the result, we will need to summarize them in the
form of report and presentation
• If all goes well client will approve/ sign-off then, we can move to
implementation. If all does not go well , we need to address and fix
problem
• Deliverable Structure Chart for electronic commerce project
The WBS Should Follow the Work Package Concept
•The WBS Dictionary and Scope Baseline :-
•A WBS dictionary is a document that describes detailed
information about each WBS item
•The format of WBS dictionary can vary based on project needs
•Define short paragraph describing each work package.
•The approved project scope statement and its associated WBS
and WBS dictionary form the scope baseline, which is used to
measure performance in meeting project scope goals
● Advice for Creating a WBS and WBS Dictionary :-
1. WBS should focus on deliverables, not just activities.
2. It must support the project’s MOV by including all tasks needed
for the scope.
3. Detail should be enough for planning, monitoring, and
controlling schedule and budget.
4. Too little detail misses tasks; too much causes
micromanagement.
5. Create the WBS with input from the people doing the work.
6. Lack of coordination while creating it can cause confusion.
4. Scope Verification :-
● It is very difficult to create a good scope statement and WBS for
a project
● It is even more difficult to verify project scope and minimize
scope changes.
● Scope verification involves formal acceptance of the completed
project scope by the stakeholders
● Acceptance is often achieved by a customer inspection and then
sign-off on key deliverables
● Scope verification ensures that:
1. The project scope is clear, accurate, and complete.
2. Stakeholders accept the scope.
3. Standards are in place so the scope is completed correctly.
4. Completing the scope will achieve the project’s MOV.
● Tool: Scope Verification Checklist
1. MOV: Is the MOV clearly defined and agreed?
2. If not, scope changes may occur later, affecting time and budget.
3. Deliverables: Are they clear, measurable, and do they support
the MOV?
4. Quality Standards: Do they confirm that work is completed
correctly as per required standards?
5. Milestones: Do they show that each deliverable is completed,
reviewed, and accepted before moving to the next?
5. Scope Change control :-
● Ensures that any changes to the project’s scope will help the
project achieve its MOV.
● Keeps the “triple constraint” in balance. i.e., an increase in
scope will require an increase in the project’s schedule and
budget.
● Scope control involves controlling changes to the project scope
•Goals of scope control are to:
•Assure changes are processed according to procedures developed
as part of integrated change control
•Manage changes when they occur
•Ensures that any changes to scope will be beneficial
•Concerned with--
•Scope Grope – i.e., scope poorly defined– occur when trouble in
understanding what project is supposed to accomplish by project team
and sponsor
•Scope Creep – i.e., increasing featurism– adding small yet time and
resource consuming features to the system once scope has been
approved
•Scope Leap – i.e., drastic change in project direction or the project’s
MOV
•Tools:
•Scope Change Request Form
● Benefits of Scope Control:
1. Helps the project manager stay in control of the project.
2. Gives the project manager authority to manage schedule and
budget without pressure to accept unwanted scope changes.
3. Keeps the project team focused and on track.
4. Prevents unnecessary work.
● Software Estimation
1) Size Estimation
2) Cost Estimation
1) Size Estimation:
● Size is the main factor used to estimate everything in a project.
● Once the size is estimated, the required effort and duration of the
project can be calculated.
● From the effort, the project cost is estimated, which helps in price
negotiation with the customer.
● Other planning activities like staffing and scheduling also depend on
these estimates.
● For large projects, creating an accurate plan becomes difficult because
the project scope and staff may change over time.
● Project size measures how complex the problem is, based on the effort
and time needed to develop the product.
● Measures :-
1. “A Measure provides a quantitative indication of the extent,
amount, dimension, capacity or a size of product or process.”
2. “Measurement” is the act or a process of determining a
measure
● Metric :-
1. A quantitative measure of the degree to which the system,
component or a process possesses a given attribute.”
2. Two metrics are used to estimate the size: lines of code(LOC)
and function point(FP).
● LOC (Lines of Code) Metric
1. LOC is the simplest and most popular metric for estimating project size.
2. It measures size by counting the number of source code instructions,
excluding comments and header lines.
3. LOC is easy to count after the project is completed, but difficult to
estimate before development.
4. Early estimation requires a systematic guess: the project is divided into
modules and sub-modules.
5. Past experience with similar projects helps predict LOC for the smallest
modules.
6. These module-level estimates are combined to estimate the total project
size.
•Example :-
•Consider this snippet of code as an example:
num1 = 12
num2 = 13
#Print the addition value
print(num1+num2)
•In this example we have:
• 4 Physical Lines of Code
• 3 Logical Lines of Code (for statement and printf statement)
• 1 Comment Line
LOC as measure of problem has several limitations:
● LOC depends on coding style: Different programmers write
code differently, so LOC varies a lot and is not a reliable
measure.

● Measures only coding: LOC looks only at the number of lines

written, but software development includes many other steps
like design, testing, etc.

● Does not show code quality: More lines do not mean better or
efficient code. Sometimes shorter code is much better.
● If someone uses libraries or advanced languages, LOC becomes
low, but effort may still be high.
● Not linked to complexity: Two programs may have the same
LOC, but one may be much more complex and harder to build.
● Hard to estimate before coding: You cannot accurately predict
LOC from the requirements or design.
● Accurate LOC can be known only after coding is completed.
Function Point
Function Point Metric
● Function Point Metric (FPM) was introduced by Albrecht.
● It solves many problems that we face with the Lines of Code
(LOC) metric.
● Big advantage:
● FPM helps us estimate the size of a software product directly
from the problem specification, even before coding starts.
● This is opposite of LOC, where we can calculate size only after
the complete code is written
● Main idea of FPM: The size of the software depends on how
many functions/features the system provides.
● More features/functions → larger software size.
Fewer features/functions → smaller software size.
● Every function usually:
takes some input,
processes or transforms that input, and
produces some output.
•Example :-
•The query book feature of a Library Automation Software takes the
name of the book as input and display it’s location and the no. of
copies available.
•Similarly, issue book and return book feature produce their output
based on corresponding input data.
•Thus computation of number of input and output data values to a
system gives some indication of number of functions supported by
the system
•Function point is computed in three steps.
•The first step is to compute the UFP Unadjusted Function Point
•UFP is refined to reflect the differences in the complexities of the
different parameters of the expression for UFP computation
•Final step, FP is computed by final refining UFP to account for the
specific characteristic of the project that can influence the
development effort
•UFP=(Number of inputs)*4 + (Number of outputs)*5 +
(Number of inquiries)*4 + (Number of files)*10 + (Number of
interfaces)*10
•The meaning of the different parameters of this expression is as
follows:
1) Number of inputs:
•Each data item input by the user is counted. Data inputs should be
distinguished from user inquiries.
•Inquiries are user commands such as print-account-balance. Inquiries are
counted separately.
•It must be noted that individual data item input by the user are not simply
added up to compute the no. of inputs, but a group of related inputs are
considered as single input.
•While entering data as Employee payroll software, the data items name,
age,address, phone no etc. are together considered as single input.
2) Number of outputs:
•The outputs considered refer to the reports printed, screen outputs,
error message produced etc.
•While computing no. of outputs the individual data items within a
report are not considered , but set of related data items is counted as one
output.
3) Number of Inquiries:
•It is the number of distinct interactive queries which can be made by
the users.
•These inquiries are the user commands which require specification by
the system
4) Number of files:
•Each logical file is counted.
•A logical file implies a group of logically related data.
•Thus, logical file include data structures and physical files

5)Number of interfaces:
•the interfaces considered are the interfaces used to exchange
information with other system.
•E.g. Data files on tapes, disks, communication link with other
system.
•The computed UFP is refined in next step.
•The complexity level of each of the parameter is graded as simple,

average or complex
•Technical complexity factor (TCF) :-
•A technical complexity factor (TCF) for the project is
computed and the TCF is multiplied with UFP to yield FP.
•The TCF expresses the overall impact of various project
parameters that can influence the development effort such as
high transaction rates, response time requirements, scope for
reuse, etc.
•Albrecht identified 14 parameters that can influence the
development effort.
•Each of this 14 factors is assigned a value from 0(not present)
to 6(strong influence)
•The resulting numbers are summed, yielding the total degree of
influence(DI). TCF is computed as (0.65+0.01*DI)
•DI can vary from 0 to 84, TCF can vary from 0.65 to 1.35.
•FP is given as the product of UFP and TCF that is
FP=UFP*TCF
 2) Cost Estimation
1) COCOMO Model I
I. Basic COCOMO
II. Intermediate COCOMO
III. Embedded COCOMO / Detailed COCOMO
2) COCOMO Model II
I. Stage I
II. Stage II
III. Stage III
COCOMO- Heuristic Estimation Techniques

•COCOMO(Constructive Cost estimation Model) was proposed by

Boehm, 1981.
•Boehm states that any s/w development project can be classified
into three categories based on development complexity:
•Organic
•Semidetached
•Embedded
•In order to classify them into categories , Boehm requires us to
consider not only the characteristic of the product but also those of
development team and development environment.
1) Basic COCOMO Model
1) Basic COCOMO
•Estimating most of the small to medium sized projects in quick and
rough fashion.
•Basic COCOMO model takes the form

Where E is effort applied in person-months.

D is develop time in months
Coefficients for Basic COCOMO
•When effort and development time are known, the average staff
size to complete the project may be calculated as:
•Example 1 :-
•Suppose that a project was estimated to be 400 KLOC.
•Calculate the effort and development time for each of the three
modes i.e., organic, semidetached and embedded.
•Solution :-

M
 M

M
•Example2:

M
2. Intermediate COCOMO Model :-
 2. Intermediate COCOMO :-
•The Basic COCOMO model considers only the Effort & time to
determine the product size.
•In order to obtain an accurate estimation of effort & project duration,
the effect of all relevant parameters must be taken into account.
•The intermediate COCOMO model recognizes this fact & refines the
initial estimate obtained through basic COCOMO expression by using
a set of 15 cost drivers based on various attributes of s/w development.
Cost Driver in Intermediate COCOMO Model
•Intermediate COCOMO equations :

•Multiplying factors for all 15 cost drivers are multiplied to get EAF
•EAF(Effort Adjustment Factor): 0.9 to 1.4
3. Embedded COCOMO / Detailed COCOMO :-
3. Embedded COCOMO / Detailed COCOMO :-
•Most large systems are made up of several smaller subsystems.
These subsystems may have widely different characteristics.
•For Eg – some subsystems may be considered as organic type,
some semi detached & some embedded.
•Even the development complexity of these subsystems may be
different.
•The COCOMO model considers these differences & estimate the
Effort & development time as the sum of the estimates for
individual subsystems
•The cost of each subsystem is estimated separately.
•This approach reduces the margin of error in the final estimate.
COCOMO-II
•The COCOMO model was proposed in 1980’s
•The present day s/w project are much larger in size and reuse
existing s/w to develop new products.
•To make COCOMO suitable in changed scenario, Boehm
proposed COCOMO 2
•COCOMO 2 provides three increasingly detailed cost estimation
models
•These can be used to estimate project cost at different phases of
software .
•It is actually a hierarchy of Estimation models that address the
following areas:
•Application Composition Model :Used during the early stages of
S.E., when prototyping of user interfaces,consideration of s/w &
system Interaction, assessment of performance & evaluation of
technology maturity are paramount.
•Early design Stage Model : Used once requirements have been
stabilized & basic s/w architecture has been established.
•Post-Architecture stage Model : Used during the construction of the
s/w
Stage I : Application composition model :-
Stage I : Application composition model :-
•An indirect s/w measure that is computed using counts of the
number of :
•Screens (user Interfaces)
•Reports
•Components
•Each object(component) instance is classified into one of 3
complexity levels ( simple, medium, difficult)
Step for Application composition model :-
Stage II: Early Design estimation model :-
Stage II: Early Design estimation model :-

•It is used at the Stage – II in COCOMO -II models and supports

estimation in early design stage of project.
•Base equation used in COCOMO – II models is as follows –
PM nominal = A * (size)B

where PM nominal= Effort for the project in person months

A = constant representing the nominal productivity where A = 2.5
B = Scale Factor
Size = size of the Software
•The basic assumption stands as effort on project usually increases
faster than size of product.
•However, value of ‘B’ is computed on basis of scaling factors that
may cause loss of productivity corresponding to an increase in the
size as follows –
● This model uses five scaling factors that affects B value
● They are
1. Precedentdness (PREC)
2. Development Flexibility (FLEX)
3. Architecture/Risk Resolution (RESL)
4. Team Cohesion (TEAM)
5. Process Maturity (PMAT)
The value of B can be calculated as:
B=0.91 + 0.01 * (Sum of rating on scaling factors for the
project)
When all scaling factors are high, the best value of B is obtained
(B=0.91).
When all scaling factors are very low, the worst value of B is
obtained (B=1.23).
So B value range between 0.91 to 1.23
● There are seven early design cost drivers
i. Product Reliability and Complexity (RCPX)
ii. Required Reuse (RUSE)
iii. Platform Difficulty (PDIF)
iv. Personnel Capability (PERS)
v. Personnel Experience (PREX)
vi. Facilities (FCIL)
vii. Schedule (SCED)
•These values are used for the calculation of a factor called “Effort
multiplier” which is the product of all seven early design cost
drivers.
•These factors are used for the calculation of adjusted effort as
given below:
PM effort may very even up to 400% from
adjusted
PM
nominal
Hence PM is the fine tuned value of effort
adjusted
in the early design phase
Stage III: Post Architectural Model
Stage III: Post Architectural Model
It is the most detailed estimation model and is
intended to be used when a software life cycle architecture has been
completed.
This model is used in the development and maintenance of
software products in the application generators, system integration
or infrastructure sectors.
Formula for Post Architectural Model
● EM : Effort multiplier which is the product of 17 cost drivers.
● There are 17 cost drivers in Post Architecture model.
● These are rated on a scale of 1 to 6 as given below :
•The list of seventeen cost drivers
i. Reliability Required (RELY)
ii. Database Size (DATA)
iii. Product Complexity (CPLX)
iv. Required Reusability (RUSE)
v. Documentation (DOCU)
vi. Execution Time Constraint (TIME)
vii. Main Storage Constraint (STOR)
viii. Platform Volatility (PVOL)
ix. Analyst Capability (ACAP)
x. Programmers Capability (PCAP)
xi. Personnel Continuity (PCON)
xii. Analyst Experience (AEXP)
xiii. Programmer Experience (PEXP)
xiv. Language & Tool Experience (LTEX)
xv. Use of Software Tools (TOOL)
xvi. Site Locations & Communication Technology between Sites
(SITE)
xvii. Schedule (SCED)
Self Learning Topics:
1. Project selection and Approval
2. Project charter