Software

Management
Software cost estimation
technique
 Algorithmic cost: A model is developed using historical cost information
that relates some software metric to the project cost.
 Expert judgment: Several experts on the proposed software development
techniques and the application domain are consulted.they each estimate the
project cost.
 Estimation by analogy: This technique is applicable when other projects in
the same application domain have been completed.The cost of a new project
is estimated by analogy with this completed projects.
 Parkinson’s Law: Parkinson’s Law states that work expends to fill the time
available.The cost is determined by available resources rather than by
objective assessment.
 Pricing to win: The software cost is estimated to be whatever the customer
has available to spend on the project.The estimated project depends on the
customer’s budget and not on the software functionality.
The COCOMO Model
 The cocomo model is an empirical model that was derived by
collecting data from a large number of software projects.These data
were analyzed to discover formulate that were best fit to the
observations.
 Reasons for choosing cocomo model:
1. It is well documented,available in the public domain and supported by the
public domain and commercial tools.
2. It has been widely used and evaluated in a range of organizations.
3. It has a long pedigree from its first instantiation in 1989 ,through a
refinement tailored to ada software development.
Metrics
 Metrics are numbers that are assigned to some
artifact or process
 In software engineering there are two sorts

- Process metrics
 These refer to the process of developing the software and are
used by management to determine how development is
processing
- Product metrics
 These are data that indicate the quality of the product
 We will focus on Product Metrics here
 Software Attributes
 We can measure the internal attributes of software
- Things like number of lines of code, the readability of
the software manual, the number of faults observed in
testing, the fan in of the modules, etc
 What is important is how the internal attributes relate
to the external attributes
- The characteristics of the actual product
 These are the ilities, such as Maintainability, Reliability,
Portability, Usability, etc
Relationship Between Internal
and External Attributes
Internal Attributes
External Attributes
Number of
Maintainability procedure parameters

Cyclometric
Reliability complexity

Number of lines of code

Portability
Number of
error message
Usability
Length of
user manual
Metrics and Software
 Metrics have not been widely used for software
quality assessment
- They cost money to collect
- They require analysis
 What do the figures mean
 However, successful companies use them to
assess the quality of their specifications, designs
and code
- They invest to develop experience in working out
what the figures mean
Product Quality Metrics
Product quality metrics are particularly valuable for highlighting
anomalous components that may have quality problems .These
components should then be analyzed in more detail.

 Product metrics fall into two classes

1.Dynamic metrics: Dynamic metrics that are collected by
measurements made of a program in execution.
2. Static metrics: Static metrics that are collected by measurement
made of representations of the system such as the design ,a
program or documentation.
These can be applied at the following
stages
- Analysis
- Design
- Code
- Test
Adaptive maintenance
 Adaptinf the software to changes in its environment
- The operating system may change, the hardware
platforms may change
 Suppose that you wrote a program 10 years ago for PCs
- You may have gone through DOS, Windows 3.1 and
Windows 95, Windows 98, Windows NT versions
 Note that the functionalityy of the software does not
radically change
 Surveys shown that about 18% of maintenance is
adaptive
 Analysis Metrics
 The most popular analysis metric is the Function Point Metric
 This measures the complexity of the product to be developed
 Its calculation is somewhat complicated

- So it’s omitted here

 The Function Point Metric is a predictive metric

- If a company is properly organised it can be used to predict

 The size of the code, the effort taken to develop the code, the cost of the
development, its timescales, etc.
 Design Metrics
 We can estimate the complexity of the design of a
program when it is designed
- complexity is a good predictor of maintainability
and reliability
 We can split these into three classes

- Overall Design Metrics (structure of program)

- Component Level Design Metrics (Structure of Component)
- Interface Design Metrics ( complexity of interface)
 We will only consider overall design metrics
Overall Design Metrics
 These refer to modules at the black box level
- We can use a structure chart to estimate
these
 We can use the following

- Fan in/ Fan out measures

- Information Fan in /Fan out
- Henry and Kafura’s Metric
- Card and Glass’s System Complexity
 Fan In & Fan Out
 The Fan In of a module is the number of
calls from superordinate modules
 The Fan out of a module is the number
of calls a module makes to a
subordinate module

Fan in = 3
Fan out = 2
Complexity of
module = 5
Information Fan In/ Fan Out
 Fan In & Fan Out does not consider the
data passes to the module
- So class_ord appears less complex
than order
 It’s rather more complex
 Information Fan In & Fan Out considers
the parameters passed
Fan in information = 3
Fan out information = 2
Complexity = 5
Order
 Henry and Kafura’s Metric
 This uses the following formula
- For module m, the complexity C is:
- C = length (m) x (fan_in(m) + fan_out(m))2
- where
 length (m) is the length of the module as lines of code or as
Cyclometric Complexity
 fan_in and fan_out are computed as the information metric

 When applied at design time before code is

developed, length must be an estimate
 Card and Glass’s Systems
Complexity
 Structural Complexity S of module m is given by
- S(m) = fan_out(m)2
 where fan_out is the standard fan out rather than the information fan
out
 Data Complexity D of module m is given by
- D(m) = v(m).(fan_out(m)+1)
- where v(m) is the number of input and output variables passed
to and from the module m
 System Complexity C for module m is

- C(m) = S(m) + D(m)

 Quality Assurance
 Software quality management can be structured into three principal activities
 Quality assurance:The establishment of a framework of organizational
procedures and standards which lead to high quality software.
 Quality planning: The selection of appropriate procedures and standards from
this framework and the adaptation of these for a specific software project.
 Quality control: The defination of processes which ensure that the project
quality procedures and standards are followed by the software development
team.