software engineering slide 1

– !echni"ues#
– $ethodologies#
– %uidelines.
– &ast experience is systematically arranged.
!heoretical )asis and "uantitative techni"ues
provided.
!radeoff )etween alternatives.

Engineering ,iscipline
– /n the )uild and fix -exploratory style#
normally a 0dirty1 program is "uic2ly
developed.
su)se"uently noticed are fixed.
Exploratory Style?
programs only.
Program Size
E f f o r t , t i m e ,
c o s t
Exploratory Style? Cont3
and time with pro)lem si4e
– Exploratory style usually results in
unmaintaina)le code.
style in a team development environment.

– /s within the easy grasp of an individual.
As the num)er of independent varia)les in the
program increases
individual 5e"uires an unduly large effort to master the
pro)lem.
/mplication in &rogram
,evelopment /nstead of a human# if a machine could )e writing
-generating a program#
But# why does the effort+si4e curve )ecome almost
linear when software engineering principles are
deployed?
techni"ues specifically to overcome the human
cognitive limitations.
$ainly two important principles are
deployed
– A)straction
– ,ecomposition
A)straction Simplify a pro)lem )y omitting unnecessary details.
– Focus attention on only one aspect of the pro)lem and ignore
irrelevant details.
understanding of some country.
– 'o one in his right mind would meet all the citi4ens of the
country# visit every house# and examine every tree of the country#
etc.
– 8ou would possi)ly refer to various types of maps for that
country.

independent parts.
– !he small parts are then ta2en up one )y one
and solved separately.
– !he idea is that each small part would )e easy
to grasp and can )e easily solved.
– !he full pro)lem is solved when all the parts
are solved.
decomposition principle
– !ry to )rea2 a )unch of stic2s tied together versus
)rea2ing them individually.
– 8ou understand a )oo2 )etter when the contents
are organi4ed into independent chapters
– Compared to when everything is mixed up.

programs.
difficulty level with si4e.
when si4e of software increases.

pro)lems – (ow to )rea2 large pro*ects into smaller and
managea)le parts?
development# testing# pro*ect management# etc.

programmer (igher &roductivity
Better <uality &rograms
– Fre"uently crash.
– 6ften delivered late.
&') *))+

7arger pro)lems#
engineering#
Programs verss Software Pro%cts
-sally small in size Athor himself is sole ser
Single %eveloper
A% hoc %evelopment
.arge .arge nm0er of sers Team of %evelopers 1ell2%esigne%
interface 1ell %ocmente% 3 ser2manal prepare%
Systematic %evelopment
Software products
outsourced pro*ects.
506ect25riente%
Control flow2 0ase%
assem)ly language.
hundreds of lines of assem)ly code.

were introduced
(igh+7evel 7anguage
&rogramming -Early @s
still exploratory.
–Typical program sizes were limite% to a few thosan%s of lines of sorce co%e
(igh+7evel 7anguage
&rogramming -Early @s
@s
increased further – Exploratory programming style proved
to )e insufficient.
correct programs.
@s
understand and maintain.
!o cope up with this pro)lem#
experienced programmers advised `Pay particular attention to the design of the
program's control structure.1
28
Control Flow+Based ,esign -late @s A program1s control structure indicates
– !he se"uence in which the program1s
instructions are executed.
structure – Flow charting techni"ue was developed.

=sing flow charting techni"ue –6ne can represent and design a
program1s control structure.
–=sually one understands a program By mentally simulating the program1s
execution se"uence.
chart representation –,ifficult to understand and de)ug.

/t was found
of a program messy.
ar)itrarily.
statements was recogni4ed.
$any programmers had extensively used
assem)ly languages.
program )ranching in assem)ly languages.
– &rogrammers considered use of %6 !6
statements unavoida)le.
At that time# ,i*2stra pu)lished his
article – %oto Statement Considered (armful
Comm. of AC$# 9>>.
read his article.
!hey pu)lished several counter

– 6nly three programming constructs are
sufficient to express any programming logic
se"uence -e.g. aG@H)GH
iteration -e.g. while-2I@ 2G*+2H

Everyone accepted – /t is possi)le to solve any
programming pro)lem without using
&rogramming methodology.
–When it uses only the following
types of constructs
=se single+entry# single+exit program
constructs.
(owever# violations to this feature
are permitted –De to practical consi%erations sch as7 Prematre loop exit to spport exception han%ling
Structured &rograms
–Easier to maintain#
development.
errors
do+while statements.
Soon it was discovered
to the design of data structures of a
program
structure.
J@s

Example of data structure+oriented
design techni"ue
–Dac2son1s Structured
&rogramming-DS& methodology

45
DS& techni"ue – Program co%e strctre shol% correspon% to the %ata strctre
,ata Structure 6riented ,esign -Early J@s

46
/n DS& methodology –A program8s %ata strctres are first %esigne% sing notations for
se4ence, selection, an% iteration
–Then %ata strctre %esign is se% 7
To %erive the program strctre


,ata flow+oriented techni"ues
first )e identified#
produce the re"uired outputs should )e
determined.
,ata flow techni"ue identifies
processing stations.
techni"ue – Can )e used to model the wor2ing of any
system.
techni"ue is its simplicity.
9it Engine
6)*ect+oriented techni"ue
– An intuitively appealing design
are first identified.
5elationships among o)*ects – Such as composition# reference# and
inheritance are determined.
Each o)*ect essentially acts as – A data hiding -or data a)straction
entity.
gained wide acceptance
– $ore ro)ust code
design methodologies – are indeed very noticea)le.
/n additions to the software design
techni"ues – Several other techni"ues evolved.

– specification techni"ues#
=se of 7ife Cycle $odels Software is developed through
several well+defined stages – re"uirements analysis and specification#
– design#
– coding#
Emphasis has shifted – from error correction to error
prevention.
$odern practices emphasi4e – detection of errors as close to their
point of introduction as possi)le.

and modern software development practices -C6'!.
/n exploratory style# – errors are detected only during
testing#
development.
/n exploratory style# – coding is synonymous with
program development.
part of program development
A lot of effort and attention is now )eing
paid to – 5e"uirements specification.

,uring all stages of development process – &eriodic reviews are )eing carried out
Software testing has )ecome systematic – Standard testing techni"ues are availa)le.

!here is )etter visi)ility of design and code – isi)ility means production of good "uality# consistent
and standard documents.
– /n the past# very little attention was )eing given to
producing good "uality and consistent documents.
– increased visi)ility ma2es software pro*ect management easier.

Because of good documentation – fault diagnosis and maintenance are
smoother now.
Several metrics are )eing used – help in software pro*ect management#
"uality assurance# etc.
&ro*ects are )eing thoroughly planned – estimation#
– scheduling#
Software 7ife Cycle Software life cycle -or software process
– Series of identifiable stages that a software product undergoes during its life time:
Feasi)ility study
7ife Cycle $odel
A software life cycle model -or process model – a descriptive and diagrammatic model of software
life cycle
– esta)lishes a precedence ordering among the different
activities#

Several different activities may )e
carried out in each life cycle phase. – For example# the design stage might consist
of
structured design activity.
among the software developers.
– (elps in identifying inconsistencies#
development process.
for specific pro*ects.
pro*ects.
customi4ation is needed.
suita)le life cycle model – and then adhere to it.
– &rimary advantage of adhering to a life cycle
model
disciplined manner.
single programmer +++ – he has the freedom to decide his exact
steps.
developed )y a team – there must )e a precise understanding
among team mem)ers as to when to do
what#
failure.
if – one engineer starts writing code#
– another concentrates on writing the test
document first#
structure

7ife Cycle $odel -C6'!.
A life cycle model – defines entry and exit criteria for every
phase.

the customer.

managers – to monitor the progress of the pro*ect.

When a life cycle model is adhered to# – the pro*ect manager can at any time fairly
accurately tell#
at which stage -e.g.# design# code# test# etc. of the
pro*ect is.
the progress of the pro*ect


$any life cycle models have )een proposed. We will confine our attention to a few important
and commonly used models. – Classical waterfall model
– /terative waterfall#

software engineering slide 1

Documents