CTIS 359 PRINCIPLES OF SOFTWARE ENGINEERING

1
CTIS 359 PRINCIPLES OF SOFTWARE ENGINEERING

• WEEK 4
• SOFTWARE COST ESTIMATION

2
OBJECTIVES

• To introduce the fundamentals of software size
  estimation.
• To describe three metrics for software
  productivity assessment.
• To introduce the COCOMO cost estimation model.

3
PROJECT PLANNING QUESTIONS

• How much effort is required to complete a
  software project?(Man Months)
• How much calendar time is needed to complete a
  software project? (Months)
• What is the total development cost of a software
  project? (Money)

4
COST COMPONENTS

• Hardware and software costs
• Travel and training costs
• Effort costs (the dominant factor in most
  projects)
• The salaries of software engineers involved in
  the project
• Social and insurance costs
• Effort costs must take overheads into account
• Costs of building, heating, lighting
• Costs of networking and communications
• Costs of shared facilities (library, staff
  restaurant, etc.)

5
PRODUCTIVITY MEASURES

• Size-related measures - based on some output from
  the software process. (Lines of Source Code is
  the best known).
• Function-related measures - based on an estimate
  of the functionality of the delivered software.
  (Function Points are the best known).

6
LINES OF CODE (LOC)

• What is a line of code?
• The measure was first proposed when programs were
  typed on cards with one line per card
• How does this correspond to statements as in Java
  which can span several lines or where there can
  be several statements on one line?

7
LINES OF CODE (LOC) PROBLEMS

• Programming language dependent
• Penalize well-designed but shorter programs
• Estimation requires a level of detail that may
  be difficult to achieve.

8
FUNCTION POINTS (FP)

• Focus on software functionality
• Independent of the language
• A function point is not a single characteristic
  but computed by combining several measuraments or
  estimates then scaled based on complexity factors
  called weights.

9
FUNCTION POINTS WEIGHTING FACTORS
10
FUNCTION POINTS (FP)

• Inputs Web pages, forms, dialogs, controls,
  messages, XML documents
• Outputs Web pages, reports, graphs, messages,
  XML documents
• Inquiries simple Web inputs
• Interfaces device interface
• Files tables

11
UNADJUSTED FUNCTION POINTS (UFP) EXAMPLE

• Unadjusted Function Point (UFC) 304

12
FUNCTION POINTS (FP)

• Anadjusted Function Point (UFP) is adjusted by
  additional complexity factors that are related to
  the system as a whole.
• 14 system factors are rated from 0-5. These
  factors rate the system complexity.
• 0 Not present or no influence
• 5 Strong Influence
• Rating is subjective.
• The Function Point Users manual gives full
  details on how to apply these factors at their
  web site www.ifpug.org.
• UFP is adjusted using the following formula
• Factor 0.65 0.01(sum of factors)
• Factor ranges between 0.65 1.35
• FP UFC x Factor

13
FUNCTION POINTS FACTORS

• Data Communications
• Distributed Functions
• Performance
• Heavy Use
• Transaction Rate
• Online Data Entry
• End User Efficiency
• Online Update
• Complex Processing
• Reusability of System Code
• Installation Ease
• Operational Ease
• Multiple Sites
• Ease Of Change

14
FUNCTION POINT TO LOC CONVERSION FACTORS
15
OBJECT POINTS

• Also named application points
• They are not same as object classes
• The number of object points in a program is a
  weighted estimate of
• The number of separate screens that are displayed
• The number of reports that are produced by the
  system
• The number of program modules that must be
  developed to supplement the database code

16
OBJECT POINTS

• Object points are easier to estimate from a
  specification than function points as they are
  simply concerned with screens, reports and
  programming language modules.
• They can therefore be estimated at a fairly early
  point in the development process.

17
INITIAL COST AND SCHEDULE ESTIMATES

• At the time the project is initially planned only
  the most general characteristics of the product
  are known.
• The first substative work product of most
  projects is the Software Requirements
  Specification (SRS).
• Therefore, the process of estimation and
  scheduling should be repeated after the SRS is
  approved.
• They are used for proposals.

18
PREPARING INITIAL ESTIMATES

• There are 3 major methods
• Analogy The actual cost and schedule of one or
  more specific, similar projects are used to
  develop the estimates.
• Rule of thumb Institutional or individual
  experts or guidelines are used, usually within an
  organization.
• Parametric models These use properties of the
  products, like lines of code.

19
PARAMETRIC MODELS

• Parametric models use parametric input
• The expected size of the product
• The nature of the product
• The capabilities of the organization
• Properties of the project

20
PARAMETRIC MODELS

• The main models are
• COnstructive COst MOdel (COCOMO)
• PRICE S
• SLIM
• SEER-SEM

21
COCOMO

• COCOMO is a model based on inputs relating to the
  size of the system and a number of cost drivers
  that affect productivity.
• The original COCOMO model was first published in
  1981 (Boehm, 1981).
• Orginal COCOMO model got updated and called
  COCOMO 2 that accounts for recent changes in
  software engineering technology.

22
ORIGINAL COCOMO

• The original COCOMO has 3 models
• Basic used early in the project estimates in
  Lines of Code.
• Intermediate after requirements are specified
  estimates in Lines of Code and a set of cost
  drivers. Cost Drivers are subjective assessments
  of attributes in the general areas of product,
  hardware, personenel and project.
• Advanced after design is complete incorporates
  the characteristics of intermediate COCOMO with
  an assessment of the cost driver impact on each
  phase of the software development cycle.
• All 3 models use the following formula
• E aSb x EAF where
• E is effort in person months
• S size in Lines of Code
• EAF Effort Adjustment Factor (equals to 1 for
  basic)
• Factors a and b depend on the software project.

23
COCOMO

• 3 types of software projects
• Organic Mode relatively simple projects with
  smalls teams
• Semi-detached Mode intermediate size project
• Embedded Mode advanced project that must be
  developed with tight hardware, software,
  operational requirements.

24
INTERMEDIATE COCOMO

• Determine the mode.
• Calculate effort from the appropriate table.
• Calculate a difficulty multiplier that is the
  product of the 15 individual difficulty factors
  in the four categories.
• Plug into formula The adjusted effort MM is
  the nominal effort MMnominal multiplied by the
  difficulty multiplier

25
INTERMEDIATE COCOMO CONSTANTS
26
INTERMEDIATE COCOMO MODEL
27
COCOMO 2

• COCOMO 2 was developed to address several issues
  that did not exist when the original COCOMO was
  developed.
• The waterfall model was the software lifecycle
  development model
• Most software ran on mainframes
• Client-server and object oriented technologies
  were unknown, or at least were not widely used
• COCOMO 2 supports for evolutionary and COTS based
  development.
• COCOMO 2 incorporates a range of sub-models that
  produce increasingly detailed software estimates.

28
Use of COCOMO 2 models
29
COCOMO 2 SUBMODELS

• 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 available.

30
POST ARCHITECTURE MODEL

• Used during actual development and maintenance.
• Function Points or LOCs can be used.
• 17 cost drivers
• 5 factors to determine the project scaling
  component.
• The 5 factors replace the development modes
  (organic,semi-detached, embedded) of the original
  COCOMO model.
• E aKLOCb x EAF
• a 2.55
• b 1.01 0.01 x SUM (Wi) where W is the set of
  5 factors.

31
POST ARCHITECTURE SCALE FACTORS
32
POST ARCHITECTURE COST DRIVERS