1 SEA Side Software Engineering Annotations AAnnotation 5: Process Model One hour presentation to...

1

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 StoecklinDirector of Software Engineering- Panama City

Florida State University – Computer [email protected]

[email protected]

850-522-2023 Ex 182

2

The Process ModelThe Process Model(Software Development Life Cycle (Software Development Life Cycle

(SDLC))(SDLC))MethodologyMethodology

3

OvervieOvervieww

HeavyweightHeavyweight Waterfall Model, DOD WaterfallWaterfall Model, DOD Waterfall Unified ProcessUnified Process RAD, Component Assembly ModelRAD, Component Assembly Model Iterative, EvolutionaryIterative, Evolutionary SpiralSpiral

MiddleweightMiddleweight KorbraKorbra UML ComponentsUML Components CleanRoomCleanRoom

LightweightLightweight XPXP Agile Software DevelopmentAgile Software Development CaLMCaLM

4

A Common Process A Common Process FrameworkFramework

Work Tasks Work Tasks

Work ProductsWork Products

MilestonesMilestones

DeliverablesDeliverables

QA CheckpointsQA Checkpoints

5

Some Common Process Some Common Process FlowsFlows

Linear Process FlowsLinear Process Flows

Iterative Process FlowsIterative Process Flows

Incremental Process FlowsIncremental Process Flows

6

Linear Linear ModelsModels

analysis design code test

System/informationengineering

7

Linear Model Linear Model CharacteristicsCharacteristics

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.

Users HATE to read documentation.

If users read, they rarely understand documentation.

Programmers don't understand other programmers documentations.

Standards for documentation not clear although UML ordained.

8

Iterative Iterative ModelsModels

listento

customerbuild/revisemock-up

customertest-drivesmock-up

Prototyping

9

Evolutionary/Prototype Evolutionary/Prototype ModelModel

IssuesIssuesProcess is not visibleProcess is not visible--Lack of process visibility--Lack of process visibilitySystems are often poorly structuredSystems are often poorly structured—Change —Change

tends to corrupt the structurestends to corrupt the structuresSpecial tools and techniques may be requiredSpecial tools and techniques may be required——

Special skills (e.g. in languages for rapid Special skills (e.g. in languages for rapid prototyping) may be requiredprototyping) may be required

ApplicabilityApplicabilityFor small or medium-size interactive systemsFor small or medium-size interactive systemsFor parts of large systems (e.g. the user For parts of large systems (e.g. the user

interface)interface)For short-lifetime systemsFor short-lifetime systems

10

Iterative Iterative ModelsModels

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

b u s i n e s sm o d e l i n g

d a t am o d e l i n g

p r o c e s sm o d e l i n g

a p p l i c a t i o ng e n e r a t i o n

t e s t in g&

t u r n o v e r

b u s i n e s sm o d e l i n g

d a t am o d e l i n g

p r o c e s sm o d e l i n g

a p p l i c a t i o ng e n e r a t i o n

t e s t i n g&

t u r n o v e r

team #1team #2

team #3

60 - 90 days

RAD

11

The Incremental The Incremental ModelModel


System/informationengineering




increment 2

increment 3

increment 4

increment 1

delivery of1st increment

delivery of2nd increment

delivery of3rd increment

delivery of4th increment

calendar time

12

Waterfall ModelSSR - 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 ReviewSoftwareRequirements

AnalysisSoftwareDesign

Code and UnitTesting

SoftwareIntegrationand Test

SoftwareAcceptance

Test

SSR PDR CDR TRR CRRFCAPCA

SRS

SDS

STP

SIP

13

SoftwareRequirements

Analysis

DetailedSoftwareDesign

Code and UnitTesting

SoftwareIntegration

and Test SoftwareAcceptance

Test

SSR PDR CDR TRR FCAPCA

SystemDesign

PreliminarySoftwareDesign

SDR

HardwareHardware

Implementation

Operational Timelines

Waterfall - DOD Model NASA Model)

SRS

PP

PDD

SDS

STPSIP

14

Rapid Application Development ModelRapid Throwaway Prototype Model


Analysis

SoftwareDesign

Code and UnitTesting Software

Integrationand Test Software

AcceptanceTest


BuildPrototype

PR

SRS

PDD

SDS

STP

SIP

15

RAD RAD CharacteristicsCharacteristics 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 requirements1. Model the Information Flow2. Refine the flows into Data elements3. Model the data transformations4. Generate the code 4GLs, component reuse, CASE5. Test and integration

16

Evolutionary (Prototype) Model

ONLY A PART OF THE FULL SYSTEM

Series of Implementations of each PART


Analysis

SoftwareDesign



AcceptanceTest


BuildPrototype

PR

SRS

PDD

SDS

STP

SIP

17





AcceptanceTest


Incremental Development Model

ONLY A PART OF THE FULL SYSTEM

Can Determine a PART at any phase.

SRS

SDS

STP

SIP

18

Characteristics of Incremental Characteristics of Incremental ModelModel

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"

19

Characteristics of Incremental Characteristics of Incremental ModelModel

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

20

Spiral Model

Risk Analysis

Prototyping

Planning

Client Evaluation and Input

Simulation

Operational Prototype

Verification for Next Level

Developing

21

An Evolutionary (Spiral) An Evolutionary (Spiral) ModelModel

CustomerCommunication

Planning

Construction & ReleaseCustomerEvaluation

Engineering

Risk Analysis

Prototyping

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

And input

22

REQUIREMENTSANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

Verify design

Validate requirements

[Pfleeger 98]

V V ModelModel

23

Operational Specification Operational Specification ModelModel

DELIVEREDSYSTEM

Execute andRevise

SYSTEMREQUIREMENTS

(sometimes informalor incomplete)

TESTOPERATIONALSPECIFICATION

(problem-oriented)

TRANSFORMEDSPECIFICATION

(implementation-oriented)

[Pfleeger 98]

24

Still Other Process Still Other Process ModelsModels

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

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

25

Heavyweight Heavyweight MethodologiesMethodologies

Predictable sequential series of tasksPredictable sequential series of tasks Structured sequence of eventsStructured sequence of events Plan and work the planPlan and work the plan Allows management of milestonesAllows management of milestones Are rigid in deviations to the planAre rigid in deviations to the plan Lack flexibility to use different Lack flexibility to use different

methods for different problemsmethods for different problems Trouble handling uncertaintyTrouble handling uncertainty

26

Capability Maturity Capability Maturity ModelModel

Organizations are not born using a mature Organizations are not born using a mature process model. process model.

Most organizations use NO known process Most organizations use NO known process modelmodel

Watts Humphrey wrote a book to lay out a plan Watts Humphrey wrote a book to lay out a plan for improving the process model within for improving the process model within organizations. His book “Managing the organizations. His book “Managing the Software Process” and other research has Software Process” and other research has greatly improved the software engineering greatly improved the software engineering process. process.

The SEI Developed a capability maturity model The SEI Developed a capability maturity model which proposes a model for maturing an which proposes a model for maturing an organizations process model. organizations process model.

27

Capability Maturity Capability Maturity ModelModel

Five Process Maturity LevelsFive Process Maturity LevelsLevel 0: ChaosLevel 0: ChaosLevel 1: InitialLevel 1: InitialLevel 2: RepeatableLevel 2: RepeatableLevel 3: DefinedLevel 3: DefinedLevel 4: ManagedLevel 4: ManagedLevel 5: OptimizingLevel 5: Optimizing

28

Middleweight Middleweight MethodologiesMethodologies

Predictable sequential series of tasksPredictable sequential series of tasks Structured sequence of eventsStructured sequence of events Plan and work the planPlan and work the plan Allows management of milestonesAllows management of milestones Are Are NOTNOT rigid in deviations to the plan rigid in deviations to the plan ContainContain flexibility to use different methods flexibility to use different methods

for different problemsfor different problems HandleHandle uncertainty uncertainty Domain experts and programmers work Domain experts and programmers work

closelyclosely

29

CleanRoom Approach

SpecificationIncremental Development

Planning Specificationand Design

StatisticalTesting

Certification

UsageDesign

30

Reuse and Automated Development Models/Component Assembly Model





AcceptanceTest


Identify Reusable Components

Informal Specification Formal Specifications Code

SRS

SDS

STP

SIP

31

LightWeight LightWeight MethodologiesMethodologies

Lightweight methodologies :Lightweight methodologies : Customer is the highest priority at all phasesCustomer is the highest priority at all phases Change in requirements welcomed anytimeChange in requirements welcomed anytime Deliver is done frequentlyDeliver is done frequently Domain experts and programmers work closelyDomain experts and programmers work closely Motivate developers via various methodsMotivate developers via various methods Hold conversations while prototyping or Hold conversations while prototyping or

programmingprogramming Amount of workable software is the measure of Amount of workable software is the measure of

success success Good Design occurs every momentGood Design occurs every moment Reflection on designs happen oftenReflection on designs happen often

32

LightWeight LightWeight MethodologiesMethodologies

Differenced between light and heavyDifferenced between light and heavy Individuals over processIndividuals over process Working software over documentationWorking software over documentation Customer collaboration over contractsCustomer collaboration over contracts Responding to change over planningResponding to change over planning Stepping up to the plateStepping up to the plate

33

LightWeight Methodology – LightWeight Methodology – CaLMCaLM

Design

Project Management

Implementation

Meetings

34

ThThe e

XP XP ProProcescesss

Build User Stories

Define Architectural Spikes

Conduct Release Planning

Build Iteration

Conduct Acceptance

Testing

requirements

metaphor

new velocity

estimating

release plan

bugs

next iteration

release

Defines user requirements

Controls Scope

ImprovesQuality

35

Twelve XP PracticesTwelve XP Practices

Five Basic XP PrinciplesFive Basic XP PrinciplesSmall ReleasesSmall Releases40-hour work week40-hour work weekOn-site customerOn-site customerCollective OwnershipCollective OwnershipCoding StandardsCoding Standards

Seven Process TechniquesSeven Process Techniques

36

Twelve XP PracticesTwelve XP Practices

Seven Process TechniquesSeven Process TechniquesThe Planning GameThe Planning GameMetaphorMetaphorSimple DesignSimple DesignPair ProgrammingPair ProgrammingRefactoringRefactoringContinuous IntegrationContinuous IntegrationTestingTesting

37

Visioning. A good visioning practice Project initiation. Short, iterative, feature-driven,

timeboxed delivery Constant feedback. Customer involvement. Technical excellence.

LightWeight Methodology – AgileLightWeight Methodology – Agile

38

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.

THE BESTTHE BEST

1 SEA Side Software Engineering Annotations AAnnotation 5: Process Model One hour presentation to...

Documents

Transcript of 1 SEA Side Software Engineering Annotations AAnnotation 5: Process Model One hour presentation to...