Software engineering mca

Software Engineering MCA II
sarojpandey.com.np

1
of
146

SOFTWARE
ENGINEERING

Purbanchal
University

MCA
II
Semester

sarojpandey.com.np

2
of
146

References:

1. Handouts
provided
by
Er.
Niraj
Man
Shrestha.
[2005]

2. Sommerville
I.,
Software
Engineering,
6th
Edition
PEA.

3. Pressman
R,
Software
Engineering
Practitioners
Approach
5th
Edition
MC
GrawHill.

4. Slides
from
Guest
Lectures.

Thanks
All!

sarojpandey.com.np

3
of
146

Syllabus

1. Introduction
to
Software
Engineering

3
Hours

Definition,
Scope,
Software
Products
Process,
Responsibilities
of
Software
Engineer,
Ethical

Issues

2. Software
design

8
Hours

Fundamental
design
concepts
and
principles,
Design
patterns,
Software
architecture,
structured

design,
Object-‐oriented
analysis
and
design,
Component-‐level
design,
Design
for
reuse

3. Using
APIs

5
Hours

API
Programming,
Class
browsers
and
related
tools,
Programming
by
example,
Debugging
in
the

API
environment,
Introduction
to
component-‐based
computing

4. Software
tools
and
environments

3
Hours

Programming
environments,
Requirements
analysis
and
design
modeling
tools,
Testing
tools,

Configuration
management
tools,
Tools
integration
mechanisms

5. Software
Processes

2
Hours

Software
life-‐cycle
and
process
models,
Process
assessment
models,
Software
process
metrics

6. Software
requirements
and
specifications

4
Hours

Requirements
elicitation,
Requirements
analysis
modeling
techniques,
Functional
and

nonfunctional
requirements,
Prototyping,
Basic
concepts
of
formal
specification
techniques

7. Software
validation

3
Hours

Validation
planning,
Testing
fundamentals,
including
test
plan
creation
and
test
case
generation,

Black-‐box
and
white-‐box
testing
techniques,
Unit
integration,
validation,
and
system
testing,

Object-‐oriented
testing,
Inspections

8. Software
evolution

3
Hours

Software
maintenance,
Characteristics
of
maintainable
software,
Reengineering,
Legacy
systems,

Software
reuse

sarojpandey.com.np

4
of
146

9. Software
Project
management

3
Hours

Team
management
(Team
processes,
Team
organization
and
decision-‐making,
Roles
and

responsibilities
in
a
software
team,
Role
identification
and
assignment,
Project
tracking,
Team

problem
resolution),
Project
scheduling,
Software
measurement
and
estimation
techniques,
Risk

analysis,
Software
quality
assurance,
Software
configuration
management,
Project
management

tools

10. Formal
methods

6
Hours

Formal
methods
concepts,
Formal
specification
languages,
Executable
and
non-‐executable

specifications,
Pre
and
post
assertions,
Formal
verification

11. Specialized
Systems
development

5
Hours

Real-‐time
systems,
Client-‐server
systems,
Distributed
systems,
Parallel
systems,
Web-‐based

systems,
High-‐integrity
systems

Main
Texts:

1. Sommerville
I,
Software
Engineering,
6th
Edition
PEA.

2. Pressman
R,
Software
Engineering
Practitioners
Approach
5th
Edition
MC
GrawHill

sarojpandey.com.np

5
of
146

1. Introduction
to
Software
Engineering

SOFTWARE
ENGINEERING:
A
DEFINITION

The
computer
science
discipline
concerned
with
developing
large
applications.
Software
engineering

covers
not
only
the
technical
aspects
of
building
software
systems,
but
also
management
issues,
such
as

directing
programming
teams,
scheduling,
and
budgeting.

Software
engineering
is:

• a
modeling
activity
-‐-‐
software
engineers
deal
with
complexity
through
modeling,
by
focusing
at

any
one
time
on
only
the
relevant
details
and
ignoring
everything
else.

o model
-‐-‐
an
abstraction
of
reality

o analysis
-‐-‐
constructing
a
model
of
the
problem
domain

o design
-‐-‐
constructing
a
model
of
the
solution
domain

o In
OO
methods,
the
solution
domain
model
is
an
extension
of
the
problem
domain
model,

so
that
the
structure
of
the
software
reflects
that
of
the
problem.

• a
problem-‐solving
activity
-‐-‐
models
are
used
to
search
for
an
acceptable
solution

o driven
by
experimentation

o reuses
pattern
solutions

o incremental
evolution
of
the
system
toward
one
acceptable
to
the
client

o revised
in
response
to
change

• a
knowledge
acquisition
activity
-‐-‐
in
modeling
the
application
and
solution
domain,
software

engineers
collect
data,
organize
it
into
information,
and
formalize
it
into
knowledge.

o nonlinear
-‐-‐
new
information
may
invalidate
previous
knowledge

§ risk-‐based
development
-‐-‐
identify
high-‐risk
components
to
avoid
late
surprises

§ issue-‐based
development
-‐-‐
execute
development
activities
in
parallel,
organizing

according
to
issues
which
still
need
resolution

§ iterative
development
-‐-‐
design
and
implement
the
high-‐risk
(difficult)
parts
first

• a
rationale-‐driven
activity
-‐-‐
software
engineers
need
to
capture
the
context
in
which
decisions

were
made
and
the
rationale
behind
these
decisions
in
order
to
understand
the
implications
of
a

proposed
change
when
revisiting
a
decision.

o assists
in
dealing
with
changing
systems

o useful
in
the
maintenance
phase

Wasserman
identifies
eight
fundamental
notions
that
form
the
basis
for
an
effective
discipline
of

software
engineering:

sarojpandey.com.np

6
of
146

• Abstraction
-‐-‐
a
description
of
the
problem
at
some
level
of
generalization
that
allows
us
to

concentrate
on
the
key
aspects
of
the
problem
without
getting
mired
in
the
details

• Analysis
and
Design
Methods
and
Notations
-‐-‐
when
you
work
as
a
team,
you
must

communicate
with
many
other
participants
in
the
development
process,
and
therefore
need
a

common
notation
for
communication
and
documentation

• Prototyping
-‐-‐
building
a
small
version
of
a
system,
usually
with
limited
functionality,
helps
the

user
to
identify
the
key
requirements
of
a
system
and
demonstrates
the
feasibility
of
a
design
or

approach;
commonly
used
to
design
a
good
user
interface

• Software
Architecture
-‐-‐
the
description
of
a
system
in
terms
of
a
set
of
architectural
units,
and

a
map
of
how
the
units
relate
to
one
another

• Software
Process
-‐-‐
the
organization
and
discipline
in
the
activities
of
the
process
of
developing

software
(as
well
as
to
the
products
that
result)
contribute
to
the
quality
of
the
software
and
the

speed
with
which
it
is
developed

• Reuse
-‐-‐
taking
advantage
of
the
commonalities
across
applications
by
reusing
items
from

previous
development

• Measurement
-‐-‐
quantitative
descriptions
of
improvements
to
processes,
resources,
and

methods
permit
us
to
compare
progress
across
disparate
projects
and
support
analysis
and

decision-‐making

• Tools
and
Integrated
Environment
-‐-‐
computer-‐aided
software
engineering
(CASE)
tools
are

designed
to
enhance
software
development,
but
rarely
address
the
entire
software
development

life
cycle.

The
scope
of
software
engineering
is
extremely
broad.
In
general,
five
aspects
are
involved:

o Historical
Aspects

o Economic
Aspects

o Maintenance
Aspects

o Requirements,
Analysis,
and
Design
Aspects

o Team
Development
Aspects

What
is
the
difference
between
building
bridges
and
building
operating
systems?

Answer:
Bridges
are
engineered
to
withstand
every
reasonably
anticipated
condition;
while
operating

systems
are
often
built
so
that
damages
caused
by
unanticipated
conditions
are
minimized.

sarojpandey.com.np

7
of
146

Corollary:
Bridges
are
assumed
to
be
perfectly
engineered;
while
operating
systems
are
assumed
to
be

imperfectly
engineered.

Another
major
difference:
Bridges
are
not
drastically
modified
during
its
useful
life;
while
operating

systems
are
often
drastically
modified.
(People
don't
rotate
the
bridge
90%
in
the
maintenance
phase,

but
people
do
want
to
modify
a
batch
operating
system
so
that
it
supports
time-‐sharing
operation!)

Software
Engineering
is
defined
as
the
discipline
whose
aim
is
the
production
of
fault-‐free
or
fault-‐
tolerant
software
that
satisfies
the
user's
needs
and
that
is
delivered
on
time
and
within
budget.

The
software
engineer
job
encompasses
a
fairly
wide
range
of
responsibilities.

Smaller
applications
and
systems
may
employ
just
a
few
software
engineers
to
manage
the
full
lifecycle

software
development
process.
Generally,
for
most
large-‐scale
applications,
jobs
are
broken
down
into

groups
that
focus
on
one
specific
area
of
the
software
or
just
a
specific
function
of
the
application
or

technology.
For
example,
one
system
may
employ
a
Software
Architect,
Design
Engineer,
Java

Developer
and
Quality
Assurance
Engineer.

In
today’s
market,
jobs
involving
web
services
have
become
more
common
as
businesses
continue
to

leverage
capabilities
of
the
Internet.
Object-‐oriented
analysis
and
design
has
is
a
common

requirements
for
most
business
application
design.
Many
of
the
responsibilities
listed
below
are
vague

and
general,
focusing
more
on
software
engineering
in
a
corporate
setting.
This
does
not
encompass

every
possible
software
engineering
responsibility
and
there
are
other
specialized
software

engineering
positions
such
as
embedded
software
engineers.

Common
alternate
job
titles
for
Software
Engineer
include:
Senior
Software
Engineer,
Software

Developer,
Software
Programmer,
Software
Designer,
Principal
Engineer,
Application
Developer,

Application
Engineer,
Embedded
Software
Engineer,
Java
Developer,
Java
Engineer,
Web
Services

Developer,
C++
Developer,
Quality
Assurance
Engineer.

Consultants
can
focus
under
any
category
but

most
technology-‐consulting
professionals
possess
experience
in
two
or
more
of
these
areas
as
a

specialty.

Common
Job
Responsibilities
for
Software
Engineer

1. Full
lifecycle
application
development

2. Designing,
coding
and
debugging
applications
in
various
software
languages.

3. Software
analysis,
code
analysis,
requirements
analysis,
software
review,
identification
of
code

metrics,
system
risk
analysis,
software
reliability
analysis

4. Object-‐oriented
Design
and
Analysis
(OOA
and
OOD)

5. Software
modeling
and
simulation

sarojpandey.com.np

8
of
146

6. Front
end
graphical
user
interface
design

7. Software
testing
and
quality
assurance

8. Performance
tuning,
improvement,
balancing,
usability,
automation.

9. Support,
maintain
and
document
software
functionality

10. Integrate
software
with
existing
systems

11. Evaluate
and
identify
new
technologies
for
implementation

12. Project
Planning
and
Project
Management

13. Maintain
standards
compliance

14. Implement
localization
or
globalization
of
software

Common
IT
Hardware,
Software,
Platform
and
Systems
Knowledge

C,
C++,
Java,
.NET,
Python,
BEA
WebLogic,
WebSphere,
J2EE,
JBoss,
ADO,
Perl,
HTML,
JSP,
JavaScript,

Web
services,
SOAP,
XML,
ASP,
JSP,
PHP,
MySQL,
SQL
Server,
Oracle,
UNIX,
Linux,
Redhat
Linux,
STL,

XSLT,
OWL,
AJAX,
J2EE,
J2ME,
J2SE,
Sun
Solaris.

Software
Engineer:

A
software
engineer
is
a
skilled
professional
focused
on
the
design
and
creation
of
software.
They
may
or

may
not
actually
code.
Because
they
are
interacting
with
both
business
functions
and
programmers,

Software
Engineers
should
have
excellent
communication
skills
and
should
enjoy
working
as
part
of
a

team.
They
will
often
have
to
explain
business
functions
to
programmers
and
technology
restraints
to

non-‐technical
business
managers.

Requirements
for
Software
Engineers:

• Skill
Set:

Successful
Software
Engineers
need
to
know
basic
business
functions,
have
a
firm
understanding
of

design
methodology,
and
excellent
communication
skills.

• Education:

Usually
requires
at
least
a
BS
in
Computer
Science.
Should
be
very
familiar
with
specialized
languages

relevant
to
the
technologies
employed
(Java,
C++,C#.NET)

• Code
Requirements:

Software
Engineers
may
or
may
not
write
code,
although
most
do
regularly.

sarojpandey.com.np

9
of
146

Software
Engineer
Compensation:

• Expected
Salary:
Compensation
for
Software
Engineers
varies
according
to
years
of
experience,
degree

and
geography.

• Additional
Incentives:
Often,
performance
bonuses
are
awarded
in
addition
to
base
salary.
Profit

sharing
or
stock
purchase
programs
may
provide
additional
compensation.
Many
newer
start
ups

offer
stock
in
addition
to
or
in
place
of
some
base
salary
compensation.

Software
Engineering
Code
of
Ethics
and
Professional
Practice

Software
engineers
shall
commit
themselves
to
making
the
analysis,
specification,
design,
development,

testing
and
maintenance
of
software
a
beneficial
and
respected
profession.
In
accordance
with
their

commitment
to
the
health,
safety
and
welfare
of
the
public,
software
engineers
shall
adhere
to
the

following
Eight
Principles:

Software
Engineering
Code
of
Ethics
and
Professional
Practice

SHORT
VERSION

1.
PUBLIC
-‐
Software
engineers
shall
act
consistently
with
the
public
interest.

2.
CLIENT
AND
EMPLOYER
-‐
Software
engineers
shall
act
in
a
manner
that
is
in
the
best
interests
of

their
client
and
employer
consistent
with
the
public
interest.

3.
PRODUCT
-‐
Software
engineers
shall
ensure
that
their
products
and
related
modifications
meet
the

highest
professional
standards
possible.

4.
JUDGMENT
-‐
Software
engineers
shall
maintain
integrity
and
independence
in
their
professional

judgment.

5.
MANAGEMENT
-‐
Software
engineering
managers
and
leaders
shall
subscribe
to
and
promote

an
ethical
approach
to
the
management
of
software
development
and
maintenance.

6.
PROFESSION
-‐
Software
engineers
shall
advance
the
integrity
and
reputation
of
the
profession

consistent
with
the
public
interest.

7.
COLLEAGUES
-‐
Software
engineers
shall
be
fair
to
and
supportive
of
their
colleagues.

8.
SELF
-‐
Software
engineers
shall
participate
in
lifelong
learning
regarding
the
practice
of
their

profession
and
shall
promote
an
ethical
approach
to
the
practice
of
the
profession.

sarojpandey.com.np

10
of
146

FULL
VERSION

Computers
have
a
central
and
growing
role
in
commerce,
industry,
government,
medicine,
education,

entertainment
and
society
at
large.
Software
engineers
are
those
who
contribute
by
direct
participation

or
by
teaching,
to
the
analysis,
specification,
design,
development,
certification,
maintenance
and
testing

of
software
systems.
Because
of
their
roles
in
developing
software
systems,
software
engineers
have

significant
opportunities
to
do
good
or
cause
harm,
to
enable
others
to
do
good
or
cause
harm,
or
to

influence
others
to
do
good
or
cause
harm.
To
ensure,
as
much
as
possible,
that
their
efforts
will
be
used

for
good,
software
engineers
must
commit
themselves
to
making
software
engineering
a
beneficial
and

respected
profession.
In
accordance
with
that
commitment,
software
engineers
shall
adhere
to
the

following
Code
of
Ethics
and
Professional
Practice.

The
Code
contains
eight
Principles
related
to
the
behavior
of
and
decisions
made
by

professional
software
engineers,
including
practitioners,
educators,
managers,
supervisors
and
policy

makers,
as
well
as
trainees
and
students
of
the
profession.
The
Principles
identify
the
ethically

responsible
relationships
in
which
individuals,
groups,
and
organizations
participate
and
the
primary

obligations
within
these
relationships.
The
Clauses
of
each
Principle
are
illustrations
of
some
of
the

obligations
included
inthese
relationships.
These
obligations
are
founded
in
the
software
engineer’s

humanity,
in
special
care
owed
to
people
affected
by
the
work
of
software
engineers,
and
the
unique

elements
of
the
practice
of
software
engineering.
The
Code
prescribes
these
as
obligations
of
anyone

claiming
to
be
or
aspiring
to
be
a
software
engineer.

It
is
not
intended
that
the
individual
parts
of
the
Code
be
used
in
isolation
to
justify
errors
of
omission
or

commission.
The
list
of
Principles
and
Clauses
is
not
exhaustive.
The
Clauses
should
not
be
read
as

separating
the
acceptable
from
the
unacceptable
in
professional
conduct
in
all
practical
situations.
The

Code
is
not
a
simple
ethical
algorithm
that
generates
ethical
decisions.
In
some
situations
standards
may

be
in
tension
with
each
other
or
with
standards
from
other
sources.
These
situations
require
the

software
engineer
to
use
ethical
judgment
to
act
in
a
manner,
which
is
most
consistent
with
the
spirit
of

the
Code
of
Ethics
and
Professional
Practice,
given
the
circumstances.

Ethical
tensions
can
best
be
addressed
by
thoughtful
consideration
of
fundamental
principles,
rather

than
blind
reliance
on
detailed
regulations.
These
Principles
should
influence
software
engineers
to

consider
broadly
who
is
affected
by
their
work;
to
examine
if
they
and
their
colleagues
are
treating
other

human
beings
with
due
respect;
to
consider
how
the
public,
if
reasonably
well
informed,
would
view

their
decisions;
to
analyze
how
the
least
empowered
will
be
affected
by
their
decisions;
and
to
consider

whether
their
acts
would
be
judged
worthy
of
the
ideal
professional
working
as

sarojpandey.com.np

11
of
146

a
software
engineer.
In
all
these
judgments
concern
for
the
health,
safety
and
welfare
of
the
public
is

primary;
that
is,
the
"Public
Interest"
is
central
to
this
Code.

The
dynamic
and
demanding
context
of
software
engineering
requires
a
code
that
is
adaptable
and

relevant
to
new
situations
as
they
occur.
However,
even
in
this
generality,
the
Code
provides
support

for
software
engineers
and
managers
of
software
engineers
who
need
to
take
positive
action
in
a
specific

case
by
documenting
the
ethical
stance
of
the
profession.
The
Code
provides
an
ethical
foundation
to

which
individuals
within
teams
and
the
team
as
a
whole
can
appeal.
The
Code
helps
to
define
those

actions
that
are
ethically
improper
to
request
of
a
software
engineer
or
teams
of
software
engineers.

The
Code
is
not
simply
for
adjudicating
the
nature
of
questionable
acts;
it
also
has
an
important

educational
function.
As
this
Code
expresses
the
consensus
of
the
profession
on
ethical
issues,
it
is
a

means
to
educate
both
the
public
and
aspiring
professionals
about
the
ethical
obligations
of

all
software
engineers.

PRINCIPLES

Principle
1:
PUBLIC

Software
engineers
shall
act
consistently
with
the
public
interest.
In
particular,
software
engineers
shall,

as
appropriate:

1.01.
Accept
full
responsibility
for
their
own
work.

1.02.
Moderate
the
interests
of
the
software
engineer,
the
employer,
the
client
and
the
users
with
the

public
good.

1.03.
Approve
software
only
if
they
have
a
well-‐founded
belief
that
it
is
safe,
meets
specifications,
passes

appropriate
tests,
and
does
not
diminish
quality
of
life,
diminish
privacy
or
harm
the
environment.
The

ultimate
effect
of
the
work
should
be
to
the
public
good.

1.04.
Disclose
to
appropriate
persons
or
authorities
any
actual
or
potential
danger
to
the
user,
the
public,

or
the
environment,
that
they
reasonably
believe
to
be
associated
with
software
or
related
documents.

1.05.
Cooperate
in
efforts
to
address
matters
of
grave
public
concern
caused
by
software,
its
installation,

maintenance,
support
or
documentation.

1.06.
Be
fair
and
avoid
deception
in
all
statements,
particularly
public
ones,
concerning
software
or

related
documents,
methods
and
tools.

sarojpandey.com.np

12
of
146

1.07.
Consider
issues
of
physical
disabilities,
allocation
of
resources,
economic
disadvantage
and
other

factors
that
can
diminish
access
to
the
benefits
of
software.

1.08.
Be
encouraged
to
volunteer
professional
skills
to
good
causes
and
contribute
to
public
education

concerning
the
discipline.

Principle
2:
CLIENT
AND
EMPLOYER

Software
engineers
shall
act
in
a
manner
that
is
in
the
best
interests
of
their
client
and
employer,

consistent
with
the
public
interest.
In
particular,
software
engineers
shall,
as
appropriate:

2.01.
Provide
service
in
their
areas
of
competence,
being
honest
and
forthright
about
any
limitations
of

their
experience
and
education.

2.02.
Not
knowingly
use
software
that
is
obtained
or
retained
either
illegally
or
unethically.

2.03.
Use
the
property
of
a
client
or
employer
only
in
ways
properly
authorized,
and
with
the
client's
or

employer's
knowledge
and
consent.

2.04.
Ensure
that
any
document
upon
which
they
rely
has
been
approved,
when
required,
by
someone

authorized
to
approve
it.

2.05.
Keep
private
any
confidential
information
gained
in
their
professional
work,
where
such

confidentiality
is
consistent
with
the
public
interest
and
consistent
with
the
law.

2.06.
Identify,
document,
collect
evidence
and
report
to
the
client
or
the
employer
promptly
if,
in
their

opinion,
a
project
is
likely
to
fail,
to
prove
too
expensive,
to
violate
intellectual
property
law,
or

otherwise
to
be
problematic.

2.07.
Identify,
document,
and
report
significant
issues
of
social
concern,
of
which
they
are

aware,
in
software
or
related
documents,
to
the
employer
or
the
client.

2.08.
Accept
no
outside
work
detrimental
to
the
work
they
perform
for
their
primary
employer.

2.09.
Promote
no
interest
adverse
to
their
employer
or
client,
unless
a
higher
ethical
concern
is
being

compromised;
in
that
case,
inform
the
employer
or
another
appropriate
authority
of
the
ethical
concern.

Principle
3:
PRODUCT

Software
engineers
shall
ensure
that
their
products
and
related
modifications
meet
the
highest

professional
standards
possible.
In
particular,
software
engineers
shall,
as
appropriate:

sarojpandey.com.np

13
of
146

3.01.
Strive
for
high
quality,
acceptable
cost
and
a
reasonable
schedule,
ensuring
significant
tradeoffs
are

clear
to
and
accepted
by
the
employer
and
the
client,
and
are
available
for
consideration
by
the
user
and

the
public.

3.02.
Ensure
proper
and
achievable
goals
and
objectives
for
any
project
on
which
they
work
or
propose.

3.03.
Identify,
define
and
address
ethical,
economic,
cultural,
legal
and
environmental
issues
related
to

work
projects.

3.04.
Ensure
that
they
are
qualified
for
any
project
on
which
they
work
or
propose
to
work
by
an

appropriate
combination
of
education
and
training,
and
experience.

3.05.
Ensure
an
appropriate
method
is
used
for
any
project
on
which
they
work
or
propose
to
work.

3.06.
Work
to
follow
professional
standards,
when
available,
that
are
most
appropriate
for
the
task
at

hand,
departing
from
these
only
when
ethically
or
technically
justified.

3.07.
Strive
to
fully
understand
the
specifications
for
software
on
which
they
work.

3.08.
Ensure
that
specifications
for
software
on
which
they
work
have
been
well
documented,
satisfy
the

users’
requirements
and
have
the
appropriate
approvals.

3.09.
Ensure
realistic
quantitative
estimates
of
cost,
scheduling,
personnel,
quality
and
outcomes
on
any

project
on
which
they
work
or
propose
to
work
and
provide
an
uncertainty
assessment
of
these

estimates.

3.10.
Ensure
adequate
testing,
debugging,
and
review
of
software
and
related
documents
on
which
they

work.

3.11.
Ensure
adequate
documentation,
including
significant
problems
discovered
and
solutions
adopted,

for
any
project
on
which
they
work.

3.12.
Work
to
develop
software
and
related
documents
that
respect
the
privacy
of
those
who
will
be

affected
by
that
software.

3.13.
Be
careful
to
use
only
accurate
data
derived
by
ethical
and
lawful
means,
and
use
it
only
in
ways

properly
authorized.

3.14.
Maintain
the
integrity
of
data,
being
sensitive
to
outdated
or
flawed
occurrences.

3.15
Treat
all
forms
of
software
maintenance
with
the
same
professionalism
as
new
development.

Principle
4:
JUDGMENT

sarojpandey.com.np

14
of
146

Software
engineers
shall
maintain
integrity
and
independence
in
their
professional

judgment.
In
particular,
software
engineers
shall,
as
appropriate:

4.01.
Temper
all
technical
judgments
by
the
need
to
support
and
maintain
human
values.

4.02
Only
endorse
documents
either
prepared
under
their
supervision
or
within
their
areas
of

competence
and
with
which
they
are
in
agreement.

4.03.
Maintain
professional
objectivity
with
respect
to
any
software
or
related
documents
they
are
asked

to
evaluate.

4.04.
Not
engage
in
deceptive
financial
practices
such
as
bribery,
double
billing,
or
other
improper

financial
practices.

4.05.
Disclose
to
all
concerned
parties
those
conflicts
of
interest
that
cannot
reasonably
be
avoided
or

escaped.

4.06.
Refuse
to
participate,
as
members
or
advisors,
in
a
private,
governmental
or
professional
body

concerned
with
software
related
issues,
in
which
they,
their
employers
or
their
clients
have
undisclosed

potential
conflicts
of
interest.

Principle
5:
MANAGEMENT

Software
engineering
managers
and
leaders
shall
subscribe
to
and
promote
an
ethical
approach
to
the

management
of
software
development
and
maintenance
.
Inparticular,
those
managing
or

leading
software
engineers
shall,
as
appropriate:

5.01
Ensure
good
management
for
any
project
on
which
they
work,
including
effective
procedures
for

promotion
of
quality
and
reduction
of
risk.

5.02.
Ensure
that
software
engineers
are
informed
of
standards
before
being
held
to
them.

5.03.
Ensure
that
software
engineers
know
the
employer's
policies
and
procedures
for
protecting

passwords,
files
and
information
that
is
confidential
to
the
employer
or
confidential
to
others.

5.04.
Assign
work
only
after
taking
into
account
appropriate
contributions
of
education
and
experience

tempered
with
a
desire
to
further
that
education
and
experience.

5.05.
Ensure
realistic
quantitative
estimates
of
cost,
scheduling,
personnel,
quality
and
outcomes
on
any

project
on
which
they
work
or
propose
to
work,
and
provide
an
uncertainty
assessment
of
these

estimates.

sarojpandey.com.np

15
of
146

5.06.
Attract
potential
software
engineers
only
by
full
and
accurate
description
of
the
conditions
of

employment.

5.07.
Offer
fair
and
just
remuneration.

5.08.
Not
unjustly
prevent
someone
from
taking
a
position
for
which
that
person
is
suitably
qualified.

5.09.
Ensure
that
there
is
a
fair
agreement
concerning
ownership
of
any
software,
processes,
research,

writing,
or
other
intellectual
property
to
which
a
software
engineer
has
contributed.

5.10.
Provide
for
due
process
in
hearing
charges
of
violation
of
an
employer's
policy
or
of
this
Code.

5.11.
Not
ask
a
software
engineer
to
do
anything
inconsistent
with
this
Code.

5.12.
Not
punish
anyone
for
expressing
ethical
concerns
about
a
project.

Principle
6:
PROFESSION

Software
engineers
shall
advance
the
integrity
and
reputation
of
the
profession
consistent
with
the

public
interest.
In
particular,
software
engineers
shall,
as
appropriate:

6.01.
Help
develop
an
organizational
environment
favorable
to
acting
ethically.

6.02.
Promote
public
knowledge
of
software
engineering.

6.03.
Extend
software
engineering
knowledge
by
appropriate
participation
in
professional
organizations,

meetings
and
publications.

6.04.
Support,
as
members
of
a
profession,
other
software
engineers
striving
to
follow
this
Code.

6.05.
Not
promote
their
own
interest
at
the
expense
of
the
profession,
client
or
employer.

6.06.
Obey
all
laws
governing
their
work,
unless,
in
exceptional
circumstances,
such
compliance

is
inconsistent
with
the
public
interest.

6.07.
Be
accurate
in
stating
the
characteristics
of
software
on
which
they
work,
avoiding
not
only
false

claims
but
also
claims
that
might
reasonably
be
supposed
to
be
speculative,
vacuous,
deceptive,

misleading,
or
doubtful.

6.08.
Take
responsibility
for
detecting,
correcting,
and
reporting
errors
in
software
and
associated

documents
on
which
they
work.

6.09.
Ensure
that
clients,
employers,
and
supervisors
know
of
the
software
engineer's
commitment
to

this
Code
of
ethics,
and
the
subsequent
ramifications
of
such
commitment.

sarojpandey.com.np

16
of
146

6.10.
Avoid
associations
with
businesses
and
organizations
which
are
in
conflict
with
this
code.

6.11.
Recognize
that
violations
of
this
Code
are
inconsistent
with
being
a
professional
software
engineer.

6.12.
Express
concerns
to
the
people
involved
when
significant
violations
of
this
Code
are
detected

unless
this
is
impossible,
counter-‐productive,
or
dangerous.

6.13.
Report
significant
violations
of
this
Code
to
appropriate
authorities
when
it
is
clear
that

consultation
with
people
involved
in
these
significant
violations
is
impossible,
counter-‐productive
or

dangerous.

Principle
7:
COLLEAGUES

Software
engineers
shall
be
fair
to
and
supportive
of
their
colleagues.
In
particular,
software
engineers

shall,
as
appropriate:

7.01.
Encourage
colleagues
to
adhere
to
this
Code.

7.02.
Assist
colleagues
in
professional
development.

7.03.
Credit
fully
the
work
of
others
and
refrain
from
taking
undue
credit.

7.04.
Review
the
work
of
others
in
an
objective,
candid,
and
properly-‐documented
way.

7.05.
Give
a
fair
hearing
to
the
opinions,
concerns,
or
complaints
of
a
colleague.

7.06.
Assist
colleagues
in
being
fully
aware
of
current
standard
work
practices
including
policies
and

procedures
for
protecting
passwords,
files
and
other
confidential
information,
and
security

measures
in
general.

7.07.
Not
unfairly
intervene
in
the
career
of
any
colleague;
however,
concern
for
the
employer,
the
client

or
public
interest
may
compel
software
engineers,
in
good
faith,
to
question
the
competence
of
a

colleague.

7.08.
In
situations
outside
of
their
own
areas
of
competence,
call
upon
the
opinions
of
other

professionals
who
have
competence
in
that
area.

Principle
8:
SELF

Software
engineers
shall
participate
in
lifelong
learning
regarding
the
practice
of
their
profession
and

shall
promote
an
ethical
approach
to
the
practice
of
the
profession.
In
particular,
software
engineers

shall
continually
endeavor
to:

sarojpandey.com.np

17
of
146

8.01.
Further
their
knowledge
of
developments
in
the
analysis,
specification,
design,
development,

maintenance
and
testing
of
software
and
related
documents,
together
with
the
management
of
the

development
process.

8.02.
Improve
their
ability
to
create
safe,
reliable,
and
useful
quality
software
at
reasonable
cost
and

within
a
reasonable
time.

8.03.
Improve
their
ability
to
produce
accurate,
informative,
and
well-‐written
documentation.

8.04.
Improve
their
understanding
of
the
software
and
related
documents
on
which
they
work
and
of
the

environment
in
which
they
will
be
used.

8.05.
Improve
their
knowledge
of
relevant
standards
and
the
law
governing
the
software
and
related

documents
on
which
they
work.

8.06
Improve
their
knowledge
of
this
Code,
its
interpretation,
and
its
application
to
their
work.

8.07
Not
give
unfair
treatment
to
anyone
because
of
any
irrelevant
prejudices.

8.08.
Not
influence
others
to
undertake
any
action
that
involves
a
breach
of
this
Code.

8.09.
Recognize
that
personal
violations
of
this
Code
are
inconsistent
with
being
a

professional
software
engineer.

This
Code
was
developed
by
the
ACM/IEEE-‐CS
joint
task
force
on
Software
Engineering
Ethics
and
Professional
Practices
(SEEPP).

Software
is
a
computer
programs
and
its
associated
document
and
configuration
data,
which
is
needed

to
make
these
programs
operate
correctly.
A
software
system
usually
consists
of
a
number
of
separate

programs,
configuration
files
that
are
used
to
set
up
these
programs,
system
documentation
which

describes
the
structure
of
the
system
and
user
documentation
which
explains
how
to
use
the
system,
and

for
software
products,
web
sites
for
users
to
download
recent
information.

Software
is...

Instructions
(
computer
programs)
that
when
executed
provide
desired
function

and
performance.

Data
structures
that
enables
the
programs
to
adequately
manipulate
information,
and

Documents
that
describe
the
operation
and
use
of
the
programs.

Evolving
role
of
software

Software
takes
on
a
dual
role.
It
is
a
product
and
the
vehicle
for
delivering
a
product.
As
a
product,
it

delivers
the
computing
potential
embodied
by
computer
hardware
or,
a
network
of
computers
that
are

sarojpandey.com.np

18
of
146

accessible
by
local
hardware.
Software
is
an
information
transformer-‐producing,
managing,
acquiring,

modifying,
displaying,
or
transmitting
information.
As

the
vehicle
used
to
deliver
the
product,
software

acts
as
the
basis
for
the
control
of
the
computer
(
operating
systems),
the
communication
of
information(

networks),
and
the
creation
and
control
of
other
programs
(
software
tools
and
environments).

Software
delivers
the
most
important
product
of
our
time-‐
information.
Software
transforms
personal

data
(
e.g.,
an
individual's
financial
transactions)
so
that
the
data
can
be
more
useful
in
a
local
context;
it

manages
business
information
to
enhance
competitiveness;
it
provides
a
gateway
to
worldwide

information
networks
(
Internet)
and
provides
the
means
for
acquiring
information
in
all
of
its
form.

Software
Characteristics

Software
is
a
logical
rather
than
a
physical
system
element.
Therefore,
software
has
characteristics
that

are
considerably
different
than
those
of
hardware.
When
hardware
is
built,
the
human
creative
process
(

analysis,
design,
construction,
testing)
is
ultimately
translated
into
a
physical
form.

§ Software
is
developed
or
engineered,
it
is
not
manufactured
in
the
classical
sense.

§ Software
does
not
"wear
out"
but
it
does
deteriorate.

§ Currently,
most
software
is
still
custom-‐built.

Attributes
of
a
good
Software

The
software
should
deliver
the
required
functionality
and
performance
to
the
user
and
should
be

maintainable,
dependable
and
usable.

n Maintainability

Software
must
evolve
to
meet
changing
needs
of
the
customers.
This
is
a
critical
attribute

because
software
change
is
an
inevitable
consequence
of
a
changing
business
environment.

n Dependability

Software
must
be
trustworthy.
Dependability
has
a
range
of
characteristics,
including

reliability,
security
and
safety.
Dependable
software
should
not
cause
physical
or
economical

damage
in
the
event
of
system
failure.

n Efficiency

Software
should
not
make
wasteful
use
of
system
resources
such
as
memory
and
processor

cycles.
Efficiency
therefore
includes
responsiveness,
processing
time,
and
memory

utilization,
etc.

sarojpandey.com.np

19
of
146

n Usability

Software
must
be
usable
by
the
users
for
which
it
was
designed,
this
means
it
should
have
an

appropriate
user
interface
and
adequate
documentation.

Software
Applications

System
software

Real-‐time
software

Business
software

Engineering
and
scientific
software

Embedded
software

Personal
computer
software

Web-‐based
software

Artificial
intelligence
software

System
software

A
collection
of
programs
written
to
service
other
programs.

Some
systems
software
(
e.g.,
compilers,
editor,
and
file
management
utilities)
process
complex,

but
determinate,
information
structures.

Other
system
applications
(
e.g.
operating
system
components,
drivers,
telecommunications

processors)
process
largely
indeterminate
data.

It
is
characterized
by
heavy
interaction
with
computer
hardware,
heavy
usage
by
multiple
users;

concurrent
operation
that
requires
scheduling,
resources
sharing,
and
sophisticated
process

management,
complex
data
structures,
and
multiple
external
interfaces.

Real
time
Software

It
monitors/analyzes/
controls
real-‐world
events
as
they
occur.

Elements
of
real
time
software
include

o Data
gathering
component
that
collects
and
formats
information
from
an
external

environment,

o Analysis
component
that
transforms
information
as
required
by
the
applications,

o Control/Output
components
that
responds
to
the
external
environment,

o Monitoring
component
that
coordinates
all
other
components
so
that
real
time

response
can
be
maintained.

sarojpandey.com.np

20
of
146

Business
Software

Business
information
processing
is
the
largest
single
software
application
area.

Discrete
"system"
(
e.g.,
payroll,
accounts
receivable/payable,
inventory)
has
evolved
into
MIS

software
that
access
database
containing
business
information.

Encompass
interactive
computing
(e.g.,
point
of
sale
transaction
processing)

Engineering
and
Scientific
Software

Characterized
by
"number
crunching"
algorithms.

Applications
range
from
astronomy
to
volcanology,
from
automotive
stress
analysis
to
space

shuttle
orbital
dynamics,
and
from
molecular
biology
to
automated
manufacturing.

Ex-‐
CAD,
System
simulation
and
other
interactive
applications.

Embedded
Software

Resides
in
ROM
(
Read
only
memory)
and
is
used
to
control
products
and
systems
for
the

consumer
and
industrial
markets.

Perform
very
limited
and
esoteric
functions
(
e.g.,
keypad
control
for
the
microwave
oven)

Provide
significant
function
and
control
capability
(
e.g.,
digital
functions
in
an
automobile
such

as
fuel
control,
dashboard
displays,
and
braking
systems.)

Personal
computer
software

Word
processing,
spreadsheets,
computer
graphics,
multimedia,
entertainment,
database
management,

personal
and
business
financial
applications,
external
network,
and
database
access.

Web-‐based
Software

Software
that
incorporates
executable
instructions
(e.g.,
CGI,
HTML,
Perl,
or
Java)
and
data
(e.g.,

hypertext
and
a
variety
of
visual
and
audio
formats).

Artificial
Intelligence
Software

It
makes
use
of
non-‐numerical
algorithms
to
solve
complex
problems
that
are
not
amenable
to

computation
or
straightforward
analysis.

Ex-‐
Expert
systems,
also
called
knowledge
based
systems,
pattern
recognition
(
image
and
voice),

artificial
neural
networks,
theorem
proving,
and
game
playing.

sarojpandey.com.np

21
of
146

Programs
vs.
Software
products

Program
Software
Product

Programs
are
developed
by
individuals
for
their

personal
use.

Software
products
are
usually
developed
by
a

group
of
software
engineers
and
have
multiple

users.

Small
in
size
and
have
limited
functionality
Medium
or
large
size
program
and
have
complex

functionality.

The
author
of
a
program
himself
uses
and

maintains
his
programs.

Software
products
are
too
large
to
be
developed
by

any
individual
programmer.
A
group
of
software

engineers
are
involved
in
the
development.

Program
usually
do
not
have
good
user-‐interface

and
lack
proper
documentation

A
software
product
not
only
consists
of
the

program
code
but
also
of
all
the
associated

documents
such
as
SRS
document,
design

document,
test
document
and
users’
manuals.

Software
products

Software
Products
may
be
developed
for
a
particular
customer
or
may
be
developed
for
a
general

market.
There
are
two
types
of
software
products:

Generic
products:

These
are
stand-‐alone
systems
which
are
produced
by
a
development

organization
and
sold
on
the
open
market
to
a
range
of
different
customers.
Sometimes
they
are

referred
to
as
shrink-‐wrapped
software.
Examples:
databases,
word
processors,
drawing
packages

and
project
management
tools.

Bespoke
(or
customised)
products
-‐
These
are
systems
developed
for
a
single
customer

according
to
their
specification.
Examples:
control
systems
for
electronic
devices,
systems
written

to
support
a
particular
business
process
and
air
traffic
control
systems.

An
important
difference
between
these
different
types
of
software
is
that,
in
generic
products,
the

organization,
which
develops
the
software,
controls
the
software
specification.
For
custom
products,
the

specification
is
usually
developed
and
controlled
by
the
organization
that
is
buying
the
software.
The

software
developers
must
work
to
that
specification.

sarojpandey.com.np

22
of
146

Software
Myths

Software
standards
provide
software
engineers
with
all
the
guidance
they
need.
The
reality
is
the

standards
may
be
outdated
and
rarely
referred
to.

People
with
modern
computers
have
all
the
software
development
tools.
The
reality
is
that
CASE

tools
are
more
important
than
hardware
to
producing
high
quality
software,
yet
they
are
rarely
used

effectively.

Adding
people
is
a
good
way
to
catch
up
when
a
project
is
behind
schedule.
The
reality
is
that
adding

people
only
helps
the
project
schedule
when
is
it
done
in
a
planned,
well-‐coordinated
manner.

Giving
software
projects
to
outside
parties
to
develop
solves
software
project
management

problems.
The
reality
is
people
who
can’t
manage
internal
software
development
problems
will

struggle
to
manage
or
control
the
external
development
of
software
too.

A
general
statement
of
objectives
from
the
customer
is
all
that
is
needed
to
begin
a
software
project.

The
reality
is
without
constant
communication
between
the
customer
and
the
developers
it
is

impossible
to
build
a
software
product
that
meets
the
customer's
real
needs.

Project
requirements
change
continually
and
change
is
easy
to
accommodate
in
the
software
design.

The
reality
is
that
every
change
has
far-‐reaching
and
unexpected
consequences.
Changes
to
software

requirements
must
be
managed
very
carefully
to
keep
a
software
project
on
time
and
under
budget.

Once
a
program
is
written,
the
software
engineer's
work
is
finished.
The
reality
is
that
maintaining
a

piece
of
software
is
never
done,
until
the
software
product
is
retired
from
service.

There
is
no
way
to
assess
the
quality
of
a
piece
of
software
until
it
is
actually
running
on
some

machine.
The
reality
is
that
one
of
the
most
effective
quality
assurance
practices
(formal
technical

reviews)
can
be
applied
to
any
software
design
product
and
can
serve
as
a
quality
filter
very
early
in

the
product
life
cycle.

The
only
deliverable
from
a
successful
software
project
is
the
working
program.
The
reality
is
the

working
program
is
only
one
of
several
deliverables
that
arise
from
a
well-‐managed
software

project.
The
documentation
is
also
important
since
it
provides
a
basis
for
software
support
after

delivery.

sarojpandey.com.np

23
of
146

Software
engineering
is
all
about
the
creation
of
large
and
unnecessary
documentation.
The
reality
is

that
software
engineering
is
concerned
with
creating
quality.
This
means
doing
things
right
the
first

time
and
not
having
to
create
deliverables
needed
to
complete
or
maintain
a
software
product.
This

practice
usually
leads
to
faster
delivery
times
and
shorter
development
cycles.

Summary

Software
has
become
a
key
element
in
the
evolution
of
computer
based
systems
and
products.
Over
the

past
50
years,
software
has
evolved
from
a
specialized
problem
solving
and
information
analysis
tool
to

an
industry
in
itself.
Since
software
is
composed
of
programs,
data
and
documents;
each
of
these
items

comprises
a
configuration
that
is
created
as
part
of
the
software
engineering
process.
The
intent
of

software
engineering
is
to
provide
a
framework
for
building
software
with
higher
quality.

Software
engineering
is
the
systematic
collection
of
decades
of
programming
experience
together
with

the
innovations
made
by
researchers
towards
developing
high-‐quality
software
in
a
cost
effective
maner.

Assignment
Questions

Q1.
Software
is
both
a
product
and
a
vehicle
for
delivering
a
product.
Explain

Q2.
Software
is
engineered,
not
manufactured.
Explain

Q3.
“Software
does
not
wear,
but
it
does
deteriorate”.
Describe
this
statement
with
reference
to
software

characteristics.

Q4.
Define
Software
and
explain
its
characteristics
and
also
mention
the
various
types
of
software

product.

Q5.
Explain
some
of
the
Software
applications
you
have
noticed.

Q6.
Compare
and
contrast
programs
with
Software
products.

Q7.
What
are
the
various
software
myth
and
explain
what
should
be
the
reality.

Q8.
What
are
the
key
challenges
facing
software
engineering?

sarojpandey.com.np

24
of
146

2. Design
Concepts
and
Principles

Overview

A
software
design
is
a
meaningful
engineering
representation
of
some
software
product
that
is
to
be

built.
A
design
can
be
traced
to
the
customer's
requirements
and
can
be
assessed
for
quality
against

predefined
criteria.
During
the
design
process
the
software
requirements
model
is
transformed
into

design
models
that
describe
the
details
of
the
data
structures,
system
architecture,
interface,
and

components.
Each
design
product
is
reviewed
for
quality
before
moving
to
the
next
phase
of
software

development.

Software
design
sits
at
the
technical
kernel
of
software
engineering
and
is
applied
regardless
of
the

software
process
model
being
used.
Beginning
once
software
requirements
have
been
analyzed
and

specified,
software
design
is
the
first
of
three
technical
activities-‐design,
code
generation,
and
test
-‐
that

are
required
to
build
and
verify
the
software.
Each
activity
transforms
information
in
a
manner
that

ultimately
results
in
validated
computer
software.

Design
Specification
Models

Data
design
-‐
created
by
transforming
the
analysis
information
model
(data
dictionary
and
ERD)

into
data
structures
required
to
implement
the
software

Architectural
design
-‐
defines
the
relationships
among
the
major
structural
elements
of
the

software,
it
is
derived
from
the
system
specification,
the
analysis
model,
and
the
subsystem

interactions
defined
in
the
analysis
model
(DFD)

Interface
design
-‐
describes
how
the
software
elements
communicate
with
each
other,
with
other

systems,
and
with
human
users;
the
data
flow
and
control
flow
diagrams
provide
much
the

necessary
information

Component-‐level
design
-‐
created
by
transforming
the
structural
elements
defined
by
the

software
architecture
into
procedural
descriptions
of
software
components
using
information

obtained
from
the
PSPEC,
CSPEC,
and
STD

Design
Guidelines

A
design
should

exhibit
good
architectural
structure

be
modular

contain
distinct
representations
of
data,
architecture,
interfaces,
and
components
(modules)

sarojpandey.com.np

25
of
146

lead
to
data
structures
that
are
appropriate
for
the
objects
to
be
implemented
and
be
drawn
from

recognizable
design
patterns

lead
to
components
that
exhibit
independent
functional
characteristics

lead
to
interfaces
that
reduce
the
complexity
of
connections
between
modules
and
with
the

external
environment

be
derived
using
a
reputable
method
that
is
driven
by
information
obtained
during
software

requirements
analysis

Design
Principles

Software
design
is
both
a
process
and
a
model.
The
design
process
is
a
sequence
of
steps
that
enable
the

designer
to
describe
all
aspects
of
the
software
to
be
built.
The
design
model
is
the
equivalent
of
an

architect's
plan
for
a
house.
It
begins
by
representing
the
totality
of
the
thing
to
be
built
and
slowly

refines
the
thing
to
provide
guidance
for
constructing
each
detail.

Basic
design
principles,
as
suggested
by
Davis,
enable
to
navigate
the
design
process.

The
design

process
should
not
suffer
from
"tunnel
vision"

should
be
traceable
to
the
analysis
model

should
not
reinvent
the
wheel

should
"minimize
intellectual
distance"
between
the
software
and
the
problem
as
it
exists
in
the

real
world

should
exhibit
uniformity
and
integration

should
be
structured
to
accommodate
change

should
be
structured
to
degrade
gently,
even
with
bad
data,
events,
or
operating
conditions
are

encountered

should
be
assessed
for
quality
as
it
is
being
created

should
be
reviewed
to
minimize
conceptual
(semantic)
errors

Fundamental
Software
Design
Concepts

Abstraction
-‐
allows
designers
to
focus
on
solving
a
problem
without
being
concerned
about

irrelevant
lower
level
details
(procedural
abstraction
-‐
named
sequence
of
events,
data

abstraction
-‐
named
collection
of
data
objects)

Refinement
-‐
process
of
elaboration
where
the
designer
provides
successively
more
detail
for

each
design
component

sarojpandey.com.np

26
of
146

Modularity
-‐
the
degree
to
which
software
can
be
understood
by
examining
its
components

independently
of
one
another

Software
architecture
-‐
overall
structure
of
the
software
components
and
the
ways
in
which
that

structure
provides
conceptual
integrity
for
a
system

Control
hierarchy
or
program
structure
-‐
represents
the
module
organization
and
implies
a

control
hierarchy,
but
does
not
represent
the
procedural
aspects
of
the
software
(e.g.
event

sequences)

Structural
partitioning
-‐
horizontal
partitioning
defines
three
partitions
(input,
data

transformations,
and
output);
vertical
partitioning
(factoring)
distributes
control
in
a
top-‐down

manner
(control
decisions
in
top
level
modules
and
processing
work
in
the
lower
level
modules)

Data
structure
-‐
representation
of
the
logical
relationship
among
individual
data
elements

(requires
at
least
as
much
attention
as
algorithm
design)

Software
procedure
-‐
precise
specification
of
processing
(event
sequences,
decision
points,

repetitive
operations,
data
organization/structure)

Information
hiding
-‐
information
(data
and
procedure)
contained
within
a
module
is
inaccessible

to
modules
that
have
no
need
for
such
information

Modular
Design
Method
Evaluation
Criteria

Modular
decomposability
-‐
provides
systematic
means
for
breaking
problem
into
sub-‐problems

Modular
composability
-‐
supports
reuse
of
existing
modules
in
new
systems

Modular
understandability
-‐
module
can
be
understood
as
a
stand-‐alone
unit

Modular
continuity
-‐
side-‐effects
due
to
module
changes
minimized

Modular
protection
-‐
side-‐effects
due
to
processing
errors
minimized

Control
Terminology

Span
of
control
(number
of
levels
of
control
within
a
software
product)

Depth
(distance
between
the
top
and
bottom
modules
in
program
control
structure)

Fan-‐out
or
width
(number
of
modules
directly
controlled
by
a
particular
module)

Fan-‐in
(number
of
modules
that
control
a
particular
module)

Visibility
(set
of
program
components
that
may
be
called
or
used
as
data
by
a
given
component)

Connectivity
(set
of
components
that
are
called
directly
or
are
used
as
data
by
a
given

component)

Effective
Modular
Design

Functional
independence
-‐
modules
have
high
cohesion
and
low
coupling

Cohesion
-‐
qualitative
indication
of
the
degree
to
which
a
module
focuses
on
just
one
thing

sarojpandey.com.np

27
of
146

Coupling
-‐
qualitative
indication
of
the
degree
to
which
a
module
is
connected
to
other
modules

and
to
the
outside
world

Design
Heuristics
for
Effective
Modularity

Evaluate
the
first
iteration
of
the
program
structure
to
reduce
coupling
and
improve
cohesion.

Attempt
to
minimize
structures
with
high
fan-‐out;
strive
for
fan-‐in
as
structure
depth
increases.

Keep
the
scope
of
effect
of
a
module
within
the
scope
of
control
for
that
module.

Evaluate
module
interfaces
to
reduce
complexity,
reduce
redundancy,
and
improve
consistency.

Define
modules
whose
function
is
predictable
and
not
overly
restrictive
(e.g.
a
module
that
only

implements
a
single
sub-‐function).

Strive
for
controlled
entry
modules,
avoid
pathological
connection
(e.g.
branches
into
the
middle

of
another
module)

Assignments

1) Do
you
design
software
when
you
"write"
a
program?
What
makes
software
design
different
from

coding?

2) Discuss
the
relationship
between
the
concept
of
information
hiding
as
an
attribute
of
effective

modularity
and
the
concept
of
module
independence.

3) Discuss
how
structural
partitioning
can
help
to
make
software
more
maintainable.

4) What
is
the
purpose
of
developing
a
program
structure
that
is
factored?

5) Explain
the
different
design
principles.

6) Explain
Top-‐down
Vs.
Bottom-‐up
design
technique

7) Write
short
notes
on
Fan-‐in
and
Fan-‐out

sarojpandey.com.np

28
of
146

3. Using
APIs

Application
programming
interface
(API)

An
application-‐programming
interface
(API)
is
a
particular
set
of
rules
and
specifications
that
software

programs
can
follow
to
communicate
with
each
other.
It
serves
as
an
interface
between
different
software

programs
and
facilitates
their
interaction;
similar
to
the
way
the
user
interface
facilitates
interaction
between

humans
and
computers.

An
API
can
be
created
for
applications,
libraries,
operating
systems,
etc.,
as
a
way
of
defining
their

"vocabularies"
and
resources
request
conventions
(e.g.
function-‐calling
conventions).
It
may
include

specifications
for
routines,
data
structures,
object
classes,
and
protocols
used
to
communicate
between
the

consumer
program
and
the
implementer
program
of
the
API.

An
API
is
an
abstraction
that
describes
an
interface
for
the
interaction
with
a
set
of
functions
used
by

components
of
a
software
system.
The
software
providing
the
functions
described
by
an
API
is
said
to
be

an
implementation
of
the
API.

An
API
can
be:

§ General,
the
full
set
of
an
API
that
is
bundled
in
the
libraries
of
a
programming
language,
e.g.
Standard

Template
Library
in
C++
or
Java
API.

§ Specific,
meant
to
address
a
specific
problem,
e.g.
Google
Maps
API
or
Java
API
for
XML
Web
Services.

§ Language-‐dependent,
meaning
it
is
only
available
by
using
the
syntax
and
elements
of
a
particular

language,
which
makes
the
API
more
convenient
to
use.

§ Language-‐independent,
written
so
that
it
can
be
called
from
several
programming
languages.
This
is
a

desirable
feature
for
a
service-‐oriented
API
that
is
not
bound
to
a
specific
process
or
system
and
may
be

provided
as
remote
procedure
calls
or
web
services.
For
example,
a
website
that
allows
users
to
review

local
restaurants
is
able
to
layer
their
reviews
over
maps
taken
from
Google
Maps,
because
Google
Maps

has
an
API
that
facilitates
this
functionality.
Google
Maps'
API
controls
what
information
a
third-‐party
site

can
use
and
how
they
can
use
it.
API
may
be
used
to
refer
to
a
complete
interface,
a
single
function,
or
even
a
set
of
APIs
provided
by
an

organization.
Thus,
the
scope
of
meaning
is
usually
determined
by
the
context
of
usage.

sarojpandey.com.np

29
of
146

You
often
have
to
rely
on
others
to
perform
functions
that
you
may
not
be
able
or
permitted
to
do
by

yourself,
such
as
opening
a
bank
safety
deposit
box.
Similarly,
virtually
all
software
has
to
request
other

software
to
do
some
things
for
it.

To
accomplish
this,
the
asking
program
uses
a
set
of
standardized
requests,
called
application
programming

interfaces
(API),
that
have
been
defined
for
the
program
being
called
upon.
Almost
every
application
depends

on
the
APIs
of
the
underlying
operating
system
to
perform
such
basic
functions
as
accessing
the
file
system.
In

essence,
a
program's
API
defines
the
proper
way
for
a
developer
to
request
services
from
that
program.

Developers
can
make
requests
by
including
calls
in
the
code
of
their
applications.
The
syntax
is
described
in

the
documentation
of
the
application
being
called.
By
providing
a
means
for
requesting
program
services,
an

API
is
said
to
grant
access
to
or
open
an
application.

Building
an
application
with
no
APIs,
is
basically
like
building
a
house
with
no
doors.
The
API
for
all
computing

purposes
is
how
you
open
the
blinds
and
the
doors
and
exchange
information.
APIs
also
exist
between

applications.

Open
source
code
exposes
every
instruction
and
operation
in
an
application
and
therefore
offers
the
most

flexibility.
But
understanding
source
code
can
be
time-‐consuming,
and
it
also
exposes
the
author's
intellectual

property.

Class
browser

A
class
browser
is
a
feature
of
an
integrated
development
environment
(IDE)
that
allows
the
programmer
to

browse,
navigate,
or
visualize
the
structure
of
object-‐oriented
programming
code.

All
major
development
environments
supply
some
manner
of
class
browser,
including

• CodeWarrior
for
Microsoft
Windows,
Mac
OS,
and
embedded
systems

• Microsoft
Visual
Studio

• Eclipse

• Embarcadero
JBuilder

• Embarcadero
Delphi

• Apple
Xcode
for
Mac
OS
X

• NetBeans

• KDevelop

sarojpandey.com.np

30
of
146

• Cincom
Smalltalk

• .NET
Reflector

• Visual
Prolog

Programming
by
example
(PbE),
Programming
by
example
(PbE),
also
known
as
programming
by
demonstration
or
more
generally

as
demonstrational
programming,
is
an
End-‐user
development
technique
for
teaching

a
computer
new
behavior
by
demonstrating
actions
on
concrete
examples.
The
system
records
user
actions

and
infers
a
generalized
program
that
can
be
used
upon
new
examples.

PbE
is
intended
to
be
easier
than
traditional
programming,
which
generally
requires
learning
and
using

a
programming
language.
Many
PbE
systems
have
been
developed
as
research
prototypes,
but
few
have

found
widespread
real-‐world
application.
More
recently,
PbE
has
proved
to
be
a
useful
paradigm
for
creating

scientific
work-‐flows.

Programming
by
example
is
a
way
of

programming
a
software
system
in
its
own
user
interface.
The
user
of

the
system
writes
a
program
by
giving
an
example
of
what
the
program
should
do.
The
system
records
the

sequence
of
actions,
and
can
perform
it
again.
Programming
by
example
allows
a
user
to
create
programs

without
doing
conventional
programming.
Programming
by
example
was
incorporated
into
a
simulation
of
an

office
information
system.
As
the
system
evolved,
it
became
clear
that
the
basic
concept
of
programming
by

example
needed
to
be
extended:
certain
aspects
of
program
creation
are
better
done
by
program

modification
than
by
using
the
programming-‐by-‐example
mechanism.
The
final
system
includes
a
static

program
representation
that
is
easy
to
understand,
a
mechanism
for
describing
data,
and
a
method
of
adding

control
structure.
A
user
operates
on
certain
data
while
creating
a
program
by
example,
but
does
not

necessarily
tell
the
system
why
that
data
was
selected.
The
user
can
supply
this
missing
information
by
using

data
descriptions,
which
are
program
operands
that
specify
how
to
choose
the
data
to
be
used
when
the

program
is
run.
The
system
automatically
supplies
reasonable
default
data
descriptions
while
recording
a

program;
if
necessary
the
user
can
modify
the
descriptions
later
to
reflect
his
or
her
true
intentions.

Since
programming
by
example
is
best
at
recording
sequential
user
actions,
rather
than
branching
or

iteration,
control
structure
that
alters
program
flow
is
specified
by
program
editing.
The
operands
in

sarojpandey.com.np

31
of
146

iterations
and
the
predicates
in
conditional
control
structures
are
built
from
data
descriptions.
Real
users

have
learned
to
use
the
system
quickly
and
with
little
difficulty.
The
techniques
used
in
this
system
can
be

applied
to
other
systems
as
well.
This
research
has
demonstrated
that
programming
by
example
is
a
practical

method
for
creating
programs.

Component-‐based
software
engineering
(CBSE)

Component-‐based
software
engineering
(CBSE)
(also
known
as
component-‐based
development
(CBD))
is
a

branch
of
software
engineering
which
emphasizes
the
separation
of
concerns
in
respect
of
the
wide-‐ranging

functionality
available
throughout
a
given
software
system.
This
practice
aims
to
bring
about
an
equally
wide-‐
ranging
degree
of
benefits
in
both
the
short-‐term
and
the
long-‐term
for
the
software
itself
and
for

organizations
that
sponsor
such
software.

sarojpandey.com.np

32
of
146

4. Software
tools
and
Environments

Topics
to
be
covered:

• Programming
Environment

• Requirement
analysis
and
design
modeling
tools

• Testing
tools

• Configuration
Management
Tools

• Tools
Integration
Mechanism

SELF
STUDY

sarojpandey.com.np

33
of
146

5. Software
Process

An
Introduction
-‐
Software
Engineering

Software
engineering
is
an
engineering
discipline,
which
is
concerned
with
all
aspects
of
software

production
from
the
early
stages
of
system
specification
through
to
maintaining
the
software.

Software
engineers
should
adopt
a
systematic
and
organised
approach
to
their
work
and
use

appropriate
tools
and
techniques
depending
on
the
problem
to
be
solved,
the
development
constraints

and
the
resources
available

Software
engineering
encompasses
a
process,
management
techniques,
technical
methods,
and
the
use

of
tools
to
develop
software.
It
provides
the
specification,
development,
management,
and
evolution
of

software
systems,
not
constrained
by
materials
governed
by
physical
laws
or
manufacturing
processes.

According
to
Stephen
R.
Schach,
Richard
D.Irwin,
Inc.
and
Aksen
Associates,
Software
engineering
is
a

discipline
whose
aim
is
the
production
of
quality
software,
delivered
on
time,
within
budget,
and

satisfying
users'
needs.

According
to
Shari
Lawrence
Pfleeger,

Software
Engineering
is
the
designing
and
developing
high-‐quality
software.
Application
of
computer

science
techniques
to
a
variety
of
problems.

According
to
Fritz
Bauer
[
NAU69],

Software
engineering
is
the
establishment
and
use
of
sound
engineering
principles
in
order
to
obtain

economically
software
that
is
reliable
and
works
efficiently
on
real
machines.

The
IEEE
[IEE93]
defines
Software
engineering
as..

(1)
The
application
of
a
systematic,
disciplined,
quantifiable
approach
to
development,
operation,

and
maintenance
of
software;
that
is,
the
application
of
engineering
to
software.

(2)
The
study
of
approach
as
in
(1).

Software engineering mca

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software engineering mca

Similar to Software engineering mca (20)

More from Aman Adhikari

More from Aman Adhikari (20)

Recently uploaded

Recently uploaded (20)

Software engineering mca