s.e chap models

8/2/2019 S.E chap Models

1/41

Prescriptive Process Models


2/41

Prescriptive Models

Prescriptive process models advocate an orderly approach tosoftware engineering

That leads to a few questions

If prescriptive process models strive for structure and order, are theyinappropriate for a software world that increases on change?

Yet, if we reject traditional process models (and the order theyimply) and replace them with something less structured, do we makeit impossible to achieve coordination and coherence in softwarework?


3/41


4/41


5/41

The Waterfall Model

Communication

Planning

Modeling

ConstructionDeployment

analysis

designcode

test

project init iat ion

requirement gat hering estimating

scheduling

tracking

delivery

supportfeedback


6/41

The Waterfall Model


7/41


8/41

The Waterfall Model

Problems: Sequential flow. Real projects rarely follow the sequential flow

that the model proposes.

Requirements. It is often difficult for the customer to state allrequirements explicitly. It has difficulty accommodating the

natural uncertainty that exists at the beginning of manyprojects.

Patience. The customer must have patience. A working versionof the programs will not be available until late in the project time-span.


9/41


10/41

1

Evolutionary Models: Prototyping

Communication

Quick plan

Constructionof

prototype

Model ing

Quick design

Delivery

& Feedback

Deployment

communication

Quickplan

ModelingQuickdesign

Construction

of prototype

Deploymentdelivery &feedback


11/41

1

Prototyping

Customer is not clear about detailed input, outputrequirements

Developer is unsure of a particular aspect of the design

Allows better understanding of what is to be built when

requirements are fuzzy It can be treated as a standalone process model or

within the context of any one of the process models

Serves as a mechanism for identifying software

requirements.

Evolutionary Models


12/41


1


13/41


1


14/41


1


15/41

1

Incremental Models


16/41

1

The RAD Model

Communication

Planning

Modelingbusiness modeling

data modeling

process modeling

Constructioncomponent reuse

auto mat ic codegenerat ion

test ing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data model ing

process model ing

Constructioncomponen t reuse

autom at ic code

generat ion

tes t i ng

M o d e l i n gbusiness modelingdata modelingprocess modeling

C o n s t r u c t i o ncomponent reuse

automatic code

generationtesting

Team # 2

Team # n

integrat ion

delivery

feedback

Incremental Models


17/41

1


18/41

1


19/41

1

Incremental Models


20/41

2

The RAD Model

Short development cycle High-speed adaptation of the waterfall model

Uses a component-based construction approach

Uses the generic framework activities

Multiple software teams work in parallelon differentfunctions

Drawbacks: May not be appropriate if: System cannot be properly modularized

Technical risks are high

High performance is an issue

Incremental Models


21/41

2


22/41

2


23/41

2

Th I l M d lIncremental Models


24/41

2

The Incremental Model

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r uc t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

design code

t e s t

increment # 1

increment # 2

delivery of

1st increment

delivery of

2nd increment

delivery of

nt h increment

increment # n

project calendar t ime


P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

design code

t e s t


P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

designcode

t e s t


25/41

2

Incremental Models


26/41

2

The Incremental Model

Waterfall model applied in an iterative manner Delivery of an operational product with each increment

Linear sequences in a staggered fashion.

Each linear sequence produces deliverable increments of

the software (e.g. word processing software) Increment 1: file management, editing and document production

Increment 2: More sophisticated editing and production

Increment 3: Spelling and grammar checking

Increment 4: Advanced page layout capability

The first increment is the core product


27/41

2


28/41

2

Evolutionary Models: The Spiral


29/41

2

Evolutionary Models: The Spiral

communication

planning

modeling

constructiondeployment

deliveryfeedback

start

analysisdesign

code

test

estimation

scheduling

risk analysis

Evolutionary Models


30/41

3

The Spiral

Software is developed in a series of evolutionaryreleases

First circuit around the spiral: product specification

The project manager adjusts the number of iterationsrequired to complete the software

Circuit 1: Product specification

Circuit 2: Prototype

Circuit n: More sophisticated versions of the software

Each pass through the planning region result inadjustments to the project plan

Evolutionary Models


31/41

3

The Spiral

It can be adapted to apply throughout the life of software Iterations around the spiral may be used to represent:

Concept development project

Product development

Product enhancement

Is a realistic approach to the development of large-scalesystems.

It is not a panacea: it may be difficult to convincecustomers that the approach is controllable

C M d lEvolutionary Models


32/41

3

Concurrent Model

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling act ivity

represents the state

of a software engineeringactivity o r t ask

Evolutionary Models


33/41

3

Concurrent Model

Also known as concurrent engineering Consist of framework activities, SE actions and tasks,

and associated states.

The activity can be in one of the states at a time

All activities exist concurrently but reside in differentstates. Communication activity: awaiting changes state

Modeling activity: under development

Appropriate for system engineering projects where

different teams are involved

Evolutionary Models


34/41

3

Final Comment

A problem to project planning: uncertain number of cycles required

Most project management and estimation techniques are basedon linear layouts

Undefined maximum speed:

If evolution is too fast, the process will fall into chaos

If evolution is too slow, then productivity could be affected

Evolutionary Models


35/41

3

Final Comment

Excessive focus on high quality: We should prioritize the speed of the development over zero

defects

Extending the development in order to reach high quality couldresult in late delivery of the product.

It is possible to use an evolutionary process toemphasize flexibility, extensibility, and speed ofdevelopment.

The challenge is to establish a proper balance between

product parameters and customer satisfaction.

Still Other Process Models


36/41

3

Still Other Process Models

Component based developmentthe process to apply

when reuse is a development objective

Formal methodsemphasizes the mathematicalspecification of requirements

AOSDprovides a process and methodological

approach for defining, specifying, designing, andconstructing aspects

Unified Processa use-case driven, architecture-centric, iterative and incremental software process

closely aligned with the Unified Modeling Language(UML)

The Unified Process (UP)


37/41

3

inception


soft ware increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration


38/41

3


A framework for OO SE using UML Has its roots in the industrial experience within Ericsson

Successor methodologies led by Rational and Objectory

Status: a widely adopted industrial standard

Uses the Unified Modeling Language (UML) Several OOA and OOD methods were proposed during

the 80s and early 90s

UP combine the best features of each individual method.

Rational Corporation developed automated tools tosupport UML methods


39/41

3

The Unified Process (UP) - Phases

1.

Inception (feasibility study) Document a vision of the product

Who are the expected users of the system

What is the preliminary high-level architecture of the system

What is the development plan and what are the development costs?

2. Elaboration Use cases are specified in detail

Software architecture is developed and specified

3. Construction developing and testing code

4. Transition corresponds to beta testing.

5. Production

deployment, monitored use of software

UP Phases


40/41

4

Inception Elab or at io n Co nst r uct ion Tr an sit ion Pr odu ct io n

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

UP W k P d


41/41

4

UP Work Products

Inception phase

Elaboration phase

Construction phase

Transit ion phase

Vision document

Init ial use-case mod el

Init ial project glossary

Init ial business case

Init ial risk assessment .

Project plan,

phases and ite rat ions.

Business model,

if necessary.

One or more prot ot ypesI n c e pt i on

Use-case mode l

Supplement ary requirements

including non-funct ional

Analysis model

Software archit ecture

Descript ion.

Execut able archit ect ural

prototype.

Preliminary design model

Revised risk list

Project plan including

it erat ion plan

adapt ed workflows

milest ones

t echnical work product s

Preliminary user manual

Design model

Soft ware component s

Integrat ed soft ware

increment

Test p lan and procedure

Test cases

Support documentat ion

user manuals

inst allation manuals

descript ion of current

increment

Delivered soft ware increment

Bet a t est reports

Gene ral user feed back

s.e chap models

Documents