1 Chapter 2 The Process. 2 Software Engineering A Layered Technology Software Engineering a...

40
1 Chapter 2 Chapter 2 The Process The Process

Transcript of 1 Chapter 2 The Process. 2 Software Engineering A Layered Technology Software Engineering a...

1

Chapter 2Chapter 2The The

ProcessProcess

2

Software Engineering

A Layered A Layered TechnologyTechnology

Software Engineering

a “quality” focusa “quality” focus

process modelprocess model

methodsmethods

toolstools

3

A Common Process A Common Process FrameworkFramework

Common process frameworkCommon process framework

Framework activitiesFramework activities

work taskswork tasks

work productswork products

milestones & deliverablesmilestones & deliverables

QA checkpointsQA checkpoints

Umbrella ActivitiesUmbrella Activities

4

Umbrella Umbrella ActivitiesActivities

Software project managementSoftware project management Formal technical reviewsFormal technical reviews Software quality assuranceSoftware quality assurance Software configuration managementSoftware configuration management Document preparation and Document preparation and

productionproduction Reusability managementReusability management MeasurementMeasurement Risk managementRisk management

5

The Process The Process Model:Model:

AdaptabilityAdaptability the framework activities will the framework activities will alwaysalways be be applied on applied on everyevery project ... BUT project ... BUT

the tasks (and degree of rigor) for each the tasks (and degree of rigor) for each activity will vary based on:activity will vary based on:

the type of project (an “entry point” to the model)the type of project (an “entry point” to the model)characteristics of the projectcharacteristics of the projectcommon sense judgment; concurrence of the project common sense judgment; concurrence of the project

teamteam

6

Linear Linear ModelsModels

analysis design code test

System/informationengineering

7

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

8

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

9

Rapid Application Development ModelRapid Throwaway Prototype Model

SoftwareRequirements

Analysis

SoftwareDesign

Code and UnitTesting Software

Integrationand Test Software

AcceptanceTest

SSR PDR CDR TRR CRRFCAPCA

BuildPrototype

PR

SRS

PDD

SDS

STP

SIP

10

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

11

Reuse and Automated Development Models/Component Assembly Model

SoftwareRequirements

AnalysisSoftwareDesign

Code and UnitTesting Software

Integrationand Test Software

AcceptanceTest

SSR PDR CDR TRR CRRFCAPCA

Identify Reusable Components

Informal Specification Formal Specifications Code

SRS

SDS

STP

SIP

12

Component Based Component Based DevelopmentDevelopment

Architecture for Software ReuseBased on Object OrientationClasses are stored in a libraryWhen requirements are received,the first

stop is the library

13

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.

14

Iterative Iterative ModelsModels

listento

customerbuild/revisemock-up

customertest-drivesmock-up

Prototyping

15

Evolutionary (Prototype) Model

ONLY A PART OF THE FULL SYSTEM

Series of Implementations of each PART

SoftwareRequirements

Analysis

SoftwareDesign

Code and UnitTesting Software

Integrationand Test Software

AcceptanceTest

SSR PDR CDR TRR CRRFCAPCA

BuildPrototype

PR

SRS

PDD

SDS

STP

SIP

16

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

17

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

18

The Incremental The Incremental ModelModel

analysis design code test

System/informationengineering

analysis design code test

analysis design code test

analysis design code test

increment 2

increment 3

increment 4

increment 1

delivery of1st increment

delivery of2nd increment

delivery of3rd increment

delivery of4th increment

calendar time

19

SoftwareRequirements

AnalysisSoftwareDesign

Code and UnitTesting Software

Integrationand Test Software

AcceptanceTest

SSR PDR CDR TRR CRRFCAPCA

Incremental Development Model

ONLY A PART OF THE FULL SYSTEM

Can Determine a PART at any phase.

SRS

SDS

STP

SIP

20

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"

21

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

22

Spiral Model

Risk Analysis

Prototyping

Planning

Client Evaluation and Input

Simulation

Operational Prototype

Verification for Next Level

Developing

23

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

24

CleanRoom Approach

SpecificationIncremental Development

Planning Specificationand Design

StatisticalTesting

Certification

UsageDesign

25

REQUIREMENTSANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

Verify design

Validate requirements

[Pfleeger 98]

V V ModelModel

26

Operational Specification Operational Specification ModelModel

DELIVEREDSYSTEM

Execute andRevise

SYSTEMREQUIREMENTS

(sometimes informalor incomplete)

TESTOPERATIONALSPECIFICATION

(problem-oriented)

TRANSFORMEDSPECIFICATION

(implementation-oriented)

[Pfleeger 98]

27

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

28

Formal Method Formal Method CharacteristicsCharacteristics

Formal Methods Model Specifications produce proofsRequired rigorous notationEnhances accuracyReduces flexibility

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

Formal Methods AbstractionAdd formality to reduce ambiguity Use graphical representations

Describe the possible system states, transitions, and triggers

29

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.

30

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

31

Level 1: Level 1: InitialInitial

The software process is The software process is characterized as ad hoc, characterized as ad hoc, and occasionally even and occasionally even chaotic. Few processes chaotic. Few processes are defined, and are defined, and success depends on success depends on individual effort.individual effort.

32

Level 2: Level 2: RepeatableRepeatable

Basic project management Basic project management processes are established to processes are established to track cost, schedule, and track cost, schedule, and functionality. The necessary functionality. The necessary process discipline is in place process discipline is in place to repeat earlier successes to repeat earlier successes on projects with similar on projects with similar applicationsapplications

33

Process Maturing to Process Maturing to Level 2Level 2

Software configuration Software configuration managementmanagement

Software quality assuranceSoftware quality assurance Software subcontract Software subcontract

managementmanagement Software project tracking and Software project tracking and

oversightoversight Software project planningSoftware project planning Requirement managementRequirement management

34

Level 3: Level 3: DefinedDefined

The software process for both The software process for both management and engineering management and engineering activities is documented, activities is documented, standardized, and integrated into an standardized, and integrated into an organization-wide software process. organization-wide software process. All projects use a documented and All projects use a documented and approved version of the approved version of the organization’s process for developing organization’s process for developing and maintaining software. and maintaining software.

This level includes all characteristics This level includes all characteristics defined for level 2.defined for level 2.

35

Process Maturing Process Maturing Level 3Level 3

Peer ReviewsPeer Reviews Inter-group coordinationInter-group coordination Software product engineeringSoftware product engineering Integrated software managementIntegrated software management Training programTraining program Organization process definitionOrganization process definition Organization process focusOrganization process focus

36

Level 4: Level 4: ManagedManaged

Detailed measures of the Detailed measures of the software process and product software process and product quality are collected. Both the quality are collected. Both the software process and products software process and products are quantitatively understood are quantitatively understood and controlled using detailed and controlled using detailed measures.measures.

This level includes all This level includes all characteristics defined for level 3.characteristics defined for level 3.

37

Process Maturing Process Maturing Level 4Level 4

Software quality Software quality managementmanagement

Quantitative process Quantitative process managementmanagement

38

Level 5: Level 5: OptimizingOptimizing

Continuous process Continuous process improvement is enables by improvement is enables by quantitative feedback from the quantitative feedback from the process and from testing process and from testing innovative ideas and innovative ideas and technologiestechnologies

This level includes all This level includes all characteristics defined for level characteristics defined for level 5.5.

39

Process Maturing Process Maturing Level 5Level 5

Process change Process change managementmanagement

Technology change Technology change managementmanagement

Defect preventionDefect prevention

40

CMM CMM IssuesIssues

focuses on project management rather focuses on project management rather than than product development. product development.

ignores the use of technologies such as ignores the use of technologies such as rapid rapid prototyping.prototyping.

does not incorporate risk analysis as a key does not incorporate risk analysis as a key process areaprocess area

does not define its domain of applicabilitydoes not define its domain of applicability