CHAPTER 1

Verification and Validation

Verification and Validation is the process of investigating that a software system

satisfies specifications and standards and it fulfills the required purpose.

Verification: ➔ Verification is the process of checking that a software achieves

its goal without any bugs.
➔ It is the process to ensure whether the product that is developed is right or
not.
➔ It verifies whether the developed product fulfills the requirements that we
have.
➔ Verification is Static Testing.
➔ Activities involved in verification:
1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking

Validation:
➔ Validation is the process of checking whether the software product is up to
the mark.
➔ In other words the product has high level requirements.
➔ It is the process of checking the validation of product i.e. it checks what we
are developing is the right product.
➔ It is validation of actual and expected products.
➔ Validation is the Dynamic Testing.
Difference between verification and validation testing:
Software Inspections:

Software inspection is a static V & V process in which a software system

is reviewed to find errors, omissions and anomalies.
● It focuses on source code, but any readable representation of the software
such as its requirements or a design model can be inspected.
● While inspecting a system, you use knowledge of the system, its application
domain and the programming language or design model to discover errors.
● There are three major advantages of inspection over testing:
1. During testing, errors can mask (hide) other errors.
❏ Once one error is discovered, you can never be sure if other output
anomalies are due to a new error or are side effects of the original error.
❏ Because inspection is a static process, you don’t have to be concerned with
interactions between errors.
❏ Consequently, a single inspection session can discover many errors in a
system.
2. Incomplete versions of a system can be inspected without additional
costs.
❏ If a program is incomplete, then you need to develop specialized test
harnesses to test the parts that are available.
❏ This obviously adds to the system development costs.
3. Searching for program defects, an inspection can also consider
broader quality attributes of a program
❏ such as compliance with standards, portability and maintainability.
❏ You can look for inefficiencies, inappropriate algorithms and poor
programming style that could make the system difficult to maintain and update.

Roles in the inspection process with Description are as follow:

1. Author or owner
❏ The programmer or designer responsible for producing the program or
document.
❏ Responsible for fixing defects discovered during the inspection process.
2. Inspector
❏ Finds errors, omissions and inconsistencies in programs and documents.
❏ May also identify broader issues that are outside the scope of the inspection
team.
3. Reader
❏ Presents the code or document at an inspection meeting.
4. Scribe
❏ Records the results of the inspection meeting.
5. Chairman or moderator
❏ Manages the process and facilitates the inspection.
❏ Reports process results to the chief moderator.
6. Chief moderator
❏ Responsible for inspection process improvements, checklist updating,
standards development, etc
The inspection process:

There are some of the stages in the software inspection process such as-
● Planning : The moderator plans the inspection.
● Overview Meeting: The background of the work product is described
by the author.
● Preparation: The examination of the work product is done by
inspector to identify the possible defects.
● Inspection Meeting: The reader reads the work product part by part
during this meeting and the inspectors the faults of each part.
● Rework: After the inspection meeting, the writer changes the work
product according to the work plans.
● Follow Up: The changes done by the author are checked to make
sure that everything is correct.

Advantages of Software Inspection:

● Helps in the Early removal of major defects.

● This inspection enables a numeric quality assessment of any technical
document.
● Software inspection helps in process improvement.
● It helps in staff training on the job.
● Software inspection helps in gradual productivity improvement.
Disadvantages of Software Inspection:
● It is a time-consuming process.
● Software inspection requires discipline.

CODE REVIEW CHECKLIST

Inspection checks with different Fault class are as follow:
1. Data faults:
❏ Are all program variables initialized before their values are used?
❏ Have all constants been named?
❏ Should the upper bound of arrays be equal to the size of the array or Size
-1?
❏ If character strings are used, is a delimiter explicitly assigned?
❏ Is there any possibility of buffer overflow?

2. Control faults:
❏ For each conditional statement, is the condition correct?
❏ Is each loop certain to terminate?
❏ Are compound statements correctly bracketed?
❏ In case statements, are all possible cases accounted for?
❏ If a break is required after each case in case statements, has it been
included?

3. Input/output faults:
❏ Are all input variables used?
❏ Are all output variables assigned a value before they are output?
❏ Can unexpected inputs cause corruption?

4. Interface faults:
❏ Do all function and method calls have the correct number of parameters? ❏
Do formal and actual parameter types match?
❏ Are the parameters in the right order?
❏ If components access shared memory, do they have the same model of the
shared memory structure?

5. Storage management faults:

❏ If a linked structure is modified, have all links been correctly reassigned?
❏ If dynamic storage is used, has space been allocated correctly?
❏ Is space explicitly de-allocated after it is no longer required?

6. Exception management faults:

❏ Have all possible error conditions been taken into account?

Automated Static Analysis

Inspections are one form of static analysis where you examine the program
without executing it.
● Inspections are often driven by checklists of errors and heuristics that identify
common errors in different programming languages.
● For some errors and heuristics( an approach to problem solving or self
discovery ), it is possible to automate the process of checking programs against
this list, which has resulted in the development of automated static analysers for
different programming languages.
● Static analysers are software tools that scan the source text of a program and
detect possible faults and anomalies.
● They parse the program text and thus recognise the types of statements in
the program.
● They can then detect whether statements are well formed, make inferences
about the control flow in the program and, in many cases, compute the set of all
possible values for program data.
● They complement the error detection facilities provided by the language
compiler.
● They can be used as part of the inspection process or as a separate V & V
process activity.
● The intention of automatic static analysis is to draw an inspector’s attention to
anomalies in the program, such as variables that are used without initialisation,
variables that are unused or data whose value could go out of range.
The stages involved in static analysis include:
1. Control flow analysis
❏ This stage identifies and highlights loops with multiple exit or entry points
and unreachable code.
❏ Unreachable code is code that is surrounded by unconditional goto
statements or that is in a branch of a conditional statement where the guarding
condition can never be true.

2. Data use analysis

❏ This stage highlights how variables in the program are used.
❏ It detects variables that are used without previous initialisation, variables that
are written twice without an intervening assignment and variables that are
declared but never used.
❏ Data use analysis also discovers ineffective tests where the test condition is
redundant. Redundant conditions are conditions that are either always true or
always false.

3. Interface analysis
❏ This analysis checks the consistency of routine and procedure declarations
and their use.
❏ It is unnecessary if a strongly typed language such as Java is used for
implementation as the compiler carries out these checks.
❏ Interface analysis can detect type errors in weakly typed languages like
FORTRAN and C.
❏ Interface analysis can also detect functions and procedures that are declared
and never called or function results that are never used.

4. Information flow analysis

❏ This phase of the analysis identifies the dependencies between input and
output variables.
❏ While it does not detect anomalies, it shows how the value of each program
variable is derived from other variable values.
❏ With this information, a code inspection should be able to find values that
have been wrongly computed.
❏ Information flow analysis can also show the conditions that affect a variable’s
value.

5. Path analysis
❏ This phase of semantic analysis identifies all possible paths through the
program and sets out the statements executed in that path.
❏ It essentially unravels the program’s control and allows each possible
predicate to be analyzed individually.

Automated static analysis checks

Automated static analysis checks with Fault class are as follow:

1. Data faults
● Variables used before initialisation
● Variables declared but never used
● Variables assigned twice but never used between assignments
● Possible array bound violations
● Undeclared variables
2. Control faults
● Unreachable code
● Unconditional branches into loops
3. Input/output faults
● Variables output twice with no intervening assignment
4. Interface faults
● Parameter type mismatches
● Parameter number mismatches
● Non-usage of the results of functions
● Uncalled functions and procedures

5. Storage management faults

● Unassigned pointers
● Pointer arithmetic
 Verification and Formal Method
Formal methods of software development are based on mathematical
representations of the software, usually as a formal specification.
● These formal methods are mainly concerned with a mathematical analysis of the
specification; with transforming the specification to a more detailed, semantically
equivalent representation; or with formally verifying that one representation of
the system is semantically equivalent to another representation.
● You can think of the use of formal methods as the ultimate static verification
technique. They require very detailed analyses of the system specification and
the program, and their use is often time consuming and expensive.
● Consequently, the use of formal methods is mostly confined to safety- and
security-critical software development processes.
● The use of formal mathematical specification and associated verification was
mandated in UK defense standards for safety-critical software (MOD, 1995).
Formal methods may be used at different stages in the V & V process as
shown below:
1. A formal specification of the system may be developed and mathematically
analyzed for inconsistency. This technique is effective in discovering
specification errors and omissions.
2. You can formally verify, using mathematical arguments, that the code of a
software system is consistent with its specification. This requires a formal
specification and is effective in discovering programming and some design
errors. A transformational development process where a formal specification is
transformed through a series of more detailed representations or a
Cleanroom process may be used to support the formal verification process.
● Formal verification demonstrates that the developed program meets its
specification so implementation errors do not compromise dependability.

Formal specification and proof do not guarantee that the software will be
reliable in practical use.
The reasons for this are:
 1. The specification may not reflect the real requirements of system users.
System users rarely understand formal notations so they cannot read the
formal specification directly to find errors and omissions.
2. The proof may contain errors.Program proofs are large and complex, so, like
large and complex programs, they usually contain errors.

3. The proof may assume a usage pattern which is incorrect. If the system is not
used as anticipated, the proof may be invalid.

● In spite of their disadvantages, formal methods have an important role to play

in the development of critical software systems.
● Formal specifications are very effective in discovering specification
problems that are the most common causes of system failure.
● Formal verification increases confidence in the most critical components of
these systems.
● The use of formal approaches is increasing as procurers demand it and as
more and more engineers become familiar with these techniques.

Cleanroom software development:

●Another well-documented approach that uses formal methods is the

Cleanroom development process.
● Cleanroom software development is a software development philosophy that
uses formal methods to support rigorous(done very carefully) software inspection.
● The objective of this approach to software development is zero-defect
software.
1. Formal specification
❏ The software to be developed is formally specified.
❏ A state transition model that shows system responses to stimuli is used to
express the specification.
2. Incremental development
❏ The software is partitioned into increments that are developed and validated
separately using the Cleanroom process.
❏ These increments are specified, with customer input, at an early stage in the
process.
3. Structured programming
❏ Only a limited number of control and data abstraction constructs are used.
❏ The program development process is a process of stepwise refinement of the
specification.
❏ A limited number of constructs are used and the aim is to systematically
transform the specification to create the program code.
4. Static verification
❏ The developed software is statically verified using rigorous software
inspections.
❏ There is no unit or module testing process for code components.
5. Statistical testing of the system
 ❏ The integrated software increment is tested statistically to determine its
reliability.
❏ These statistical tests are based on an operational profile, which is developed
in parallel with the system specification as shown in above Figure.

★ There are three teams involved when the Cleanroom process is used
for large system development:
1. The specification team
❏ This group is responsible for developing and maintaining the system
specification.
❏ This team produces customer-oriented specifications (the user
requirements definition) and mathematical specifications for verification.
❏ In some cases, when the specification is complete, the specification
team also takes responsibility for development.
2. The development team
❏ This team has the responsibility of developing and verifying the
software.
❏ The software is not executed during the development process.
❏ A structured, formal approach to verification based on inspection of
code supplemented with correctness arguments is used.
3. The certification team
❏ This team is responsible for developing a set of statistical tests to
exercise the software after it has been developed.
❏ These tests are based on the formal specification.
❏ Test case development is carried out in parallel with software
development.
❏ The test cases are used to certify the software reliability. Reliability
growth models used to decide when to stop testing.
 CHAPTER 2
SOFTWARE TESTING

● Software Testing is a method to check whether the actual software

product matches expected requirements and to ensure that software
product is Defect free.
● It involves execution of software/system components using manual or
automated tools to evaluate one or more properties of interest. The
purpose of software testing is to identify errors, gaps or missing
requirements in contrast to actual requirements.

What are the benefits of Software Testing?

Here are the benefits of using software testing:

● Cost-Effective: It is one of the important advantages of software testing.

Testing any IT project on time helps you to save your money for the long
term. In case if the bugs caught in the earlier stage of software testing, it
costs less to fix.
● Security: It is the most vulnerable and sensitive benefit of software
testing. People are looking for trusted products. It helps in removing risks
and problems earlier.
● Product quality: It is an essential requirement of any software product.
Testing ensures a quality product is delivered to customers.
● Customer Satisfaction: The main aim of any product is to give
satisfaction to their customers. UI/UX Testing ensures the best user
experience.
A model of the software testing process
A general model of the testing process is shown in above Figure.
● Test cases are specifications of the inputs to the test and the expected
output from the system plus a statement of what is being tested.
● Test data are the inputs that have been devised/invented to test the
system.
● Test data can sometimes be generated automatically. Automatic test case
generation is impossible.
● The output of the tests can only be predicted by people who understand
what the system should do.
● Exhaustive testing, where every possible program execution sequence is
tested, is impossible.
● Testing, therefore, has to be based on a subset of possible test cases.
●Ideally, software companies should have policies for choosing this subset
rather than leave this to the development team.
● These policies might be based on general testing policies, such as a policy
that all program statements should be executed at least once.
● Alternatively, the testing policies may be based on experience of system
usage and may focus on testing the features of the operational system.

For example:
1. All system functions that are accessed through menus should be tested.
2. Combinations of functions (e.g., text formatting) that are accessed through
the same menu must be tested.
3. Where user input is provided, all functions must be tested with both correct
and incorrect input.
There are two types of Software testing

1. Manual Testing
2. Automation Testing

Manual Testing

● Manual testing is testing of the software where tests are executed

manually by a QA Analyst. It is performed to discover bugs in software
under development.
● In Manual testing, the tester checks all the essential features of the given
application or software.
● In this process, the software testers execute the test cases and generate
the test reports without the help of any automation software testing tools.
● It is a classical method of all testing types and helps find bugs in software
systems. It is generally conducted by an experienced tester to accomplish
the software testing process.

Automation Testing

● In Automated Software Testing, testers write code/test scripts to automate

test execution. Testers use appropriate automation tools to develop the
test scripts and validate the software. The goal is to complete test
execution in a less amount of time.
● Automated testing entirely relies on the pre-scripted test which runs
automatically to compare actual result with the expected results. This
helps the tester to determine whether or not an application performs as
expected.
● Automated testing allows you to execute repetitive task and regression
test without the intervention of manual tester. Even though all processes
are performed automatically, automation requires some manual effort to
create initial testing scripts.

System Testing
System testing involves integrating two or more components that implement system
functions or features and then testing this integrated system. In an iterative
development process, system testing is concerned with testing an increment to be
delivered to the customer; in a waterfall process, system testing is concerned with
testing the entire system.
For most complex systems, there are two distinct phases to system testing:

1. Integration testing, where the test team has access to the source code of the
system.

❏ When a problem is discovered, the integration team tries to find the source of the
problem and identify the components that have to be debugged.

❏ Integration testing is mostly concerned with finding defects in the system.

2. Release testing, where a version of the system that could be released to users is
tested.

❏ Here, the test team is concerned with validating that the system meets its
requirements and with ensuring that the system is dependable.

❏ Release testing is usually ‘black-box’ testing where the test team is simply
concerned with demonstrating that the system does or does not work properly.

❏ Problems are reported to the development team whose job is to debug the program.

❏ Where customers are involved in release testing, this is sometimes called

acceptance testing. If the release is good enough, the customer may then accept it for
use.

Software Testing can be majorly classified into two categories:

1. Black Box Testing is a software testing method in which the internal

structure/design/implementation of the item being tested is not known
to the tester. Only the external design and structure are tested.
 2. White Box Testing is a software testing method in which the internal
structure/design/implementation of the item being tested is known to
the tester. Implementation and impact of the code are tested.

Differences between Black Box Testing vs White Box Testing:

TYPES OF SYSTEM TESTING

Integration testing

● The process of system integration involves building a system from its components
and testing the resultant system for problems that arise from component interactions.

● The components that are integrated may be off-the-shelf components, reusable

components that have been adapted for a particular system or newly developed
components.

● Integration testing checks that these components actually work together, are called
correctly and transfer the right data at the right time across their interfaces.
● System integration involves identifying clusters of components that deliver some
system functionality and integrating these by adding code that makes them work
together.

● In the top-down integration skeleton of the system is developed first, and

components are added to it.

● Alternatively, in the bottom-up integration first integrate infrastructure components

that provide common services, such as network and database access, then add the
functional components.

● In both top-down and bottom-up integration, usually we have to develop additional

code to simulate other components and allow the system to execute.

● Drawback:

○ A major problem that arises during integration testing is localising errors.

○ There are complex interactions between the system components and, when an
anomalous output is discovered, you may find it hard to identify where the error
occurred.

● To make it easier to locate errors, you should always use an incremental approach to
system integration and testing. Initially, you should integrate a minimal system

Regression testing:
○ These problems mean that when a new increment is integrated, it is important to
rerun the tests for previous increments as well as the new tests that are required to
verify the new system functionality.
○ Rerunning an existing set of tests is called regression testing.
○ If regression testing exposes problems, then you have to check whether these are
problems in the previous increment that the new increment has exposed or whether
these are due to the added increment of functionality.
○ Regression testing is clearly an expensive process and is impractical without some
automated support.

Release testing:
● Release testing is the process of testing a release of the system that will be
distributed to customers.
● The primary goal of this process is to increase the supplier’s confidence that the
system meets its requirements. If so, it can be released as a product or delivered to the
customer.
● Release testing is usually a black-box testing process where the tests are derived
from the system specification.

Performance testing:
● Once a system has been completely integrated, it is possible to test the system for
emergent properties such as performance and reliability.
● Performance tests have to be designed to ensure that the system can process its
intended load.
● This usually involves planning a series of tests where the load is steadily increased
until the system performance becomes unacceptable.
● As with other types of testing, performance testing is concerned both with
demonstrating that the system meets its requirements and discovering problems and
defects in the system.
● To test whether performance requirements are being achieved, you may have to
construct an operational profile.

Component Testing

Component testing also known as unit testing is the process of testing individual
components in the system.
● This is a defect testing process so its goal is to expose faults in these components.
● For most systems, the developers of components are responsible for component
testing.
● There are different types of component that may be tested at this stage:

1. Individual functions or methods within an object

2. Object classes that have several attributes and methods
3. Composite components made up of several different objects or functions.
● These composite components have a defined interface that is used to access their
functionality.
● Individual functions or methods are the simplest type of component and your tests
are a set of calls to these routines with different input parameters.
● When you are testing object classes, you should design your tests to provide
coverage of all of the features of the object.

Test Case Design

 ● A test case is a document, which has a set of test data, preconditions, expected
results and postconditions, developed for a particular test scenario in order to
verify compliance against a specific requirement.
● Test case gives detailed information about testing strategy, testing process,
preconditions, and expected output. These are executed during the testing
process to check whether the software application is performing the task for
that it was developed or not.
● Test case helps the tester in defect reporting by linking defect with test case ID.
Detailed test case documentation works as a full proof guard for the testing
team because if developer missed something, then it can be caught during
execution of these full-proof test cases.

Typical Test Case Parameters:

● Test Case ID

● Test Scenario

● Test Case Description

● Test Steps

● Prerequisite

● Test Data

● Expected Result

● Test Parameters

● Actual Result

● Environment Information

● Comments

Example:
Test Automation

● Testing is an expensive and laborious phase of the software process.

● As a result,testing tools were among the first software tools to be
developed.
● These tools offer a range of facilities and their use can significantly
reduce the costs of testing.
● The tests themselves should be written in such a way that they indicate
whether the tested system has behaved as expected.
● A software testing workbench is an integrated set of tools to support the
testing process. In addition to testing frameworks that support automated
test execution, a workbench may include tools to simulate other parts of
the system and to generate system test data.
● Following Figure shows some of the tools that might be included in such a
testing workbench:
1. Test manager Manages the running of program tests. The test manager
keeps track of test data, expected results and program facilities tested. Test
automation frameworks such as JUnit are examples of test managers.
2. Test data generator Generates test data for the program to be tested. This
may be accomplished by selecting data from a database or by using patterns to
generate random data of the correct form.
3. Oracle Generates predictions of expected test results. Oracles may either be
previous program versions or prototype systems. Back-to-back testing involves
running the oracle and the program to be tested in parallel. Differences in their
outputs are highlighted.
4. File comparator Compares the results of program tests with previous test
results and reports differences between them. Comparators are used in
regression testing where the results of executing different versions are
compared. Where automated tests are used, this may be called from within the
tests themselves.
5. Report generator Provides report definition and generation facilities for test
results.
6. Dynamic analyser Adds code to a program to count the number of times
each statement has been executed. After testing, an execution profile is
generated showing how often each program statement has been executed.
7. Simulator Different kinds of simulators may be provided.
Target simulators simulate the machine on which the program is to execute.
User interface simulators are script-driven programs that simulate multiple
simultaneous user interactions. Using simulators for I/O means that the timing of
transaction sequences is repeatable.
 CHAPTER 3
Software Measurement:
A measurement is a manifestation of the size, quantity, amount, or dimension of
a particular attribute of a product or process.
Software measurement is a titrate impute of a characteristic of a software
product or the software process. It is an authority within software engineering.
The software measurement process is defined and governed by ISO Standard.

Need for Software Measurement:

Software is measured to:

● Create the quality of the current product or process.
● Anticipate future qualities of the product or process.
● Enhance the quality of a product or process.
● Regulate the state of the project in relation to budget and schedule

Software Measurement Principles/Activities:

The software measurement process can be characterized/distinguished by five

activities-
1. Formulation: This helps to perform measurement and appropriate
metric is created for the software under consideration.
2. Collection: For the purpose of deriving the formulated metrics,
collection collects the data
3. Analysis: The metrics is calculated by it and also calculates use of
mathematical tools.
4. Interpretation: This analyzes the metrics for the purpose of getting
insight into the quality of representation.
5. Feedback: Recommendation derived from the product metrics
transmitted to the software team.
Metrics:

A metric is a measurement of the level at which any impute belongs to a system

product or process.

Software metrics will be useful only if they are characterized effectively and
validated so that their worth is proven. There are 4 functions related to software
metrics:

1. Planning
2. Organizing
3. Controlling
4. Improving

Characteristics of software Metrics:

1. Quantitative: Metrics must possess quantitative nature. It means

metrics can be expressed in values.
2. Understandable: Metric computation should be easily understood,
and the method of computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the
development of the software.
4. Repeatable: The metric values should be the same when measured
repeatedly and consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any
programming language.
Classification of Software Metrics:

There are 3 types of software metrics:

1. Product Metrics: Product metrics are used to evaluate the state of the
product, tracing risks and undercover prospective problem areas. The
ability of the team to control quality is evaluated.
2. Process Metrics: Process metrics pay particular attention to
enhancing the long-term process of the team or organization.
3. Project Metrics: The project matrix describes the project characteristic
and execution process.
○ Number of software developer
○ Staffing patterns over the life cycle of software
○ Cost and schedule
○ Productivity

Advantages of Software Metrics :

1. Reduction in cost or budget.

2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product,.
6. It helps to determine the complexity of the code and to test the code
with resources.
7. It helps in providing effective planning, controlling and managing of the
entire product.
Disadvantages of Software Metrics :

1. It is expensive and difficult to implement the metrics in some cases.

2. Performance of the entire team or an individual from the team can’t be
determined. Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measure the unwanted data which is wastage of time.
5. Measuring the incorrect data leads to make wrong decision making.

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.
● If a software organization maintains simple records, a table of
size-oriented measures, such as shown in below fig.
● The table lists each software develop project that has been completed
over past few years and corresponding measure for that project referring
to the table entry for project alpha: 12,100 lines of code were developed
with 24 person-months of effort at a cost 0f $168,000.
● It should be noted that the effort and cost recorded in the table represents
all software engineering activities (analysis, design, code and test) not just
coding.
Further information for project alpha indicates that 365 pages of
documentation were developed,
134 error were recorded before the software was released and
29 defects were encountered after release to the customer within the first
year of the operation.
Three people worked on the development of software for project alpha.
● To develop metrics that can be assimilated with similar metrics from other
projects, we choose Line of Code as our normalization value.
● So, from information given in table , a set of simple size-oriented metrics
can be developed for each projects:
Errors per KLOC (Thousands line of code)
Defects per KLOC,
$ Per KLOC,
Pages of documentation per KLOC
● Size-oriented metrics are not universally accepted as the best way to
measure the software process but most of the controversy swirls around
the use line of code as key measure.
● Proponent(a person who speaks or argues, often publicly, in support of a particular idea
or persuades people to do something) of line of code measure claims that LOC is
an “artefact” of all software development projects that can be easily
counted, that many existing software estimation models use LOC or
KLOC as a key input, and that a large body of literature and data
predicated on LOC already exists.
● On the other hand, opponent argue that LOC measures are programming
language dependent, that when productivity is considered, they are short
 programs, cannot easily accommodate nonprocedural language, and that
their use in estimation requires a level of detail that may be difficult to
achieve.

Function-Oriented Metrics

● Function-oriented software metrics use a measure of the

functionality delivered by the application as a normalization
value.
● Since ‘functionality’ cannot be measured directly, it must be
derived indirectly using other direct measures.
● Function-oriented metrics were first proposed by “Albrecht” , who
suggested a measure called the function point.(MEAN FOR
MEASURING FUNCTIONALITY)
● Function points are derived using an empirical relationship(
relationship or correlation that is supported by experiment and
observation but not necessarily supported by theory.) based on
countable (direct) measures of software's information domain and
assessments of software complexity.
● Function points are computed by completing the table as shown
below. Five information domain characteristics are determined
and counts are provided in the appropriate table location.
Information domain values are defined in the following manner:
 ● Number of user outputs. Each user output that provides application oriented
information to the user is counted. In this context output refers to reports,
screens, error messages, etc. Individual data items within a report are not
counted separately.
● Number of user inquiries. An inquiry is defined as an on-line input that results
in on-line output. Each distinct inquiry is counted.
● Number of files. Each logical master file (i.e., a logical grouping of data that
may be one part of a large database or a separate file) is counted.
● Number of external interfaces. All machine readable interfaces (e.g., data files
on storage media) that are used to transmit information to another system are
counted.

● Once these data have been collected, a complexity value is associated with
each count. Organizations that use function point methods develop criteria for
determining whether a particular entry is simple, average, or complex.

The software complexity can be computed by answering the following questions

:
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 data entry?
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation 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?

Each of the above questions is answered using a scale that ranges from o to 5
(not important or applicable to absolutely essential).
This scale is shown below :

After calculating the function point, various other measures can be calculated as shown
below :
Productivity = FP / person-month
Quality = Number of faults / FP
Cost = $ / FP
Documentation = Pages of documentation / FP

Calculating Function Point :

Disadvantages of Function-Oriented Metrics :

● Function Oriented Metrics was only developed for business systems,
therefore it is valid for only that domain.
● In this, some of the aspects are subjective and have not been validated.
● The function point does not have any physical meaning. It is just a
number.

Example:
Compute the FP for an embedded system with the following characteristics:
1. Internal data structures = 8
2. No. of user inputs = 32
3. No. of user outputs = 60
4. No. of user inquiries = 24
5. No. of external interfaces = 2

Assume complexity of the above counts is average case = 3.

Explanation:
Step-1: We draw the Table first for computing FPs.

Averag Comple
e x
Sr. Measurem Simple Weighti Weighti
No ent * Weightin ng ng Calculat
. Parameter Count * g factor factor factor ed Value

Number of
external
1 inputs(EI) 32 * 3 4 6 128

Number of
external
2 outputs(EO) 60 * 4 5 7 300

Number of
external
Inquiries(EQ
3 ) 24 * 3 4 6 96

Number of
internal files
4 (ILF) 8 * 7 10 15 80
 Number of
external
interfaces(EI
5 F) 2 * 5 7 10 14

Count –
Total —–> 618

Step-2: Find the sum of all fi (1 to 14)

Σ(&fi) = 14 * 3 = 42

Step-3: Calculate the functional point:

FP = Count-total * [0.65 + 0.01 *Σ(&fi) ]
= 618 * [0.65 + 0.01 * 42]
= 618* [0.65 + 0.42]
= 618 * 1.07
= 661.26

CHAPTER 4

SOFTWARE COST ESTIMATION

Estimation involves answering the following questions:

1. How much effort is required to complete each activity ?

2. How much calendar time is needed to complete each activity ?
3. What is the total cost of each activity ?

● Project cost estimation and project scheduling are normally carried out
together.
● The costs of development are primarily the costs of the effort involved, so
the effort computation is used in both the cost and the schedule estimate.
● However, you may have to do some cost estimation before detailed
schedules are drawn up.
● These initial estimates may be used to establish a budget for the project
or to set a price for the software for a customer:
There are three parameters involved in computing the total cost of a software
development project:
1. Hardware and software costs including maintenance
2. Travel and training costs
3. Effort costs (the costs of paying software engineers

Cost Estimation Models:

A model may be static or dynamic.
In a static model, a single variable is taken as a key element for calculating cost
and time.
In a dynamic model, all variable are interdependent, and there is no basic
variable

Static, Single Variable Models: When a model makes use of single variables
to calculate desired values such as cost, time, efforts, etc. is said to be a single
variable model.

The most common equation is:

Where C = Costs
L= size
a and b are constants

The Software Engineering Laboratory established a model called SEL model, for
estimating its software production.
This model is an example of the static, single variable model.
Static multivariable model
WALSTON and FELIX develop the models at IBM provide the following
equation gives a relationship between lines of source code and effort:

In the same manner duration of development is given by

Software Productivity
● You can measure productivity in a manufacturing system by counting the
number of units that are produced and dividing this by the number of
person-hours required to produce them.
● However, for any software problem, there are many different solutions,
each of which has different attributes. One solution may execute more
efficiently while another may be more readable and easier to maintain.
● When solutions with different attributes are produced, comparing their
production rates is not really meaningful.
● Nevertheless, as a project manager, you may be faced with the problem
of estimating the productivity of software engineers.
● You may need these productivity estimates to help define the project
cost or schedule, to inform investment decisions or to assess whether
process or technology improvements are effective.
● Productivity estimates are usually based on measuring attributes of the
software and dividing this by the total effort required for development.
There are two types of metric that have been used:
1. Size-related metrics.
● These are related to the size of some output from an activity.
● The most commonly used size- related metric is lines of delivered
source code(LOC).
● Other metrics that may be used are the number of delivered object code
instructions or the number of pages of system documentation.
2. Function-related metrics.
● These are related to the overall functionality of the delivered software.
● Productivity is expressed in terms of the amount of useful functionality
produced in some given time.
● Function points and object points are the best-known metrics of this
type.

Estimation Techniques
● Organizations need to make software effort and cost estimates.
● To do so, one or more of the techniques described below may be used.
● All of these techniques rely on experience-based judgements by project
managers who use their knowledge of previous projects to arrive at an
estimate of the resources required for the project.
● However, there may be important differences between past and future
projects. Many new development methods and techniques have been
introduced in the last 10 years.
● Some examples of the changes that may affect estimates based on
experience include:
1. Distributed object systems rather than mainframe-based systems
2. Use of web services
3. Use of ERP(Enterprise resource planning) or database-centered systems
4. Use of off-the-shelf software rather than original system development
5. Development for and with reuse rather than new development of all
parts of a system
6. Development using scripting languages such as TCL or Perl
7. The use of CASE tools and program generators rather than
unsupported software development.
Various Cost estimation techniques are as follows:
● Algorithmic cost modeling
○ A model is developed using historical cost information that relates some
software metric (usually its size) to the project cost.
○ An estimate is made of that metric and the model predicts the effort required.
● Expert judgment
○ Several experts on the proposed software development techniques and the
application domain are consulted.
○ They each estimate the project cost.
○ These estimates are compared and discussed.
○ The estimation process iterates until an agreed estimate is reached.
● Estimation by analogy (comparing)
○ 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 these completed
projects. ○ Myers (Myers, 1989) gives a very clear description of this approach.
● Parkinson’s Law
○ Parkinson’s Law states that work expands to fill the time available.
○ The cost is determined by available resources rather than by objective
assessment.
○ If the software has to be delivered in 12 months and 5 people are available,
the effort required is estimated to be 60 person-months.
● Pricing to win
○ The software cost is estimated to be whatever the customer has available to
spend on the project.
○ The estimated effort depends on the customer’s budget and not on the
software functionality.

Algorithmic cost modeling:

● Algorithmic cost modeling uses a mathematical expression to predict
project costs based on estimates of the project size, the number of software
engineers, and other process and product factors.
● An algorithmic cost model can be developed by analyzing the costs and
attributes of completed projects and finding the closest fit mathematical
expression to the actual project.
● In general, an algorithmic cost estimate for software cost can be expressed
as:
● In this equation A is a constant factor that depends on local organizational
practices and the type of software that is developed.
● Variable SIZE may be either the code size or the functionality of software
expressed in function or object points.
● M is a multiplier made by combining process, product and development
attributes, such as the dependability requirements for the software and the
experience of the development team.
● The exponential component B associated with the size estimate expresses
the non-linearity of costs with project size.
● As the size of the software increases, extra costs emerge.
● The value of exponent B usually lies between 1 and 1.5.
● All algorithmic models have the some difficulties:
○ It is difficult to estimate/calculate SIZE in the early stage of development.
Function or object point estimates can be produced easier than estimates of
code size but are often inaccurate.
○ The estimates of the factors contributing to B and M are subjective.
Estimates vary from one person to another person, depending on their
background and experience with the type of system that is being developed.
● The number of lines of source code in software is the basic software metric
used in many algorithmic cost models.
● The code size can be estimated by previous projects, by converting
function or object points to code size, by using a reference component to
estimate the component size, etc.
● The programming language used for system development also affects the
number of lines of code to be implemented.
● Furthermore, it may be possible to reuse codes from previous projects and the
size estimate has to be adjusted to take this into account.

COCOMO MODEL/Constructive Cost Estimation Model

Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.

● COCOMO is one of the most generally used software estimation models in the
world. COCOMO predicts the efforts and schedule of a software product
based on the size of the software.
● The necessary steps in this model are:
○ Get an initial estimate of the development effort from evaluation of
thousands of delivered lines of source code (KDLOC).
○ Determine a set of 15 multiplying factors from various attributes of the
project.
○ Calculate the effort estimate by multiplying the initial estimate with all the
multiplying factors i.e., multiply the values in step1 and step2.
● The initial estimate (also called nominal estimate) is determined by an
equation of the form used in the static single variable models, using KDLOC as
the measure of the size.
● To determine the initial effort Ei in person-months the equation used is of
the type is shown below
Ei=a*(KDLOC)b
where The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

1. Organic:
❏ A development project can be treated of the organic type, if the project deals
with developing a well-understood application program, the size of the
development team is reasonably small, and the team members are
experienced in developing similar methods of projects.
❏ Examples of this type of projects are simple business systems, simple
inventory management systems, and data processing systems.
2. Semidetached:
❏ A development project can be treated with semidetached type if the
development consists of a mixture of experienced and inexperienced staff.
❏ Team members may have finite experience in related systems but may be
unfamiliar with some aspects of the order being developed.
❏ Example of Semidetached system includes developing a new operating
system (OS), a Database Management System (DBMS), and complex inventory
management system.
3. Embedded:
❏ A development project is treated to be of an embedded type, if the software
being developed is strongly coupled to complex hardware, or if the stringent
regulations on the operational method exist.
❏ For Example: ATM, Air Traffic control. For three product categories, Bohem
provides a different set of expression to predict effort (in a unit of person
month)and development time from the size of estimation in KLOC(Kilo Line of
code) efforts estimation takes into account the productivity loss due to holidays,
weekly off, coffee breaks, etc.

According to Boehm, software cost estimation should be done through three

stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate

size of the project parameters.
The following expressions give the basic COCOMO estimation model:
2. Intermediate Model:
The basic Cocomo model considers that the effort is only a function of the
number of lines of code and some constants calculated according to the various
software systems.
The intermediate COCOMO model recognizes these facts and refines the initial
estimates obtained through the basic COCOMO model by using a set of 15
cost drivers based on various attributes of software engineering.(The cost
drivers are multiplicative factors that determine the effort required to complete
your software project.)
3. Detailed COCOMO Model:
Detailed COCOMO incorporates all qualities of the standard version with an
assessment of the cost drivers' effect on each method of the software
engineering process.
The detailed model uses various effort multipliers for each cost driver property.
In detailed cocomo, the whole software is differentiated into multiple modules,
and then we apply COCOMO in various modules to estimate effort and then
sum the effort.

The Six phases of detailed COCOMO are:

1. Planning and requirements
2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost

drivers are given according to every phase of the software lifecycle.
Project Duration and Staffing

As well as estimating the effort required to develop a software system and

the overall project costs, project managers must also estimate how long
the software will take to develop and when staff will be needed to
work on the project.
● The development time for the project is called the project schedule.
● Increasingly, organizations are demanding shorter development
schedules so that their products can be brought to market before their
competitor’s.
● The relationship between the number of staff working on a project, the
total effort required and the development time is not linear.
● As the number of staff increases, more effort may be needed. The
reason for this is that people spend more time communicating and defining
interfaces between the parts of the system developed by other people.
● Doubling the number of staff (for example) therefore does not mean that
the duration of the project will be halved.
● The COCOMO model includes a formula to estimate the calendar time
(TDEV) required to complete a project.
The time computation formula is the same for all COCOMO levels:
TDEV = 3 (PM)(0.33+0.2*(B-1.01))

PM is the effort computation and

B is the exponent computed,
● This computation predicts the nominal schedule for the project.
● However, the predicted project schedule and the schedule required by
the project plan are not necessarily the same thing.
● The planned schedule may be shorter or longer than the nominal
predicted schedule.
● However, there is obviously a limit to the extent of schedule changes,
and the COCOMO II model predicts this:
TDEV = 3 (PM)(0.33+0.2*(B-1.01)) SCEDPercentage/100
SCEDPercentage is the percentage increase or decrease in the nominal
schedule.
● If the predicted figure then differs significantly from the planned
schedule, it suggests that there is a high risk of problems delivering the
software as planned
● To illustrate the COCOMO development schedule computation, assume
that 60 months of effort are estimated to develop a software system
Assume that the value of exponent B is 1.17. From the schedule equation,
the time required to complete the project is:
TDEV = 3 (60)0.36 = 13 months
● In this case, there is no schedule compression or expansion, so the last
term in the formula has no effect on the computation.
● An interesting implication of the COCOMO model is that the time
required to complete the project is a function of the total effort required for
the project.
● It does not depend on the number of software engineers working on the
project.
● This confirms the notion that adding more people to a project that is
behind schedule is unlikely to help that schedule to be regained. Myers
(Myers, 1989) discusses the problems of schedule acceleration.
● He suggests that projects are likely to run into significant problems if
they try to develop software without allowing sufficient calendar time.