Bab 2 Rekayasa Perangkat Lunak 3

Software Engineering: A Practitioner’s Approach, 6/e

Chapter 3Prescriptive Process Models

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

These courseware materials are to be used in conjunction with Software Engineering: A

Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Associates, Inc., copyright © 1996, 2001, 2005 1

Materi ini dapat didownload di :DimaraKusumaHakim.BlogSpot.com

Prescriptive Models

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?




Waterfall Model

A.k.a.: Classic Life Cycle Useful for problems that are well understood Real problems are more complex than that; changes = confusion Customer must state all requirements upfront Customer must have patience Lack of feedback to the customer makes blunders disastrous




Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

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

Incremental Model

Applies elements of the waterfall model in incremental fashion First increment is often a core product Subsequent elements offer expanded functionality Subsequent features (some known, some unknown) are created,

while the core product may undergo evaluation If a customer requires deadlines that are impossible to meet,

a sequence of releases may solve the problem Permits for staffing of a team to fluctuate




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

RAD Model Emphasizes short development cycle

If requirements are well understood and project scope is constrained, it may allow rapid creation of S/W systems

For large projects may require vast human resources (for many RAD teams)

Developers and customers must be able to cope with fast action

For systems that are not highly modularized the RAD approach may not work

If systems require mutual tuning of various components, the RAD approach may not work

RAD may not be appropriate with technical risks high (new technology)




Evolutionary Models: Prototyping




Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

Evolutionary Models: Prototyping Useful when the customer has a legitimate need but is clueless about the details

First prototype may be barely useful: too slow, too big, too unfriendly, etc.

DANGERS: The customer may “LOVE” the prototype which is held

together with “chewing gum”. When informed that it is a prototype which has to be re-built, he may want “few fixes” only

The developer may be tempted to deliver the raw prototype as a final product, sacrificing quality for a quick buck




Evolutionary Models: The Spiral




communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

Evolutionary Models: The Spiral Combines iterative prototyping with systematic aspects of the

waterfall model Can be used throughout the S/W life cycle:

from conceptualization to maintenance Anchor point milestones are used for each evolutionary pass Anchor point milestones:

Work products Required conditions to be attained

Realistic to the development of large-scale systems Iteratively reduces risk Allows repeated use of the prototyping approach

PROBLEM: Customers may not like it, fearing lack of control




Evolutionary Models: Concurrent




Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

Evolutionary Models: Concurrent The former image depicted only the modeling activity

Indeed, concurrent engineering is a set of framework activities such as Communication, Modeling, etc.

Each of these activities is in one of its states… A state is some externally observable mode of behaviour

PROBLEMS: Prototyping (and other evolutionary processes) pose

problems to project planning (too much uncertainty) Evolutionary speed may not be optimal: too slow affects

productivity, too fast leads to chaos Sometimes software processes should focus on flexibility and

extensibility, rather than on quality - delivery delays may make us miss the market niche and window of opportunity




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 like security, fault tolerance, adherence to business rules, systemic: DB mirroring, memory management, concurrency

Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)These courseware materials are to be used in

conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided

with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14

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:	20-Dec-2014
Category:	Technology
Upload:	dimara-hakim
View:	5,417 times
Download:	2 times

Bab 2 Rekayasa Perangkat Lunak 3

Technology