chapter 2 the process n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 2 The Process PowerPoint Presentation
Download Presentation
Chapter 2 The Process

Loading in 2 Seconds...

play fullscreen
1 / 40

Chapter 2 The Process - PowerPoint PPT Presentation


  • 392 Views
  • Uploaded on

Chapter 2 The Process. A Layered Technology. Software Engineering. Software Engineering. tools. methods. process model. a “quality” focus. A Common Process Framework. Common process framework Framework activities work tasks work products milestones & deliverables QA checkpoints

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 2 The Process' - bernad


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a layered technology
A Layered Technology

Software Engineering

Software Engineering

tools

methods

process model

a “quality” focus

a common process framework
A Common Process Framework
  • Common process framework
    • Framework activities
      • work tasks
      • work products
      • milestones & deliverables
      • QA checkpoints
    • Umbrella Activities
umbrella activities
Umbrella Activities
  • Software project management
  • Formal technical reviews
  • Software quality assurance
  • Software configuration management
  • Document preparation and production
  • Reusability management
  • Measurement
  • Risk management
the process model adaptability
The Process Model:Adaptability
  • the framework activities will always be applied on every project ... BUT
  • the tasks (and degree of rigor) for each activity will vary based on:
    • the type of project (an “entry point” to the model)
    • characteristics of the project
    • common sense judgment; concurrence of the project team
slide7

Waterfall Model

SSR - System Software Review

PDR - Preliminary Design Review

CDR - Critical Design Review

TRR - Test Rediness Review

FCA - Functional Configuration Audit

PCA - Physical Configuration Audit

ORR - Operational Rediness Review

Software

Requirements

Analysis

Software

Design

SRS

Code and Unit

Testing

SDS

Software

Integration

and Test

STP

Software

Acceptance

Test

SIP

SSR

PDR

CDR

TRR

FCA

PCA

CRR

slide8

Hardware

Hardware

Implementation

System

Design

Operational

Timelines

Software

Requirements

Analysis

Preliminary

Software

Design

Detailed

Software

Design

Code and Unit

Testing

Software

Integration

and Test

Software

Acceptance

Test

SDR

SSR

PDR

CDR

TRR

FCA

PCA

Waterfall - DOD Model NASA Model)

PP

SRS

PDD

SDS

STP

SIP

slide9

Software

Requirements

Analysis

Build

Prototype

Software

Design

Code and Unit

Testing

Software

Integration

and Test

Software

Acceptance

Test

SSR

PR

PDR

CDR

TRR

FCA

PCA

CRR

Rapid Application Development Model Rapid Throwaway Prototype Model

SRS

PDD

SDS

STP

SIP

rad characteristics
RAD Characteristics
  • High speed adaptation of the linear model
  • Based on Component-based construction
  • Has incremental flavor
  • Not well- suited where precision is required,
    • e.g. high risk systems not easily modularized systems
  • Have rigid performance requirements
    • 1. Model the Information Flow
    • 2. Refine the flows into Data elements
    • 3. Model the data transformations
    • 4. Generate the code 4GLs, component reuse, CASE
    • 5. Test and integration
slide11

Software

Requirements

Analysis

Software

Design

Code and Unit

Testing

Software

Integration

and Test

Software

Acceptance

Test

SSR

PDR

CDR

TRR

FCA

PCA

CRR

Reuse and Automated Development Models/Component Assembly Model

SRS

SDS

STP

SIP

Identify Reusable Components

Informal Specification Formal Specifications Code

component based development
Component Based Development
  • Architecture for Software Reuse
  • Based on Object Orientation
  • Classes are stored in a library
  • When requirements are received,the first stop is the library
linear model characteristics
Linear Model Characteristics
  • Documentation driven model
  • systematic and requires rigor.
  • Inflexible partitioning of project into distinct stages
  • difficult to respond to changes in customer requirements
  • Model appropriate when requirements are well-understood.
  • Programmers HATE to create documentation.
  • l Users HATE to read documentation.
  • l If users read, they rarely understand documentation.
  • Programmers don't understand other programmers documentations.
  • Standards for documentation not clear although UML ordained.
slide15

Software

Requirements

Analysis

Build

Prototype

Software

Design

Code and Unit

Testing

Software

Integration

and Test

Software

Acceptance

Test

SSR

PR

PDR

CDR

TRR

FCA

PCA

CRR

Evolutionary (Prototype) Model

ONLY A PART OF THE FULL SYSTEM

SRS

PDD

SDS

STP

SIP

Series of Implementations of each PART

evolutionary prototype model
Evolutionary/Prototype Model
  • Issues
    • Process is not visible--Lack of process visibility
    • Systems are often poorly structured—Change tends to corrupt the structures
    • Special tools and techniques may be required—Special skills (e.g. in languages for rapid prototyping) may be required
  • Applicability
    • For small or medium-size interactive systems
    • For parts of large systems (e.g. the user interface)
    • For short-lifetime systems
iterative models1

b

u

s

i

n

e

s

s

m

o

d

e

l

i

n

g

b

u

s

i

n

e

s

s

d

a

t

a

m

o

d

e

l

i

n

g

m

o

d

e

l

i

n

g

business

p

r

o

c

e

s

s

m

o

d

e

l

i

n

g

d

a

t

a

modeling

m

o

d

e

l

i

n

g

a

p

p

l

i

c

a

t

i

o

n

g

e

n

e

r

a

t

i

o

n

t

e

s

t

i

n

g

&

p

r

o

c

e

s

s

t

u

r

n

o

v

e

r

data

m

o

d

e

l

i

n

g

modeling

a

p

p

l

i

c

a

t

i

o

n

g

e

n

e

r

a

t

i

o

n

process

modeling

t

e

s

t

i

n

g

&

t

u

r

n

o

v

e

r

application

generation

testing

&

turnover

Iterative Models

team #3

team #2

team #1

60 - 90 days

RAD

the incremental model

S

y

s

t

e

m

/

i

n

f

o

r

m

a

t

i

o

n

e

n

g

i

n

e

e

r

i

n

g

a

n

a

l

y

s

i

s

d

e

s

i

g

n

c

o

d

e

t

e

s

t

a

n

a

l

y

s

i

s

d

e

s

i

g

n

c

o

d

e

t

e

s

t

a

n

a

l

y

s

i

s

d

e

s

i

g

n

c

o

d

e

t

e

s

t

a

n

a

l

y

s

i

s

d

e

s

i

g

n

c

o

d

e

t

e

s

t

The Incremental Model

increment 1

delivery of

1st increment

delivery of

increment 2

2nd increment

delivery of

increment 3

3rd increment

increment 4

delivery of

4th increment

calendar time

slide19

Software

Requirements

Analysis

Software

Design

Code and Unit

Testing

Software

Integration

and Test

Software

Acceptance

Test

SSR

PDR

CDR

TRR

FCA

PCA

CRR

Incremental Development Model

ONLY A PART OF THE FULL SYSTEM

SRS

SDS

STP

SIP

Can Determine a PART at any phase.

characteristics of incremental model
Characteristics of Incremental Model
  • Same Requirements, specification, maintenance,and requirement phases as in Waterfall
  • The systems is partitioned into builds where each build is independently designed and scheduled "incrementally“ The 1st build gives some "production"functionality Subsequent builds add functionality
  • User perspective
  • Get some results quickly
  • Reduces new system "culture shock"
characteristics of incremental model1
Characteristics of Incremental Model
  • Costs easily prorated over the development cycle
  • It employs the systems approach
  • Changes are easier to implement (e.g.design of later builds may not start until some phases are complete and all their changes well known).
  • Problems - May degenerate into "Build and Fix“
  • May result in builds that cannot integrate with one another
slide22

Spiral Model

Risk Analysis

Prototyping

Planning

Simulation

Operational Prototype

Verification for Next Level

Developing

Client Evaluation and Input

an evolutionary spiral model

C

u

s

t

o

m

e

r

E

v

a

l

u

a

t

i

o

n

An Evolutionary (Spiral) Model

P

l

a

n

n

i

n

g

R

i

s

k

A

n

a

l

y

s

i

s

Prototyping

C

u

s

t

o

m

e

r

C

o

m

m

u

n

i

c

a

t

i

o

n

E

n

g

i

n

e

e

r

i

n

g

C

o

n

s

t

r

u

c

t

i

o

n

&

R

e

l

e

a

s

e

And input

Simulation/ Operational Prototype/Verification for the Next Level/Development

slide24

Specification

Incremental

Development

Planning

Specification

and Design

Usage

Design

Statistical

Testing

Certification

CleanRoom Approach

v model
V Model

OPERATION

Validate requirements

REQUIREMENTS

& MAINTENANCE

ANALYSIS

ACCEPTANCE

TESTING

SYSTEM

DESIGN

SYSTEM

TESTING

Verify design

PROGRAM

UNIT & INTE-

DESIGN

GRATION TESTING

CODING

[Pfleeger 98]

operational specification model
Operational Specification Model

[Pfleeger 98]

Execute and

Revise

OPERATIONAL

TRANSFORMED

TEST

SPECIFICATION

SPECIFICATION

(problem-oriented)

(implementation-

oriented)

DELIVERED

SYSTEM

SYSTEM

REQUIREMENTS

(sometimes informal

or incomplete)

still other process models
Still Other Process Models
  • 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
formal method characteristics
Formal Method Characteristics
  • Formal Methods Model Specifications produce proofs

Required rigorous notation

Enhances accuracy

Reduces flexibility

  • Some Formal Methods Petri Nets, Zed, Hoare Logic, CSP, Weakest Preconditions
  • Formal Methods Abstraction

Add formality to reduce ambiguity Use graphical representations Describe the possible system states, transitions, and triggers

capability maturity model
Capability Maturity Model
  • Organizations are not born using a mature process model.
  • Most organizations use NO known process model
  • Watts Humphrey wrote a book to lay out a plan for improving the process model within organizations. His book “Managing the Software Process” and other research has greatly improved the software engineering process.
  • The SEI Developed a capability maturity model which proposes a model for maturing an organizations process model.
capability maturity model1
Capability Maturity Model
  • Five Process Maturity Levels
    • Level 0: Chaos
    • Level 1: Initial
    • Level 2: Repeatable
    • Level 3: Defined
    • Level 4: Managed
    • Level 5: Optimizing
level 1 initial
Level 1: Initial
  • The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort.
level 2 repeatable
Level 2: Repeatable
  • Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications
process maturing to level 2
Process Maturing to Level 2
  • Software configuration management
  • Software quality assurance
  • Software subcontract management
  • Software project tracking and oversight
  • Software project planning
  • Requirement management
level 3 defined
Level 3: Defined
  • The software process for both management and engineering activities is documented, standardized, and integrated into an organization-wide software process. All projects use a documented and approved version of the organization’s process for developing and maintaining software.
  • This level includes all characteristics defined for level 2.
process maturing level 3
Process Maturing Level 3
  • Peer Reviews
  • Inter-group coordination
  • Software product engineering
  • Integrated software management
  • Training program
  • Organization process definition
  • Organization process focus
level 4 managed
Level 4: Managed
  • Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled using detailed measures.
  • This level includes all characteristics defined for level 3.
process maturing level 4
Process Maturing Level 4
  • Software quality management
  • Quantitative process management
level 5 optimizing
Level 5: Optimizing
  • Continuous process improvement is enables by quantitative feedback from the process and from testing innovative ideas and technologies
  • This level includes all characteristics defined for level 5.
process maturing level 5
Process Maturing Level 5
  • Process change management
  • Technology change management
  • Defect prevention
cmm issues
CMM Issues
  • focuses on project management rather than product development.
  • ignores the use of technologies such as rapid prototyping.
  • does not incorporate risk analysis as a key process area
  • does not define its domain of applicability