Software project estimation

Unit 4
Objectives
• To introduce the fundamentals of software costing and
pricing
• To describe three metrics for software productivity
assessment
• To explain why different techniques should be used for
software estimation
• To describe the principles of the COCOMO 2
algorithmic cost estimation model
Project Management is an integrated part of software development.

 It refers to manage the complete software project.

 The goal is to provide the necessary support for development

proceed smoothly and reduce any development problem. Its basic task
to ensure that, once a development process is chosen, it is implemente
optimally.

 Effective s/w project management focuses on the 4 P’s:

The People, The Product, The Process, and The Project.
The People
 People-intensive
 SEI has developed a “People ManagementCapability
Maturity Model” (PM-CMM):

 This model defines the key practice areas for s/w

people: recruitment, selection, performance management,
training, compensation, career development, organization
and work design, and team/culture development.
 Team leaders: Motivation, Innovative, Problem solving,
influence and team building.
The Product
 Product objectives: Overall goals (from the customer’s point of
view) without considering how these goals will be achieved.

 Scope: identifies its primary data, functions, and behaviors.

 Alternative Solutions: Once the project objectives and scope

are understood, alternative solutions are considered. The
alternative solutions enable managers to select a “best” approach,
given the constraints imposed by the delivery deadlines,
budgetary restrictions, personnel availability,
technical interfaces etc.
The Process
 The way in which we produce the software.

 Provides a framework from which a comprehensive plan for s/w

development can be established.

 Problem is to select the appropriate process model.

 The project manager must decide which process model is appropriate for:
 The customer who have requested the product
 The characteristics of the product itself, and
 The projcect environment in which the s/w team works.
The Project
 In order to manage successful s/w projects, we must understand what
can go wrong and how to do it right. Ten signs that indicate the project is
in danger:

i. S/w people don’t understand their customer’s need.

ii. The product scope is poorly defined.
iii. Changes are managed poorly.
iv. The chosen technology changes.
v. Business needs change (or ill defined).
vi. Deadlines are unrealistic.
vii. Users are resistant.
viii. Sponsorship is loss
ix. The project team lacks people with appropriate skills.
x. Managers avoid practices and less ones learned.
Metrics for Size Estimation
lines of code (LOC)
The expected value for estimation variable has been determined, historical
LOC or FP data are applied and person months, costs etc are calculated
using the following formula.

Productivity = KLOC / Person-month

Quality = Defects / KLOC
Cost = Cost $ / LOC
Documentation = pages of documentation / KLOC
• Where,
• KLOC stand for no. of lines of code (in thousands).
• Person-month stand for is the time(in months) taken by developers to
finish the product.
• Defects stand for Total Number of errors discovered
Advantages:
 Simple to measure
 It can be determined uniquely by automated tools
once the project is completed.

Drawbacks:
 It is defined on code. For example it can’t measure
the size of specification.
 It characterize only one specific view of size, name
length, it takes no account of functionality or
complexity.
 Bad s/w design may cause excessive line of code
 It is language dependent.
In this example we have:
1 Physical Line of Code (LOC)
2 Logical Lines of Code (LLOC) (for statement
and printf statement)
1 comment line
• Advantages
• Easily counted
• Many existing methods use LOC as key input.

• Disadvantages
• Depend upon programming language
• Difficult in early stage
Function point (FP)
• Function oriented metrics focus on program
"functionality" or "utility".

• Five information domain characteristics are determined

and counts for each are provided and recorded in a table.
• Number of user inputs
• Number of user outputs
• Number of user inquires
• Number of files
• Number of external interfaces
To compute function points, we use
FP = count-total X [ 0.65 + 0.01 * SUM(Fi) ]
• Where, count-total is the sum of all entries obtained
from fig.

• Fi(I= 1 to 14) are complexity adjustment values based

on response to questions(1-14) given below. The
constant values in the equation and the weighing
factors that are applied to information domain are
determined empirically.
• Rate each factor on a scale of 0 to 5
• 0 - No influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
• Count-total is sum of all FP entries.
• Fi
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational
environment?
6. Does the system require on-line entry?
7. Does the on-line data entry require the input transaction to be
built over multiple screens or operations?
8. Are the inputs, outputs, files, or inquiries complex
9. Is the internal processing complex?
10. Is the code designed to be reusable?
11. Are master files updated on-line?
12. Are conversion and installations included in the design?
13. Is the system designed for multiple installations in different
organizations?
14. Is the application designed to facilitate change and ease of use
by the user?
• Once function points have been calculated,
productivity, quality, cost and documentation can
be evaluated.

• Productivity = FP / person-month
Quality = defects / FP
Cost = $ / FP
Documentation = pages of documentation / FP
Project Cost Estimation Approach
• Basic activity in project planning and
measurement.

• Three categories

1. Heuristic technique
2. Empirical technique
3. Analytical technique
Heuristic technique

• This techniques basically uses the concept of learning

from the previous project and estimate the cost.
• The objective is to find a similar system produced
earlier and through knowing how the properties of the
new system vary from the existing one.
• COCOMO is one of this type of models example.
Analytical and Empirical technique

• Empirical estimation technique are based on

the data taken from the previous project and
some based on guesses and assumptions.

There are many empirical estimation technique

but most popular are
• Expert Judgement Technique
• Delphi Cost Technique
Expert judgement technique:
• An expert makes an educated guess of the problem size
after analyzing the problem thoroughly.
• Expert estimate the cost of different components that is
modules and sub modules of the system.

Disadvantages:
• Human error, considering not all factors and aspects of the
project, individual bias, more chances of failure.
• Estimation by group of experts minimizes factors such as
individual oversight, lack of familiarity with a particular
aspect of a project, personal bias and desired to win a
contract through overly optimistic estimate.
Delphi cost estimation

Experts Group

Estimation
E By

Coordinators

Role of Members: Coordinator provide a copy of

Software Requirement Specification(SRS) document
and a form of recording it cost estimate to each
estimator.
This process is Iterated for several rounds.
Halstead metrics are :

• Halstead Program Length – The total number of operator occurrences and the total
number of operand occurrences.
N = N1 + N2
And
• estimated program length is, N = n1log2n1 + n2log2n2

• Halstead Vocabulary – The total number of unique operator and unique operand
occurrences.
n = n1 + n2

• Program Volume – Proportional to program size, represents the size, in bits, of space
necessary for storing the program. Minimum number of bits needed to encode program.

• V = Size * (log2 vocabulary)
= N * log2(n)
Counting rules for C language –
• Comments are not considered.
• The identifier and function declarations are not considered
• All the variables and constants are considered operands.
• Global variables used in different modules of the same program are counted as
multiple occurrences of the same variable.
• Local variables with the same name in different functions are counted as
unique operands.
• Functions calls are considered as operators.
• All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control
statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
• In control construct switch ( ) {case:…}, switch as well as all the case statements
are considered as operators.
• The reserve words like return, default, continue, break, sizeof, etc., are
considered as operators.
• All the brackets, commas, and terminators are considered as operators.
• GOTO is counted as an operator and the label is counted as an operand.
• The unary and binary occurrence of “+” and “-” are dealt separately. Similarly
“*” (multiplication operator) are dealt separately.
main()
{
int a, b, c, avg;
scanf("%d %d %d", &a, &b, &c);
avg = (a + b + c) / 3;
printf("avg = %d", avg);
}

The unique operators are:

main, (), {}, int, scanf, &, =, +, /, printf, ',', ;

The unique operands are:

a, b, c, avg, "%d %d %d", 3, "avg = %d"
Risk Management

- Introduction
- Risk identification
- Risk projection (estimation)
- Risk mitigation, monitoring, and
management

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

Project Risks

What can go wrong?

What is the likelihood?
What will the damage be?
What can we do about it?
What Is Software Risk?
• Risk is an expectation of loss, a potential problem
that may or may not occur in the future.
• It is generally caused due to lack of information,
control or time.
• A possibility of suffering from loss in software
development process is called a software risk.
• Loss can be anything, increase in production cost,
development of poor quality software, not being able
to complete the project on time.
Types of software risks
• Software risk exists because the future is
uncertain and there are many known and
unknown things that cannot be incorporated
in the project plan.
• A software risk can be of two types
– (1) internal risks that are within the control of the
project manager and
– (2) external risks that are beyond the control of
project manager.
Definition of Risk
• A risk is a potential problem – it might happen and
it might not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions, places,
etc.
– Risk involves choice and the uncertainty that choice
entails
• Two characteristics of risk
– Uncertainty – the risk may or may not happen, that is,
there are no 100% risks (those, instead, are called
constraints)
– Loss – the risk becomes a reality and unwanted
consequences or losses occur
Risk Categorization – Approach #1
• Project risks
– They threaten the project plan
– If they become real, it is likely that the project schedule
will slip and that costs will increase
• Technical risks
– They threaten the quality and timeliness of the software
to be produced
– If they become real, implementation may become
difficult or impossible
• Business risks
– They threaten the posibility of the software to be built
– If they become real, they put risk in the project or the
product
Risk Categorization – Approach #1 (continued)

– Market risk – building an excellent product or

system that no one really wants
– Strategic risk – building a product that no longer
fits into the overall business strategy for the
company
– Sales risk – building a product that the sales force
doesn't understand how to sell
– Management risk – losing the support of senior
management due to a change in focus or a change
in people
– Budget risk – losing budgetary or personnel
commitment
Risk Categorization – Approach #2
• Known risks
– Those risks that can be uncovered after careful evaluation of
the project plan, the business and technical environment in
which the project is being developed, and other reliable
information sources (e.g., unrealistic delivery date)
• Predictable risks
– Those risks that are guesses from past project experience
(e.g., past turnover)
• Unpredictable risks
– Those risks that can and do occur, but are extremely difficult
to identify in advance
Steps for Risk Management
1) Identify possible risks; recognize what can go
wrong
2) Analyze each risk to estimate the probability that it
will occur and the impact (i.e., damage) that it will
do if it does occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and
catastrophic
4) Develop a contingency plan to manage those risks
having high probability and high impact
Steps for Risk Management
Identify possible risks; recognize what
can go wrong

Analyze each risk to estimate the

probability that it will occur and the
impact (i.e., damage) that it will do if it
does occur

Rank the risks by probability and impact

- Impact may be negligible, marginal, critical,
and catastrophic

Develop a contingency plan to manage those risks

having high probability and high impact
Risk Identification
Background
• Risk identification is a systematic attempt to specify threats
to the project plan
• By identifying known and predictable risks, the project
manager takes a first step toward avoiding them when
possible and controlling them when necessary
• Generic risks
– Risks that are a potential threat to every software project
• Product-specific risks
– Risks that can be identified only by those a with a clear
understanding of the technology, the people, and the
environment that is specific to the software that is to be built
– This requires examination of the project plan and the statement of
scope
– "What special characteristics of this product may threaten our
project plan?"
Risk Item Checklist

Used as one way to identify risks

Focuses on known and predictable risks in

specific subcategories (see next slide)

Can be organized in several ways

•A list of characteristics relevant to each risk
subcategory
•Questionnaire that leads to an estimate on the
impact of each risk
•A list containing a set of risk component and drivers
and their probability of occurrence
Known and Predictable Risk Categories
1-Product size risks associated with overall size of the software to be built

2-Business risks associated with constraints imposed by management or the marketplace

impact

3-Customer risks associated with sophistication of the customer and the developer's ability to
characteristics communicate with the customer in a timely manner

4-Process risks associated with the degree to which the software process has been defined
definition and is followed

5-Development risks associated with availability and quality of the tools to be used to build the
environment project

6-Technology to risks associated with complexity of the system to be built and the "newness" of
be built the technology in the system

7-Staff size and risks associated with overall technical and project experience of the software
experience engineers who will do the work
Recording Risk Information
Project: Embedded software for XYZ system
Risk type: schedule risk
Priority (1 low ... 5 critical): 4
Risk factor: Project completion will depend on tests which
require
hardware component under development. Hardware
component
delivery may be delayed
Probability: 60 %
Impact: Project completion will be delayed for each day that
hardware is unavailable for use in software testing
Monitoring approach:
Scheduled milestone reviews with hardware group
Contingency plan:
Modification of testing strategy to accommodate delay
using
software simulation
Estimated resources: 6 additional person months beginning
7-1-96
Questionnaire on Project Risk
(Questions are ordered by their relative importance to project success)

1) Have top software and customer managers formally

committed to support the project?
2) Are end-users enthusiastically committed to the project
and the system/product to be built?
3) Are requirements fully understood by the software
engineering team and its customers?
4) Have customers been involved fully in the definition of
requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?

(More on next slide)

Questionnaire on Project Risk (continued)

7) Does the software engineering team have the right mix

of skills?
8) Are project requirements stable?
9) Does the project team have experience with the
technology to be implemented?
10) Is the number of people on the project team adequate
to do the job?
11) Do all customer/user constituencies agree on the
importance of the project and on the requirements for
the system/product to be built?
Risk Components and Drivers
• The project manager identifies the risk drivers that affect
the following risk components
– Performance risk - the degree of uncertainty that the product
will meet its requirements and be fit for its intended use
– Cost risk - the degree of uncertainty that the project budget
will be maintained
– Support risk - the degree of uncertainty that the resultant
software will be easy to correct, adapt, and enhance
– Schedule risk - the degree of uncertainty that the project
schedule will be maintained and that the product will be
delivered on time
• The impact of each risk driver on the risk component is
divided into one of four impact levels
– Negligible, marginal, critical, and catastrophic
• Risk drivers can be assessed as impossible, improbable,
probable, and frequent
Risk Projection (Estimation)
Background
• Risk projection (or estimation) attempts to rate each
risk in two ways
– The probability that the risk is real
– The consequence of the problems associated with the risk,
should it occur
• The project planner, managers, and technical staff
perform four risk projection steps (see next slide)
• The intent of these steps is to consider risks in a
manner that leads to prioritization
• By prioritizing risks, the software team can allocate
limited resources where they will have the most
impact
Risk Projection/Estimation Steps
1) Establish a scale that indicates the
probability of risk being real. (e.g., 1-low, 10-
high)
2) Enlist the consequences of the risk
3) Estimate the impact of the risk on the
project and product
4) Note the overall accuracy of the risk
projection so that there will be no
misunderstandings
Contents of a Risk Table
• A risk table provides a project manager with a simple technique
for risk projection
• It consists of five columns
– Risk Summary – short description of the risk
– Risk Category – one of seven risk categories
– Probability – estimation of risk occurrence based on group
input
– Impact – (1) catastrophic (2) critical (3) marginal (4)
negligible
– RMMM – Pointer to a paragraph in the Risk Mitigation,
Monitoring, and Management Plan
Risk Summary Risk Category Probability Impact (1-4) RMMM
Risk Mitigation, Monitoring, and
Management
Background

• An effective strategy for dealing with risk must

consider three issues
(Note: these are not mutually exclusive)
– Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy
and is achieved through a plan
– Example: Risk of high staff turnover (see next slide)

(More on next slide)

Background (continued)
Strategy for Reducing Staff Turnover
 Meet with current staff to determine causes for turnover (e.g.,
poor working conditions, low pay, competitive job market)
 Mitigate those causes that are under our control before the project
starts
 Once the project commences, assume turnover will occur and
develop techniques to ensure continuity when people leave
 Organize project teams so that information about each
development activity is widely dispersed
 Define documentation standards and establish mechanisms to
ensure that documents are developed in a timely manner
 Conduct peer reviews of all work (so that more than one person is
"up to speed")
 Assign a backup staff member for every critical technologist
Background (continued)
• During risk monitoring, the project manager monitors
factors that may provide an indication of whether a
risk is becoming more or less likely
• Risk management and contingency planning assume
that mitigation efforts have failed and that the risk has
become a reality
• RMMM steps incur additional project cost
– Large projects may have identified 30 – 40 risks
• Risk is not limited to the software project itself
– Risks can occur after the software has been delivered to the
user
Background (continued)

• Software safety and hazard analysis

– These are software quality assurance activities
that focus on the identification and assessment
of potential hazards that may affect software
negatively and cause an entire system to fail
– If hazards can be identified early in the
software process, software design features can
be specified that will either eliminate or control
potential hazards
The RMMM Plan
• The RMMM plan may be a part of the software
development plan or may be a separate
document

• Once RMMM has been documented and the

project has begun, the risk mitigation, and
monitoring steps begin
– Risk mitigation is a problem avoidance activity
– Risk monitoring is a project tracking activity
– Risk management is a project management activity
Seven Principles of Risk Management
Maintain a global View software risks within the context of a system
perspective and the business problem that is intended to solve
Take a forward- Think about risks that may arise in the future;
looking view establish contingency plans
Encourage open Encourage all stakeholders and users to point out
communication risks at any time
Integrate risk Integrate the consideration of risk into the software
management process
Emphasize a Modify identified risks as more becomes known and
continuous process
of risk management add new risks as better insight is achieved
Develop a shared A shared vision by all stakeholders facilitates better
product vision risk identification and assessment
Encourage teamwork Pool the skills and experience of all stakeholders
when managing risk when conducting risk management activities
COCOMO Model (by Barry Boehm in 1981)
• Cocomo (Constructive Cost Model) is a regression model
based on LOC, i.e number of Lines of Code.

• The key parameters which define the quality of any software

products, which are also an outcome of the Cocomo are
primarily Effort & Schedule:

• Effort: Amount of labor that will be required to complete a

task. It is measured in person-months units.
• Schedule: Simply means the amount of time required for the
completion of the job, which is, of course, proportional to the
effort put. It is measured in the units of time such as weeks,
months.
Organic –
Project includes
 The team size required is adequately small,
The problem is well understood and has been solved in the past and
The team members have a nominal experience regarding the
problem.

Semi-detached – 
Intermediate projects in which team with mixed experience level.
Mix of rigid and less than rigid requirements

Embedded – 
A software project with requiring the highest level of complexity,
creativity, and experience requirement
Types of Models
• COCOMO consists of a hierarchy of three
increasingly detailed and accurate forms. Any
of the three forms can be adopted according
to our requirements. These are types of
COCOMO model:
– Basic COCOMO Model
– Intermediate COCOMO Model
– Detailed COCOMO Model
 Basic COCOMO
• Use Only Lines of code
• Equations are
Intermediate COCOMO
• Intermediate COCOMO takes these Cost
Drivers into account 
• Addition to basic cocomo , various other
factors such as reliability, experience,
Capability includes in Intermediate COCOMO.
• These factors are known as Cost Drivers and
the Intermediate Model utilizes 15 such
drivers for cost estimation.
The effort calculation:
E = a * (KLOC)b * EAF (person-months)
D= c*(E)d
P=E/D
Where,
E- Effort applied in person-months
D – Development time in duration-in-month (use c and d coefficient
from basic model)
P- Total number of persons required to accomplish the project
KLOC ... kilo lines of code
a, b, c, d depend on the project type
Detailed COCOMO Model –

• Detailed COCOMO incorporates all characteristics of the

intermediate version with an assessment of the cost
driver’s impact on each step of the software engineering
process. 

• The Four phases of detailed COCOMO are:

• Requirements Planning and Product Design
• Detailed design
• Code and unit test
• Integration and test
COCOMO II
• To help people reason about the cost and
schedule implications of their software decisions.

•  The original COCOMO model has been very successful,

but it doesn't apply to newer software development
practices as well as it does to traditional practices.

• COCOMO II targets modern software projects, and will

continue to evolve over the next few years.
Sub models of COCOMO II
• COCOMO 2 incorporates a range of sub-models that
produce increasingly detailed software estimates.

• The sub-models in COCOMO 2 are:

• Application composition model. Used when software is

composed from existing parts.
• Early design model. Used when requirements are available but
design has not yet started.
• Reuse model. Used to compute the effort of integrating reusable
components.
• Post-architecture model. Used once the system architecture has
been designed and more information about the system is
The Application Composition Model

Supports prototyping projects and projects where there is

extensive reuse.

 Takes CASE tool use into account.

 This model uses Object-Points (alternatively named Application
Points). Like FPs the object point is an indirect s/w measure that is
computed using:
 Screens (at the user interface)
 Reports, and
 Components likely to be required to build
application.
Steps for the estimation of effort in Person-
Months:
1. The first step is to count all of the object points
in the application.
2. The next step is to weight them according to the
table.

Multiply each object by its weight and sum over all

objects to give the Total Object Point Count.
• The productivity rate for different levels of
developer experience and development
environment maturity is given by this table:
• Effort computation
PM= NAP(1-%reuse/100) /PROD
WHERE
PM: effort in terms of person-months
NAP: number of application points.
%reuse: eg.screen,reports,modules used.
PROD: object point productivity
The Early Design Stage Model
• Early stage of project development
• After requirements and before actual project
development starts
• Approximate cost estimation
• Estimation based on functional points
Effort = A * (Size)B * M
• Here, A-> a constant representing the nominal productivity,
provisionally set to 2.5(2.94)

• B -> Scale factor. It depends on the development flexibility, team

management skills, and process maturity.

• Size -> Size of the s/w

• M -> Multipliers reflect the capability of the developers, the non-

functional requirements, the familiarity with the development
platform, etc. (7 cost drivers)
There are 7 cost drivers
1. RCPX - product reliability and complexity;
2. RUSE - the reuse required;
3. PDIF - platform difficulty;
4. PREX - personnel experience;
5. PERS - personnel capability;
6. SCED - required schedule;
7. FCIL - the team support facilities.

M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED

The degree of influence of each of these factors is taken to be

from 1 to 6 representing the six different levels i.e.
1 -> Very Low 2 -> Low
3 -> Nominal 4 -> High
5 -> Very High 6 -> Extra High
The Reuse Model
• Code reused from earlier software system.
• Takes into account black-box code that is reused without
change and code that has to be adapted to integrate it with
new code.

• There are two versions:

• Black-box reuse where code is not modified. An effort estimate
(PM) is computed.

• White-box reuse where code is modified. A size estimate

equivalent to the number of lines of new source code is
computed. This then adjusts the size estimate for new code.
• Third category of code:
• Generated automatically standard templates are integrated.

• Effort for automatically generated code:

PM= (ASLOC * AT/100)/ATPROD
where
• PM: person-month
• ASLOC is the number of lines of generated code
• AT is the percentage of code automatically generated.
• ATPROD is the productivity of engineers in integrating this
code.
When code has to be understood and integrated:

ESLOC = ASLOC * (1-AT/100) * AAM

• ASLOC is the number of lines of generated code

• AT is the percentage of code automatically generated
• AAM is the adaptation adjustment multiplier computed from the
costs of changing the reused code, the costs of understanding how
to integrate the code and the costs of reuse decision making.
Post-architecture level
Uses the same formula as the early design model but with 17
rather than 7 associated multipliers.

• The code size is estimated as:

• Number of lines of new code to be developed;

• Estimate of equivalent number of lines of new code computed
using the reuse model;
• An estimate of the number of lines of code that have to be
modified according to requirements changes.
• Detailed model

Effort= A*sizeB *M

The exponent term (B)

• This depends on 5 scale factors .Their sum/100 is added to

1.01

• A company takes on a project in a new domain. The client

has not defined the process to be used and has not allowed time
for risk analysis. The company has a CMM level 2 rating.
• Precedenteness - new project (4)
• Development flexibility - no client involvement- Very high(1)
• Architecture/risk resolution - No risk analysis - V. Low .(5)
• Team cohesion - new team - nominal (3)
• Process maturity - some control - nominal (3)
• Product attributes
• Concerned with required characteristics of the software product
being developed.

• Computer attributes
• Constraints imposed on the software by the hardware platform.

• Personnel attributes
• Multipliers that take the experience and capabilities of the people
working on the project into account.

• Project attributes
• Concerned with the particular characteristics of the software
development project.
Product Factors RELY- Required Software Reliability

DATA - Data Base Size

CPLX - Product Complexity
RUSE - Required Reusability
DOCU - Documentation match to life-cycle needs

Platform Factors TIME - Execution Time Constraint

STOR - Main Storage Constraint
PVOL - Platform Volatility
Personnel Factors ACAP - Analyst Capability
PCAP - Programmer Capability
AEXP - Applications Experience
PEXP - Platform Experience
LTEX - Language and Tool Experience

PCON - Personnel Continuity

Project Factors TOOL - Use of Software Tools
SITE - Multisite Development
SCED - Required Development Schedule