Slide1 l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

SEA Side Software Engineering Annotations PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on
  • Presentation posted in: General

SEA Side Software Engineering Annotations. AAnnotation 5: Process Model One hour presentation to inform you of new techniques and practices in software development. Professor Sara Stoecklin Director of Software Engineering- Panama City Florida State University – Computer Science

Download Presentation

SEA Side Software Engineering Annotations

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


Slide1 l.jpg

SEA Side Software Engineering Annotations

  • AAnnotation 5: Process Model

    One hour presentation to inform you of new techniques and practices in software development.

    Professor Sara Stoecklin

    Director of Software Engineering- Panama City

    Florida State University – Computer Science

    [email protected]

    [email protected]

    850-522-2091

    850-522-2023 Ex 182


The process model software development life cycle sdlc methodology l.jpg

The Process Model(Software Development Life Cycle (SDLC))Methodology


Overview l.jpg

Overview

  • Heavyweight

    • Waterfall Model, DOD Waterfall

    • Unified Process

    • RAD, Component Assembly Model

    • Iterative, Evolutionary

    • Spiral

  • Middleweight

    • Korbra

    • UML Components

    • CleanRoom

  • Lightweight

    • XP

    • Agile Software Development

    • CaLM


A common process framework l.jpg

A Common Process Framework

Work Tasks

Work Products

Milestones

Deliverables

QA Checkpoints


Some common process flows l.jpg

Some Common Process Flows

Linear Process Flows

Iterative Process Flows

Incremental Process Flows


Linear models l.jpg

Linear Models


Linear model characteristics l.jpg

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.


Iterative models l.jpg

Prototyping

Iterative Models


Evolutionary prototype model l.jpg

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 models10 l.jpg

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 l.jpg

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


Slide12 l.jpg

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


Slide13 l.jpg

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


Slide14 l.jpg

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 ModelRapid Throwaway Prototype Model

SRS

PDD

SDS

STP

SIP


Rad characteristics l.jpg

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


Slide16 l.jpg

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


Slide17 l.jpg

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 l.jpg

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 model19 l.jpg

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


Slide20 l.jpg

Spiral Model

Risk Analysis

Prototyping

Planning

Simulation

Operational Prototype

Verification for Next Level

Developing

Client Evaluation and Input


An evolutionary spiral model l.jpg

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


V model l.jpg

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 l.jpg

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 l.jpg

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


Heavyweight methodologies l.jpg

Heavyweight Methodologies

  • Predictable sequential series of tasks

  • Structured sequence of events

  • Plan and work the plan

  • Allows management of milestones

  • Are rigid in deviations to the plan

  • Lack flexibility to use different methods for different problems

  • Trouble handling uncertainty


Capability maturity model l.jpg

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 model27 l.jpg

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


Middleweight methodologies l.jpg

Middleweight Methodologies

  • Predictable sequential series of tasks

  • Structured sequence of events

  • Plan and work the plan

  • Allows management of milestones

  • Are NOT rigid in deviations to the plan

  • Contain flexibility to use different methods for different problems

  • Handle uncertainty

  • Domain experts and programmers work closely


Slide29 l.jpg

Specification

Incremental

Development

Planning

Specification

and Design

Usage

Design

Statistical

Testing

Certification

CleanRoom Approach


Slide30 l.jpg

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


Lightweight methodologies l.jpg

LightWeight Methodologies

  • Lightweight methodologies :

    • Customer is the highest priority at all phases

    • Change in requirements welcomed anytime

    • Deliver is done frequently

    • Domain experts and programmers work closely

    • Motivate developers via various methods

    • Hold conversations while prototyping or programming

    • Amount of workable software is the measure of success

    • Good Design occurs every moment

    • Reflection on designs happen often


Lightweight methodologies32 l.jpg

LightWeight Methodologies

  • Differenced between light and heavy

    • Individuals over process

    • Working software over documentation

    • Customer collaboration over contracts

    • Responding to change over planning

    • Stepping up to the plate


Lightweight methodology calm l.jpg

LightWeight Methodology – CaLM

Design

Project

Management

Implementation

Meetings


The xp process l.jpg

The XP Process

Defines user requirements

requirements

bugs

Build User Stories

new velocity

Conduct Release Planning

Build Iteration

Conduct Acceptance Testing

release

metaphor

release plan

Define Architectural Spikes

estimating

next iteration

Controls Scope

Improves

Quality


Twelve xp practices l.jpg

Twelve XP Practices

  • Five Basic XP Principles

    • Small Releases

    • 40-hour work week

    • On-site customer

    • Collective Ownership

    • Coding Standards

  • Seven Process Techniques


Twelve xp practices36 l.jpg

Twelve XP Practices

  • Seven Process Techniques

    • The Planning Game

    • Metaphor

    • Simple Design

    • Pair Programming

    • Refactoring

    • Continuous Integration

    • Testing


Lightweight methodology agile l.jpg

LightWeight Methodology – Agile

  • Visioning. A good visioning practice

  • Project initiation.

  • Short, iterative, feature-driven, timeboxed delivery

  • Constant feedback.

  • Customer involvement.

  • Technical excellence.


The best l.jpg

THE BEST

  • Management must have milestones.

  • Deliverables must be the payment guide.

  • Lightweight methodologies do not scale.

  • Pair programming WORKS for GOOD design.

  • Customer involvement with constant feedback.

  • Training is essential.


  • Login