ISO 9001:2015

Software Engineering
Ashish T. Bhole, BE, M.Tech., PhD (Pursuing)
Associate Professor
Department of Computer Engineering
SSBT’s College of Engineering & Technology, Bambhori, Jalgaon
 ISO 9001:2015

Unit‐IV:
U it IV
Coding and Software Testing

01/08/2019 Mr Ashish T Bhole 2

 Acknowledgement
ISO 9001:2015

• Text Book1: K. K. Aggarwal

gg & Yogesh
g Singh,
g , Software
Engineering, Third Edition (2008), New Age International
• Text
e t Book2:
oo Rajib
aj b Mall,
a , Fundamentals
u da e ta s of
o So
Software
t ae
Engineering, Fourth Edition (2014), Prentice Hall of India
• Reference Book: Roger S. Pressman, Software
Engineering: A Practitioner’s Approach, Seventh Edition
((2010),
) McGraw Hill
01/08/2019 Mr Ashish T Bhole 3
Coding
„ The input to the coding phase
is the design document.
document
„ During coding phase:

„ modules identified in the design

document are coded according
to the module specifications.
1
Coding
„ At the end of the design phase we have:
„ module structure (e.g. structure chart) of
the system
„ module specifications:
„ data structures and algorithms for each module.
„ Objective of coding phase:
„ transform design into code
„ unit test the code.

2
 C di Standards
Coding St d d
„ Good
G d software
f d
development
l
organizations require their
programmers to:
„ adhere
dh to
t some standard
t d d style
t l
g
of coding
„ called coding standards.

3
 C di Standards
Coding St d d
„ Many software development
organizations:
„ formulate their own coding
standards that suits them most,
„ require their engineers to follow

these standards rigorously.

4
 C di Standards
Coding St d d
„ Advantage of adhering to a
standard style of coding:
„ it gives a uniform appearance to
tthe
e codes written
tte by ddifferent
ee t
engineers,
„ it enhances code understanding
understanding,
„ encourages good programming

practices.
5
 C di Standards
Coding St d d
„ A coding
d standard
d d
„ sets out standard waysy of
doing several things:
„ the way
ay variables
a ab are
a named,
a d,
„ code is laid out,

„ maximum
a u number
u b of o source
ou
lines allowed per function, etc.

6
 C di guidelines
Coding id li
„ Provide
P id generall suggestions
ti
g g coding
regarding g style
y to be
followed:
„ leave actual implementation of
the guidelines:
„ to the discretion of the
g
individual engineers.
7
Code inspection and code
walk throughs
„ After a module
Aft d l has
h been
b
coded,
„ code inspection and code walk
through
g are carried out
„ ensures that coding standards
are followed
„ helps detect as many errors as
possible before testing.
8
Code inspection and code
walk throughs
„ Detect
D t t as many errors as
possible during inspection and
walkthrough:
„ detected errors require less effort
for correction
„ much higher effort needed if errors
were to be detected during
g
integration or system
y testing.
g

9
Coding Standards and
G id li
Guidelines
„ Good
G d organizations
i ti usually
ll develop
d l
their own coding standards and
guidelines:
„ depending on what best suits their
organization.
„ We will discuss some representative
coding standards and guidelines.

10
Representative Coding
St d d
Standards
„ R l for
Rules f limiting
li iti the
th use off globals:
l b l
„ what types of data can be declared
global and what can not.
„ Naming
g conventions for
„ global variables,
„ local variables, and

„ constant identifiers.

11
Representative Coding
St d d
Standards
„ Contents of headers for different
modules:
„ The headers of different modules
should be standard for an
organization.
„ The exact format for header
information is usually specified.

12
 Representative Coding Standards
„ Header
d data:
d
„ Name of the module,
„ date on which the module was created,
„ author's name,
„ modification
difi i history,
hi
„ synopsis of the module,
„ diff
differentt ffunctions
ti supported,
t d along
l with
ith
their input/output parameters,
„ global variables accessed/modified by the
module.
13
Representative Coding
St d d
Standards
„ Error return conventions and
exception handling mechanisms.
„ the way error and exception
conditions are handled should be
standard within an organization.
organization
„ For example, when different functions
encounter error conditions
„ should either return a 0 or 1
consistently.
y

14
 Representative Coding Guidelines

„ Do not use too clever and difficult to

understand coding style
style.
„ Code should be easy to understand.
„ Many inexperienced engineers
actuallyy take p
pride:
„ in writing cryptic and
incomprehensible code
code.
15
 Representative Coding Guidelines
„ Clever coding can obscure meaning
of the code:
„ hampers understanding.
„ makes later maintenance difficult
difficult.
„ Avoid obscure side effects.

16
 Representative Coding Guidelines

„ The side effects of a function call

include:
„ modification of parameters passed by
reference,
„ modification
f off global variables,
„ I/O operations.
„ A obscure
An b side
id effect:
ff t
„ one that is not obvious from a casual
examination of the code
code.

17
 Representative Coding Guidelines
„ Obscure side effects make it difficult
to understand a p
piece of code.
„ For example,
„ if a global variable
a iable is changed
obscurely in a called module,
„ it becomes difficult
ff ffor anybody trying
to understand the code.

18
 Representative Coding Guidelines
„ Do nott use an id
D identifier
tifi (variable
( i bl
name) for multiple purposes.
„ Programmers often use the same
p purposes.
identifier for multiple p p
„ For example, some programmers use

a temporary loop variable

„ also for storing the final result.

19