Unit-4

Software engineering
List of Contents

Implementation
Coding Standard and Guidelines
Review
Unit Testing
Verification and
Validation
 Implementation

• During the implementation phase, the software engineer

translates the design specifications into source codes in
some programming languages.

• Implementation is the software development phase that

effects the testing and maintenance activities.

• the main goal of implementation is to produce quality

source codes that can reduce the cost of testing and
maintenance .
 Implementation

1) Coding principles
– Information hiding
– Structure programming features
– Maximize Cohesion and Minimize Coupling
– Code Reusability
– KISS(Keep It Simple, Stupid)
– Simplicity, Extensibility, and Effortlessness
– Code Verification
– Code Documentation
– Separation of Concern
– Follow Coding Standards, Guidelines, and Styles
 Implementation

2) Coding Styles
– Use of goto statements
– Use of control constructs
– Define user-defined data types
– Program size
– Information hiding
– Program documentation prologues
– Commenting code
– Use of temporary variables
– Avoid patching bad code
 Implementation

3) Coding Errors
Compilation Errors
Logical Errors
Runtime Errors
4) Coding Standards
Naming Conventions
Don’t Be Too Clever
Code Formatting
Avoid Deep Nesting
Error Handling
Modularization of code
 Implementation

5) Coding Process
Traditional Coding Process
Test-Driven Development

6) Coding Verification
Code review
Code Walkthrough
Code inspection
Pair programming
Static Analysis
Testing
 Implementation

7) Code Documentation
Internal Documentation
System Documentation
User Documentation
Process Documentation
Daily Documentation
 Coding Standard and Guidelines

• Coding is undertaken once the design phase is complete

and the design documents have been successfully
reviewed.

• In the coding phase, every module specified in the

design document is coded and unit tested. During unit
testing, each module is tested in isolation from other
modules. That is, a module is tested independently as
and when its coding is complete.
 Coding Standard and Guidelines

• After all the modules of a system have been coded and

unit tested, the integration and system testing phase is
undertaken.

• Over the years, the general perception of testing as

monkeys typing in random data and trying to crash the
system has changed. Now testers are looked upon as
masters of specialized concepts, techniques, and tools.
 Coding Standard and Guidelines

CODING:
• The input to the coding phase is the design document
produced at the end of the design phase.

• During the coding phase, different modules identified in

the design document are coded according to their
respective module specifications.

• The objective of the coding phase is to transform the

design of a system into code in a high-level language,
and then to unit test this code.
 Coding Standard and Guidelines

The main advantages of adhering to a standard style of

coding are the following:
– A coding standard gives a uniform appearance to the
codes written by different engineers.
– It facilitates code understanding and code reuse.
– It promotes good programming practices.
 Coding Standard and Guidelines

Representative coding standards

– Rules for limiting the use of globals

• These rules list what types of data can be declared
global and what cannot, with a view to limit the
data that needs to be defined with global scope.

– Standard headers for different modules

• The header of different modules should have
standard format and information for ease of
understanding and maintenance.
 Coding Standard and Guidelines

Standard headers for different modules:

– Name of the module.
– Date on which the module was created.
– Author’s name.
– Modification history.
– Synopsis of the module. This is a small write-up about
what the module does.
– Different functions supported in the module, along
with their input/output parameters.
– Global variables accessed/modified by the module.
 Coding Standard and Guidelines

Naming conventions for global variables, local

variables, and constant identifiers:
• A popular naming convention is that variables are
named using mixed case lettering.
• Global variable names would always start with a capital
letter (e.g., Global-Data) and
• local variable names start with small letters (e.g., local-
Data). Constant names should be formed using capital
letters only (e.g., CONSTDATA).
 Coding Standard and Guidelines

Conventions regarding error return values and

exception handling mechanisms:
– The way error conditions are reported by different
functions in a program should be standard within an
organization.
• Representative coding guidelines:
• Do not use a coding style that is too clever or too
difficult to understand:
– Code should be easy to understand. Many
inexperienced engineers actually take pride in writing
cryptic and incomprehensible code.
 Coding Standard and Guidelines

 Avoid obscure side effects:

• The side effects of a function call include modifications
to the parameters passed by reference, modification of
global variables, and I/O operations.
• An obscure side effect is one that is not obvious from a
casual examination of the code.
• Obscure side effects make it difficult to understand a
piece of code.
 Coding Standard and Guidelines

 Do not use an identifier for multiple purposes:

• Programmers often use the same identifier to denote
several temporary entities.
• Each variable should be given a descriptive name
indicating its purpose. This is not possible if an
identifier is used for multiple purposes.
• Use of a variable for multiple purposes can lead to
confusion and make it difficult for somebody trying to
read and understand the code.
 Coding Standard and Guidelines

Length of any function should not exceed 10 source

lines:
• A lengthy function is usually very difficult to understand
as it probably has a large number of variables and
carries out many different types of computations.
• For the same reason, lengthy functions are likely to have
disproportionately larger number of bugs.
Do not use GO TO statements:
• Use of GO TO statements makes a program
unstructured. This makes the program very difficult to
understand, debug, and maintain.
 CODE REVIEW
• Testing is an effective defect removal mechanism.
However, testing is applicable to only executable code.
• Review is a very effective technique to remove defects
from source code.
• review has been acknowledged to be more cost-effective
in removing defects as compared to testing.
• Code review for a module is undertaken after the
module successfully compiles.
• code review does not target to design syntax errors in a
program, but is designed to detect logical, algorithmic,
and programming errors.
 CODE REVIEW
• Eliminating an error from code involves three main
activities
– testing,
– debugging, and then correcting the errors.
• Testing is carried out to detect if the system fails to
work satisfactorily for certain types of inputs and under
certain circumstances.
• debugging is carried out to locate the error that is
causing the failure and to remove it.
• errors are directly detected, thereby saving the
significant effort that would have been required to
locate the error.
 CODE REVIEW
The following two types of reviews are carried out on the
code of a module:
– Code walkthrough.
– Code inspection.
Code walkthrough:
– Code walkthrough is an informal code analysis
technique.
– In this technique, a module is taken up for review
after the module has been coded, successfully
compiled, and all syntax errors have been eliminated.
– A few members of the development team are given the
code a couple of days before the walkthrough meeting.
 CODE REVIEW
• The main objective of code walkthrough is to discover
the algorithmic and logical errors in the code.
• The team performing code walkthrough should not be
either too big or too small. Ideally, it should consist of
between three to seven members.
• Discussions should focus on discovery of errors and
avoid deliberations on how to fix the discovered errors.
• In order to foster co-operation and to avoid the feeling
among the engineers that they are being watched and
evaluated in the code walkthrough meetings, managers
should not attend the walkthrough meetings.
 CODE REVIEW
Code Inspection:
• During code inspection, the code is examined for the
presence of some common programming errors.
• This is in contrast to the hand simulation of code
execution carried out during code walkthroughs.
• The principal aim of code inspection is to check for the
presence of some common types of errors that usually
creep into code due to programmer mistakes and
oversights and to check whether coding standards have
been adhered to.
CODE REVIEW
 SOFTWARE DOCUMENTATION

• When a software is developed, in addition to the

executable files and
• The source code, several kinds of documents such as
users’ manual, software requirements specification
(SRS) document, design document, test document,
installation manual, etc., are developed as part of the
software engineering process.
• All these documents are considered a vital part of any
good software development practice. Good documents
are helpful in the following ways:
SOFTWARE DOCUMENTATION
 SOFTWARE DOCUMENTATION
Different types of software documents can broadly be
classified into the following:
• Internal documentation:
– These are provided in the source code itself.
• External documentation:
– These are the supporting documents such as SRS
document, installation document, user manual, design
document, and test document.
• Careful experiments suggest that out of all types of
internal documentation, meaningful variable names is
most useful while trying to understand a piece of code.
External Documentation
 External Documentation

Gunning’s fog index:

– Gunning’s fog index (developed by Robert Gunning in
1952) is a metric that has been designed to measure
the readability of a document.
– The computed metric value (fog index) of a
document indicates the number of years of formal
education that a person should have, in order to be
able to comfortably understand that document.
Gunning’s fog index
 TESTING
• The aim of program testing is to help realize identify all
defects in a program.
How to test a program?
• Testing a program involves executing the program with a set
of test inputs and observing if the program behaves as
expected.
• If the program fails to behave as expected, then the input data
and the conditions under which it fails are noted for later
debugging and error correction.
 Terminologies
• As is true for any specialized domain, the area of
software testing has come to be associated with its own
set of terminologies.
• In the following, a few important terminologies that have
been standardized by the IEEE Standard Glossary of
Software Engineering Terminology [IEEE90]:
 Terminologies

• The terms error, fault, bug, and defect are considered to

be synonyms in the area of program testing.
 Verification versus validation
• The objectives of both verification and validation
techniques are very similar since both these techniques
are designed to help remove errors in a software.
 Verification versus validation
Continues…
 Verification versus validation
Continues…
 Verification versus validation
• Verification techniques can be viewed as an attempt to
achieve phase containment of errors.
• Phase containment of errors has been acknowledged to
be a cost-effective way to eliminate program bugs, and is
an important software engineering principle.
• The principle of detecting errors as close to their points
of commitment as possible is known as phase
containment of errors.
• Phase containment of errors can reduce the effort
required for correcting bugs.
Verification versus validation
 Testing Activities
• Testing involves performing the following main
activities:
 Testing Activities
• Testing involves performing the following main
activities:
 Why Design Test Cases?
• When test cases are designed based on random input
data, many of the test cases do not contribute to the
significance of the test suite, That is, they do not help
detect any additional defects not already being detected
by other test cases in the suite.

• A minimal test suite is a carefully designed set of test

cases such that each test case helps detect different
errors. This is in contrast to testing using some random
input values.
 Why Design Test Cases?
• There are essentially two main approaches to
systematically design test cases:
– Black-box approach
– White-box (or glass-box) approach
• Testing in the Large versus Testing in the Small:
– Unit testing
– Integration testing
– System testing
• During unit testing, the individual functions (or units) of
a program are tested.
• Unit testing is referred to as testing in the small, whereas
integration and system testing are referred to as testing in
the large.
 Why Design Test Cases?
• After testing all the units individually, the units are
slowly integrated and tested after each step of integration
(integration testing).

• Finally, the fully integrated system is tested (system

testing). Integration and system testing are known as
testing in the large.

• Why test each module (unit) in isolation first, then

integrate these modules and test, and again test the
integrated set of modules.
 UNIT TESTING
• Unit testing is undertaken after a module has been coded
and reviewed.
• This activity is typically undertaken by the coder of the
module himself in the coding phase.

• Before carrying out unit testing, the unit test cases have
to be designed and the test environment for the unit
under test has to be developed.
• The environment needed to perform unit testing.
 UNIT TESTING
Driver and stub modules:
• In order to test a single module, we need a complete
environment to provide all relevant code that is
necessary for execution of the module.
 UNIT TESTING
Stub: The role of stub and driver modules is pictorially
shown in Figure 10.3.
 A stub procedure is a dummy procedure that has the
same I/O parameters as the function called by the unit
under test but has a highly simplified behavior.
• For example, a stub procedure may produce the expected
behavior using a simple table look up mechanism.
 UNIT TESTING
Driver: A driver module should contain the non-local data structures
accessed by the module under test. Additionally, it should also
have the code to call the different functions of the unit under test
with appropriate parameter values for testing.