ISO 9001:2015
Software Engineering
Ashish T. Bhole, BE, [Link]., 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
