2. Once a project is found to be feasible, software
project managers undertake project planning. Project
planning is undertaken and completed even before
any development activity starts. Project planning
consists of the following essential activities:
• Estimating the following attributes of the project:
1. Project size: What will be problem complexity in
terms of the effort and time required to develop
the product?
2. Cost: How much is it going to cost to develop the
project?
3. Duration: How long is it going to take to complete
development?
4. Effort: How much effort would be required?
The effectiveness of the subsequent planning
activities is based on the accuracy of these
estimations.
• Scheduling manpower and other resources
• Staff organization and staffing plans
• Risk identification, analysis, and abatement planning
• Miscellaneous plans such as quality assurance plan,
configuration management plan, etc.
Project Planning :
3. Measures, Metrics, Measurements and Indicators:
A measure provides a quantitative indication of the extent, dimension, size, capacity, efficiency, productivity or
reliability of some attributes of a product or process.
Example: Number of defects found in component testing. LOC of each component
Measurement is the act of determining a measure.
Example: Collecting the defect counts. Counting LOC.
A metric is a quantitative measure of the degree to which a system, component or process possesses a given
attribute.
Example: defects found in component testing/LOC of code tested.
A Indicator is a metrics or series of metrics that provide insight into a process, project or product.
4. Software Metrics :
Software Metrics refers to a range of measurements for computer software that
enable software people to gain insight into the project :
To improve the Process and the Product
Assist in Estimation
Productivity Assessment
Quality Control
Project Control
5. Why do we Measure?
1. To characterize
• To gain understanding of Product, Process, and ?
• To establish baseline for future comparisons
2. To evaluate
• To determine status within the plan
3. To predicate
• So that we can plan. Update estimates
4. To improve
• We would have more information “quantitative” to help determine root causes
6. Categories of
Metrics
Product Metrics:
These measurements relate to SW product and all related artifacts.
Examples: code, design docs, test plan, user manual …LOC, # of objects, #
# of pages, # of files.
Process Metrics:
These measures used to quantify characteristics of the SW process.
Usually related to events or things that occur.
Examples: # defects found in test, # requirements changes, # days to
complete task …
Project Metrics:
used to manage the SW project “Tactic”.
Estimating cost is the first application of Project Metrics.
Examples: estimates of SW development time based on past projects.
• Product Metrics
• Process Metrics
• Project Metrics
7. Software Measurements :
Two categories of measurement :
1. Direct measures - measurements that are more tangible.
o Cost, time, and efforts are Direct Process measures
o LOC, memory size are examples of Direct Product measures
2. Indirect measures - measurements of things that describe the characteristics of
a product or process. These are the "abilities".
o Functionality, quality, complexity, efficiency, reliability
8. Normalization for Metrics :
Normalized data are used to evaluate the process and the
product.
Size-oriented normalization - line-of-code approach
Function-oriented normalization - function point approach
9. Size-Oriented Metrics :
Size‐oriented software metrics are derived by normalizing quality and/or productivity measures by
considering the size of the software that has been produced.
This metrics is one of simplest and earliest metrics that is used for computer program to measure size.
The size measurement is based on lines of code computation.
There are thousand lines of code (KLOC) which are often chosen as the normalization value.
While counting lines of code, simplest standard is:
Don’t count blank lines
Don’t count comments
Count everything else
The size-oriented measure is not a universally accepted method.
10. Metrics include:
Size = Kilo(1000) Lines of Code (KLOC)
Effort = Person / month
Productivity = KLOC / person-month
Quality = Errors/ KLOC
Cost = $ / KLOC
Documentation = Pages of documentation / KLOC
This metric is not universally accepted as the best way to measure the software
process.
Example : For a size oriented metrics, software organization maintains
records in tabular form. The typical table entries are: Project Name, LOC,
Efforts, Pages of documents, Errors, Defects, Total number of people working
on it.
Possible data to collect :
• number of lines of code
• number of person-months to
complete
• cost of the project
• number of pages of documentation
• number of errors corrected before
release
• number of bugs found post release
11. 1. Using these metrics, it is very simple to measure
size.
2. Artefact of Software development which is easily
counted.
3. LOC is used by many methods that are already
existing as a key input.
4. A large body of literature and data based on LOC
already exists.
1. This measure is dependent upon programming language.
2. This method is well designed upon programming
language.
3. It does not accommodate non-procedural languages.
4. Sometimes, it is very difficult to estimate LOC in early
stage of development.
5. Though it is simple to measure but it is very hard to
understand it for users.
6. It cannot measure size of specification as it is defined on
code.
Advantages Disadvantages
Size-Oriented Metric’s