Ch03-Software Engineering Model

Software Engineering:

Chapter 3

1 D.Balaganesh Lincoln university College

Prescriptive Models

2

Prescriptive process models advocate an orderly approach to software engineering

That leads to a few questions … If prescriptive process models strive for structure and

order, are they inappropriate for a software world that thrives on change?

Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

D.Balaganesh Lincoln university College

SDLC Model

D.Balaganesh LINCOLN UNIVERSITY COLLGE 3

A framework that describes the activities performed at each stage of a software development project.

Waterfall ModelRequirements – defines

needed information, function, behavior, performance and interfaces.

Design – data structures, software architecture, interface representations, algorithmic details.

Implementation – source code, database, user documentation, testing.

D.Balaganesh LINCOLN UNIVERSITY COLLGE

4

Waterfall Model

5D.Balaganesh LINCOLN UNIVERSITY COLLGE

Waterfall ModelTest – check if all code

modules work together and if the system as a whole behaves as per the specifications.

Installation – deployment of system, user-training.

Maintenance – bug fixes, added functionality (an on-going process).


6

Waterfall Strengths


Easy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan,

staff, track)

Waterfall Deficiencies


All requirements must be known upfrontDeliverables created for each phase are

considered frozen – inhibits flexibilityDoes not reflect problem-solving nature of

software development – iterations of phases

Integration is one big bang at the endLittle opportunity for customer to preview

the system (until it may be too late)

When to use the Waterfall Model


Requirements are very well knownWhen it is possible to produce a stable

designE.g. a new version of an existing productE.g. porting an existing product to a new

platform.

Spiral SDLC ModelAdds risk analysis,

and 4gl RAD prototyping to the waterfall model

Each cycle involves the same sequence of steps as the waterfall process model


10

Spiral QuadrantDetermine objectives, alternatives and constraints


Objectives: functionality, performance, hardware/software interface, critical success factors, etc.

Alternatives: build, reuse, buy, sub-contract, etc.Constraints: cost, schedule, man-power,

experience etc.

Spiral QuadrantEvaluate alternatives, identify and resolve risks


Study alternatives relative to objectives and constraints

Identify risks (lack of experience, new technology, tight schedules, etc.)

Resolve risks

Spiral QuadrantDevelop next-level product


Typical activites:Create a designReview designDevelop codeInspect codeTest product

Spiral QuadrantPlan next phase


Typical activitiesDevelop project planDevelop a test planDevelop an installation plan

Spiral Model Strengths


Provides early indication of insurmountable risks, without much cost

Users see the system early because of rapid prototyping tools

Critical high-risk functions are developed first

Users can be closely tied to all lifecycle steps

Early and frequent feedback from users

Spiral Model Weaknesses


Time spent for evaluating risks too large for small or low-risk projects

Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive

The model is complex Risk assessment expertise is requiredSpiral may continue indefinitelyDevelopers must be reassigned during non-

development phase activities

When to use Spiral Model


When creation of a prototype is appropriate

When costs and risk evaluation is important

For medium to high-risk projectsUsers are unsure of their needsRequirements are complexNew product line Significant changes are expected

Tailored SDLC Models


No single model fits all projectsIf there is no suitable model for a

particular project, pick a model that comes close and modify it for your needs.If project should consider risk but complete

spiral model is too much – start with spiral and simplify it

If project should be delivered in increments but there are serious reliability issues – combine incremental model with the V-shaped model

Each team must pick or customize a SDLC model to fit its project

The Waterfall Model

D.Balaganesh Lincoln university College19

Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

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 u c t i o n

D e p l o y m e n t

d e l i v e ry f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g


De 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

des ign code

t es t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g


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

des igncode t es t

The RAD Model


Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation test ing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback

Evolutionary Models: Prototyping


Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

Component Assembly Model


Identifycandidate

components

Look upcomponents

in libraryAvailable?

Extractcomponents

Buildcomponents

ConstructSystem

yes

no

Component Assembly Characteristics


Use of object-oriented technologyComponents - classes that encapsulate

both data and algorithmsComponents developed to be reusableParadigm similar to spiral model, but

engineering activity involves componentsSystem produced by assembling the

correct components

Fourth Generation Techniques (4GT)


"Design" Strategy

Testing

Requirements gathering

Implementation using 4GL

4GT Characteristics


Use of software tools that allow software engineer to specify s/w characteristics at higher level

The tools generate codes based on specification

More time in design and testing - increase productivity

Tools may not be easy to use, codes generated may not be efficient

Other Process Models


Component assembly model—the process to apply when reuse is a development objective

Concurrent process model—recognizes that different part of the project will be at different places in the process

Formal methods—the process to apply when a mathematical specification is to be developed

Cleanroom software engineering—emphasizes error detection before testing

Evolutionary Models: Concurrent


Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

Still Other Process Models


Component based development—the process to apply when reuse is a development objective

Formal methods—emphasizes the mathematical specification of requirements

AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects

Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

Conclusion


The paradigm used for development of software depends on a number of factorsPeople - staff & usersSoftware productTools availableEnvironment

Existing models makes development process clearer, but they can be evolved to become new paradigms

The Unified Process (UP)


inceptioninception

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration

UP Phases


Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

UP Work Products


Inception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment

Delivered software increment Beta test reports General user feedback

Date post:	12-Nov-2014
Category:	Technology
Upload:	bala-ganesh
View:	1,450 times
Download:	0 times

Ch03-Software Engineering Model

Technology