02 - The Software engineering

8/19/2019 02 - The Software engineering

1/37

CSE 470 : SoftwareEngineering

The Software Process


2/37

2

What is a Process?

We can think of a series of activities as a process

Any process has the following characteristics

It prescribes all of the major activities It uses resources and produces intermediate and final products It may include sub-processes and has entry and exit criteria he activities are organi!ed in a se"uence #onstraints or control may apply to activities

$budget control% availability of resources &


3/37

3

'oftware Processes

Coherent sets of activities for

'pecifying%

(esigning%Implementing and

esting software systems

When the process involves the building of some product,

we refer to the process as a life cycle

Software development process – software life cycle


4/37

4

he 'oftware Process

A structured set of activities required todevelop a software system 'pecification

(esign )alidation

*volution

Fundamental Assumptions:

+ood processes lead to good software

+ood processes reduce risk


5/37

5

+eneric software process models

he waterfall model 'eparate and distinct phases of specification and development

*volutionary development

'pecification and development are interleaved,ormal systems development A mathematical system model is formally transformed to an

implementation

euse-based development he system is assembled from existing components


6/37

6

The SE !rocess "odels

he '*I #..Is are the best-known processmodels for software engineering

'*I/ 'oftware *ngineering Institute

#..I/ #apability .aturity .odels Integrated

'ee/

http/00www1sei1cmu1edu0cmmi0


7/37

7

#..I/ #apability .aturity .odels Integrated


8/37

8

The #aterfall "odel

Requirements

Definition

System and

Software design

Programming

and Unit Testing

Integration andSystem Testing

!eration and

"aintenan#e


9/37

$

$equirements Analysis and %efinition

T%e system&s ser'i#es( #onstraints and goa)s are esta*)is%ed *y

#onsu)tation wit% system users+ T%ey are t%en defined in a

manner t%at is understanda*)e *y *ot% users and de'e)o!ment

staff+

T%is !%ase #an *e di'ided into,

-easi*i)ity study .often #arried out se!arate)y/

Requirements ana)ysis

Requirements definition

Requirements s!e#ifi#ation


10/37

01

System and Software %esign

System design, Partition t%e requirements to %ardware or

software systems+ sta*)is%es an o'era)) system

architecture

Software design, Re!resent t%e software system

fun#tions in a form t%at #an *e transformed into one or

more ee#uta*)e !rograms

Unified Modeling Language (UML)


11/37

00


12/37

02


13/37

03

!rogramming and &nit Testing

T%e software design is rea)ied as a set of !rograms or

program units+ .ritten s!e#ifi#a))y( a#quired from

e)sew%ere( or modified+/

Indi'idua) #om!onents are tested against s!e#ifi#ations+


14/37

04

ntegration and System Testing

T%e indi'idua) !rogram units are,

integrated and tested as a #om!)ete system

tested against t%e requirements as s!e#ified

de)i'ered to t%e #)ient


15/37

05

'peration and "aintenance

!eration, T%e system is !ut into !ra#ti#a) use+

"aintenan#e, rrors and !ro*)ems are identified and

fied+

'o)ution, T%e system e'o)'es o'er time as

requirements #%ange( to add new fun#tions or ada!t t%e

te#%ni#a) en'ironment+

P%ase out, T%e system is wit%drawn from ser'i#e+


16/37

06

Advantages of the #aterfall Approach

(evelop re"uirements before design

(esign before writing code

Write code before integrating it

est programs after integrating them2ave milestone reviews


17/37

07

The #aterfall Approach

he Waterfall .odel re"uires that we $attempt to&/ specify the re"uirements completely% consistently% correctly%

and unambiguously on the first attempt

design the software completely and correctly on the first

attempt write all of the software interfaces and internal details correctly

on the first attempt

integrate the components in one large step

do system testing and acceptance testing at the end

he linear waterfall model is a one-pass process


18/37

08

Some $ealities of Software %evelopment

31 e"uirements always change because of/ changing customer desires and user needs

initial re"uirements analysis inade"uate

understandings and insights gained through experience

changing technology changing competitive situation

personnel turnover/ engineering% management% marketing% customer

41 he design is never right the first time

design is a creative% problem solving process

51 ,re"uent demonstrations of progress and early warning of problems are desirable


19/37

0$

%iscussion of the #aterfall "odel

Advantages:Identifies systems requirements )ong *efore !rogramming

*egins+ n)y a!!ro!riate w%en t%e requirements are we))understood

Disadvantages:

Taes )ong time to de)i'er sin#e de'e)o!ing requirements+

Diffi#u)t to ada!t to #%anging requirements a#% stage in t%e !ro#ess re'ea)s new understanding of t%e

!re'ious stages( t%at requires t%e ear)ier stages to *e re'ised+


20/37

21

$elative Cost to (i) a Software %efect


21/37

20

(eed*ac+ in the #aterfall "odel

Requirements

Definition

System and

Software design

Programming

and Unit Testing

Integration andSystem Testing

!eration and

"aintenan#e


22/37

22


*xploratory development

- 6bjective is to work with customers and to evolve a finalsystem from an initial outline specification1

- he system evolves by adding new features as they areproposed by customer1


23/37

23


apid prototyping 6bjective is to understand the system re"uirements1 (evelop 7"uick and dirty8 system in short time9 *xpose to user comment : feedback9

efine9

epeat until ade"uate system developed1

Particularly suitable where/

- detailed re"uirements not possible9- powerful development tools $#A'*& available


24/37

24


ut)ine

Des#ri!tion

Concurrent

Activities

Requirements

Design

Im!)ementation

Initia)

ersion

Intermediate

ersions

-ina)

ersion


25/37

25


Requirements

DesignIm!)ementation

.!rototy!e/

'a)uation


26/37

26


Problems ;ack of process visibility

'ystems are often poorly structured

'pecial skills $e1g1 in languages for rapid prototyping&may be re"uired

Applicability ,or small or medium-si!e interactive systems

,or parts of large systems $e1g1 the user interface&


27/37

27

!rocess iteration

• "odern de'e)o!ment !ro#esses tae iteration as a fundamenta)#on#e!t+

•System requirements 9:9;S e'o)'e during t%e #ourse of a !ro


28/37

28

ncremental development

System is not a sing)e de)i'ery= t%e de'e)o!ment and

de)i'ery *roen down into in#rements de)i'ering !art of

t%e required fun#tiona)ity+

User requirements are !rioritied and t%e %ig%est

!riority requirements are in#)uded in ear)y in#rements+

n#e t%e de'e)o!ment of an in#rement is started(t%e requirements are froen t%oug% requirements

for )ater in#rements #an #ontinue to e'o)'e+


29/37

2$

Incremental development

Validate

increment

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validate

system

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem


30/37

31

The ncremental "odel


31/37

30

ncremental development advantages

>ustomer 'a)ue #an *e de)i'ered wit% ea#% in#rement so

system fun#tiona)ity is a'ai)a*)e ear)ier+

ar)y in#rements a#t as a !rototy!e to %e)! e)i#it

requirements for )ater in#rements

:ower ris of o'era)) !ro


32/37

32

ncremental development pro*lems

T%e !ro#ess is not 'isi*)e+o "anagers need regu)ar de)i'era*)es to measure

!rogress+ If systems are de'e)o!ed qui#)y( it is not #ost

effe#ti'e to !rodu#e do#uments t%at ref)e#t e'ery 'ersion

of t%e system+

System stru#ture tends to degrade as new in#rements are

added.o Un)ess time and money is s!ent on refa#toring to

im!ro'e t%e software( regu)ar #%ange tends to #orru!t its

stru#ture+ In#or!orating furt%er software #%anges *e#omes

in#reasing)y diffi#u)t and #ost)y+


33/37

33

'piral .odel

T%e spiral model is a risk-drien !ro#ess mode)

generator for software !ro


34/37

34

Spiral development

Pro#ess is re!resented as a s!ira) rat%er t%an as a sequen#e of

a#ti'ities wit% *a#tra#ing+

a#% )oo! in t%e s!ira) re!resents a !%ase in t%e !ro#ess+

Ao fied !%ases su#% as s!e#ifi#ation or design B )oo!s in t%e

s!ira) are #%osen de!ending on w%at is required+

!isks are e!)i#it)y assessed and reso)'ed t%roug%out t%e !ro#ess+


35/37

35

Spiral model of the software process

Risk analysis

Risk analysis

Risk analysis

Risk analysis Proto-

type 1

Prototype 2Prototype 3

Opera-

tionalprotoype

Concept of Operation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


36/37

36

Spiral model sectors

*


37/37

37

Spiral model usage

S!ira) mode) %as *een 'ery inf)uentia) in %e)!ing

!eo!)e t%in a*out iteration in software !ro#esses and

introdu#ing t%e risdri'en a!!roa#% to de'e)o!ment+

In !ra#ti#e( %owe'er( t%e mode) is rare)y used as

!u*)is%ed for !ra#ti#a) software de'e)o!ment+

Date post:	07-Jul-2018
Category:	Documents
Upload:	nasim-rony
View:	214 times
Download:	0 times

02 - The Software engineering

Documents