27
1 Software Engineering: A Practitioner’s Approach, 7/e Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Chapter 2 Process: A Generic View Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Embed Size (px)

Citation preview

Page 1: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

1

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 7/eApproach, 7/e

Chapter 2Chapter 2Process: A Generic ViewProcess: A Generic View

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

Page 2: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

2

A Layered A Layered TechnologyTechnology

Software Engineering

a “quality” focusa “quality” focus

process modelprocess model

methodsmethods

toolstools

Page 3: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

System Development Life CycleSystem Development Life Cycle

It is about developing a software-drivenIt is about developing a software-driven solution to a business problemsolution to a business problem It concerns a process which takes from two It concerns a process which takes from two

months to two yearsmonths to two years This is called a System Development Life Cycle This is called a System Development Life Cycle

but it should really be called a (Business) but it should really be called a (Business) Solution Development Life CycleSolution Development Life Cycle

3

Page 4: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Business Solution Business Solution CharacteristicsCharacteristics

A software-driven solution consists of two parts:A software-driven solution consists of two parts: ModelModel

PrototypesPrototypes Diagrams and supporting DocumentsDiagrams and supporting Documents

SystemSystem HardwareHardware SoftwareSoftware

4

Page 5: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Sample DeliverablesSample Deliverables Analysis:Analysis:

Use caseUse case Shows the dynamics between the users (actors) of the system and the Shows the dynamics between the users (actors) of the system and the

system itselfsystem itself This is a narrative representationThis is a narrative representation

Conceptual DiagramConceptual Diagram Shows the structure of the objects and their relationshipsShows the structure of the objects and their relationships This is a graphical representationThis is a graphical representation

System Sequence DiagramSystem Sequence Diagram Shows the dynamics between the users (actors) of the system and the Shows the dynamics between the users (actors) of the system and the

system itselfsystem itself This is a graphical representationThis is a graphical representation

ContractsContracts Shows the state of each object before each actionShows the state of each object before each action This is a narrative representationThis is a narrative representation

5

Page 6: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Sample High-level Sample High-level Architecture Design Logical Architecture Design Logical

BlueprintBlueprint

6

Page 7: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Sample Deliverables - DesignSample Deliverables - Design

Design:Design: Interaction DiagramInteraction Diagram

Shows the interaction between objectsShows the interaction between objects This is a graphic representationThis is a graphic representation It is a dynamic blueprintIt is a dynamic blueprint

Class DiagramClass Diagram Shows the structure between objectsShows the structure between objects Shows the structure inside objectsShows the structure inside objects This is a graphic representationThis is a graphic representation It is a static blueprintIt is a static blueprint

7

Page 8: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

A Generic A Generic Process Process ModelModel

8

Page 9: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Identifying a Task SetIdentifying a Task Set

A task set defines the actual work to be done to A task set defines the actual work to be done to accomplish the objectives of a software accomplish the objectives of a software engineering actionengineering action

A list of the tasks to be accomplishedA list of the tasks to be accomplished A list of the work products to be producedA list of the work products to be produced A list of the quality assurance filters to be appliedA list of the quality assurance filters to be applied

9

Page 10: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

10

A Process A Process FrameworkFramework

Process frameworkProcess frameworkFramework activitiesFramework activities

work taskswork taskswork productswork productsmilestones & deliverablesmilestones & deliverablesQA checkpointsQA checkpoints

Umbrella ActivitiesUmbrella Activities

Page 11: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

11

Framework ActivitiesFramework Activities

CommunicationCommunication PlanningPlanning ModelingModeling

Analysis of requirementsAnalysis of requirements DesignDesign

ConstructionConstruction Code generationCode generation TestingTesting

DeploymentDeployment

Page 12: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

12

Umbrella ActivitiesUmbrella Activities Software project managementSoftware project management Formal technical reviewsFormal technical reviews Software quality assuranceSoftware quality assurance Software configuration managementSoftware configuration management Work product preparation and Work product preparation and

productionproduction Reusability managementReusability management MeasurementMeasurement Risk managementRisk management

Page 13: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

13

Process PatternsProcess Patterns Process patterns define a set of activities, Process patterns define a set of activities,

actions, work tasks, work products and/or related actions, work tasks, work products and/or related behaviorsbehaviors

A template is used to define a patternA template is used to define a pattern Typical examples:Typical examples:

Customer communication (a process activity)Customer communication (a process activity) Analysis (an action)Analysis (an action) Requirements gathering (a process task)Requirements gathering (a process task) Reviewing a work product (a process task)Reviewing a work product (a process task) Design model (a work product)Design model (a work product)

Page 14: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Process Pattern TypesProcess Pattern Types

Stage patterns Stage patterns - - defines a problem associated with a defines a problem associated with a framework activity for the processframework activity for the process

Task patterns Task patterns - - defines a problem associated with a defines a problem associated with a software engineering action or work task and software engineering action or work task and relevant to successful software engineering practicerelevant to successful software engineering practice

Phase patterns Phase patterns - - define the sequence of framework define the sequence of framework activities that occur with the process, even when activities that occur with the process, even when the overall flow of activities is iterative in naturethe overall flow of activities is iterative in nature

14

Page 15: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Waterfall ModelWaterfall Model

15

Page 16: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Incremental ModelIncremental Model

16

Page 17: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Evolutionary Model: SpiralEvolutionary Model: Spiral

17

Page 18: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Other ModelsOther Models

Component based development - Component based development - the process to the process to apply when reuse is a development objectiveapply when reuse is a development objective

Formal methods - Formal methods - emphasizes the mathematical emphasizes the mathematical specification of requirementsspecification of requirements

AOSD - AOSD - provides a process and methodological provides a process and methodological approach for defining, specifying, designing, and approach for defining, specifying, designing, and constructing constructing aspectsaspects

Unified Process - Unified Process - a “use-case driven, architecture-a “use-case driven, architecture-centric, iterative and incremental” software process centric, iterative and incremental” software process closely aligned with the Unified Modeling Language closely aligned with the Unified Modeling Language (UML)(UML)

18

Page 19: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

UP PhasesUP Phases

19

Page 20: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Personal Software Personal Software Process(PSP)Process(PSP)

Planning.Planning. This activity isolates requirements and develops both size and resource This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created.development tasks are identified and a project schedule is created.

High-level design. High-level design. External specifications for each component to be constructed External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.uncertainty exists. All issues are recorded and tracked.

High-level design review.High-level design review. Formal verification methods are applied to uncover Formal verification methods are applied to uncover errors in the design. Metrics are maintained for all important tasks and work errors in the design. Metrics are maintained for all important tasks and work results.results.

Development. Development. The component level design is refined and reviewed. Code is The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.important tasks and work results.

PostmortemPostmortem. . Using the measures and metrics collected (this is a substantial Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.modifying the process to improve its effectiveness.

20

Page 21: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

22

The CMMIThe CMMI The CMMI defines each process area in terms of The CMMI defines each process area in terms of

“specific goals” and the “specific practices” “specific goals” and the “specific practices” required to achieve these goals.required to achieve these goals.

Specific goalsSpecific goals establish the characteristics that establish the characteristics that must exist if the activities implied by a process must exist if the activities implied by a process area are to be effective. area are to be effective.

Specific practicesSpecific practices refine a goal into a set of refine a goal into a set of process-related activities.process-related activities.

Page 22: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

Homework #2Homework #2

Research and put together a comparative write-up or Research and put together a comparative write-up or traditional Process Models traditional Process Models (300 words max):(300 words max):

WaterfallWaterfall VV PhasedPhased EvolutionaryEvolutionary SpiralSpiral CBSECBSE RUPRUP PSP/TSPPSP/TSP

23

Page 23: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

24

Process AssessmentProcess Assessment

The process should be assessed to ensure that it The process should be assessed to ensure that it meets a set of basic process criteria that have meets a set of basic process criteria that have been shown to be essential for a successful been shown to be essential for a successful software engineeringsoftware engineering.

Many different assessment options are available: Many different assessment options are available: SCAMPISCAMPI CBA IPICBA IPI SPICESPICE ISO 9001:2000ISO 9001:2000

Page 24: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

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 25

Assessment and ImprovementAssessment and Improvement

Software Process

Software Process Assessment

is examined by identifies capabilitiesand risk of

identifiesmodifications to

Software Process Improvement

Capability Determination

leads to leads to

motivates

Page 25: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

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 26

Personal Software Process Personal Software Process (PSP)(PSP)

Recommends five framework activities:Recommends five framework activities: PlanningPlanning High-level designHigh-level design High-level design reviewHigh-level design review DevelopmentDevelopment PostmortemPostmortem

stresses the need for each software stresses the need for each software engineer to identify errors early and as engineer to identify errors early and as important, to understand the types of important, to understand the types of errorserrors

Page 26: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

27

Team Software Process (TSP)Team Software Process (TSP)

Each project is “launched” using a “script” Each project is “launched” using a “script” that defines the tasks to be accomplishedthat defines the tasks to be accomplished

Teams are self-directedTeams are self-directed Measurement is encouragedMeasurement is encouraged Measures are analyzed with the intent of Measures are analyzed with the intent of

improving the team processimproving the team process

Page 27: 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2

28

The Primary Goal of Any Software The Primary Goal of Any Software Process: Process: High QualityHigh Quality

Remember:Remember:

High quality = project timelinessHigh quality = project timeliness

Why?Why?

Less rework!Less rework!