1

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

Chapter 2, 3, &4Chapter 2, 3, &4ProcessProcess

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.

2

Software Software ProcessProcess

A framework for the tasks that are required to build

high-quality software.

A process defines who is doing what, when, and how

to reach a certain goal.

3

A Process A Process FrameworkFramework

Process frameworkProcess frameworkFramework activity #1Framework activity #1

work taskswork taskswork productswork productsmilestones & deliverablesmilestones & deliverablesQA checkpointsQA checkpoints

……

Framework activity #nFramework activity #n

……

Umbrella ActivitiesUmbrella Activities

4

Generic Framework Generic Framework ActivitiesActivities

CommunicationCommunication: Communication and collaboration : Communication and collaboration with the stakeholders and encompasses requirement with the stakeholders and encompasses requirement gathering and other activities.gathering and other activities.

PlanningPlanning: Establishment of a plan: the technical tasks, : Establishment of a plan: the technical tasks, risks, resources, work products, and a work schedulerisks, resources, work products, and a work schedule

ModelingModeling:: Analysis of requirements: better understanding of Analysis of requirements: better understanding of

requirementsrequirements Design: that achieves the requirementsDesign: that achieves the requirements

ConstructionConstruction Code generation: manual or automatedCode generation: manual or automated Testing: uncover errors.Testing: uncover errors.

DeploymentDeployment: Delivery of software for customer : Delivery of software for customer evaluation with feedback.evaluation with feedback.

5

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

6

The Process Model:The Process Model:AdaptabilityAdaptability

The framework activities will The framework activities will alwaysalways be applied on be applied on everyevery project ... BUT project ... BUT

The tasks (and degree of rigor) for The tasks (and degree of rigor) for each activity will vary based on:each activity will vary based on: the type of project the type of project characteristics of the projectcharacteristics of the project common sense judgment; concurrence of common sense judgment; concurrence of

the project teamthe project team

7

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

work tasks, work products and/or related behaviorswork tasks, work products and/or related behaviors 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)

http://www.ambysoft.com/processPatternsPage.htmlhttp://www.ambysoft.com/processPatternsPage.html

8

Process Patterns – An Process Patterns – An ExampleExample

Pattern NamePattern Name: Prototyping: PrototypingIntentIntent: The objective is to build a model that can be assessed iteratively by : The objective is to build a model that can be assessed iteratively by

stakeholders in an effort to identify or solidify sw requirementsstakeholders in an effort to identify or solidify sw requirementsTypeType: Phase pattern: Phase patternInitial ContextInitial Context: The following preconditions must be met: 1. stakeholders : The following preconditions must be met: 1. stakeholders

have been identified; 2. a mode of communication b/w stakeholders and sw have been identified; 2. a mode of communication b/w stakeholders and sw team has been established; 3. the overriding problem has been identified team has been established; 3. the overriding problem has been identified by stakeholders; 4. an initial understanding of proj. scope, basic by stakeholders; 4. an initial understanding of proj. scope, basic requirements, and constraints has been developed.requirements, and constraints has been developed.

ProblemProblem: Requirements are hazy or nonexistent. Stakeholders are unsure : Requirements are hazy or nonexistent. Stakeholders are unsure that they need.that they need.

SolutionSolution: A description of the prototyping process is presented.: A description of the prototyping process is presented.Resulting ContextResulting Context: A software prototype that identifies basic : A software prototype that identifies basic

requirements is approved by stakeholders.requirements is approved by stakeholders.Related PatternsRelated Patterns: customer-communications; iterative design, …: customer-communications; iterative design, …Known Uses/ExamplesKnown Uses/Examples: Prototyping is recommended when requirements : Prototyping is recommended when requirements

are uncertain.are uncertain.

9

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!

10

Two Schools of Process Two Schools of Process ModelsModels

Prescriptive process models Prescriptive process models advocate an orderly approach to advocate an orderly approach to

software engineeringsoftware engineering Agile developmentAgile development

Encourages early incremental delivery Encourages early incremental delivery of softwareof software

Stresses continuous communication Stresses continuous communication between developers and customersbetween developers and customers

11

Prescriptive Process Prescriptive Process ModelsModels

Define a distinct set of activities, actions, tasks, Define a distinct set of activities, actions, tasks, milestones, and work products.milestones, and work products.

Software engineers and managers adapt a Software engineers and managers adapt a prescriptive process model to their needprescriptive process model to their need

Guide a software team through a set of Guide a software team through a set of framework activities that organized into a linear, framework activities that organized into a linear, incremental, or evolutionary process flow incremental, or evolutionary process flow

The work products are the programs, documents, The work products are the programs, documents, and data that are produced as a consequence of and data that are produced as a consequence of the activities.the activities.

12

The Waterfall The Waterfall ModelModel

Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

13

The Waterfall ModelThe Waterfall Model

It suggests a systematic, sequential approach to It suggests a systematic, sequential approach to software development.software development.

The oldest paradigm for software engineeringThe oldest paradigm for software engineering Suitable for systems whose requirements are well-Suitable for systems whose requirements are well-

defined and reasonably stable.defined and reasonably stable. Drawbacks:Drawbacks:

Real projects rarely follow the sequential flow.Real projects rarely follow the sequential flow. It is often hard for the customer to state all requirements explicitly.It is often hard for the customer to state all requirements explicitly. A working product will not be available until late in the project A working product will not be available until late in the project

time-span.time-span. Requirement errors may not be found until they are very costly to Requirement errors may not be found until they are very costly to

fix.fix.

14

The Incremental The Incremental ModelModel

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e ry f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

De p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t es t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des igncode t es t

15

The Incremental The Incremental ModelModel

The waterfall model applied in an iterative fashion.The waterfall model applied in an iterative fashion. Each linear sequence produces deliverable Each linear sequence produces deliverable

increments of the software.increments of the software. Normally core product is first delivered and Normally core product is first delivered and

supplementary features are incrementally added.supplementary features are incrementally added. Useful when staffing is unavailable for a complete Useful when staffing is unavailable for a complete

implementation by the project deadline.implementation by the project deadline. Increments may be planned to manage technical Increments may be planned to manage technical

risksrisks

16

Rapid Application Rapid Application DevelopmentDevelopment

Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation test ing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback

17

The RAD ModelThe RAD Model The incremental model with a short development cycle.The incremental model with a short development cycle. Multiple RAD teams develop different components of the Multiple RAD teams develop different components of the

system in parallel.system in parallel. Short system development cycle is achieved by using a Short system development cycle is achieved by using a

component-based construction approach.component-based construction approach. Suitable for systems that can be modularized in a way that Suitable for systems that can be modularized in a way that

enables each major function to be completed in a short period enables each major function to be completed in a short period of time.of time.

Drawbacks:Drawbacks: For large systems, it requires sufficient people to form the RAD For large systems, it requires sufficient people to form the RAD

teamsteams If developers and customers are not committed to the rapid-fire If developers and customers are not committed to the rapid-fire

activities, the project would failactivities, the project would fail If the system cannot modularized properly, it can be problematic.If the system cannot modularized properly, it can be problematic. It may be difficult to achieve high performance.It may be difficult to achieve high performance. It may not be appropriate if technical risks are high.It may not be appropriate if technical risks are high.

18

Evolutionary Models: Evolutionary Models: PrototypingPrototyping

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

19

Evolutionary Models: Evolutionary Models: PrototypingPrototyping

Assists the software developer and the customer to better Assists the software developer and the customer to better understand what is to be built when requirements are fuzzy.understand what is to be built when requirements are fuzzy."I know this is what I asked for, but it isn't really what I wanted.""I know this is what I asked for, but it isn't really what I wanted."

A quick throwaway prototype for users to experiment and A quick throwaway prototype for users to experiment and the developer to understand and refine requirements based the developer to understand and refine requirements based on users’ feedback.on users’ feedback...

The customer may falsely perceive the prototype as a The customer may falsely perceive the prototype as a working system, unwilling to continue for a complete working system, unwilling to continue for a complete system.system.

Assumptions and design architecture of the prototype may Assumptions and design architecture of the prototype may influence implicitly the architecture of the real system.influence implicitly the architecture of the real system.

Rarely employed for complete development cycle.Rarely employed for complete development cycle.

20

Evolutionary Models: The Evolutionary Models: The SpiralSpiral

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

21

Evolutionary Models: The Evolutionary Models: The SpiralSpiral

Risk-drivenRisk-driven process model. process model. A A cyclic approachcyclic approach for incrementally growing a for incrementally growing a

system’s degree of definition and implementation.system’s degree of definition and implementation. A set of A set of anchor point milestonesanchor point milestones for ensuring for ensuring

stakeholder commitment for feasible and mutually stakeholder commitment for feasible and mutually satisfactory solutions.satisfactory solutions.

Prototyping can be employed as a risk reduction Prototyping can be employed as a risk reduction mechanism at any stagemechanism at any stage

A good approach for large-scale systems.A good approach for large-scale systems.

22

Still Other Process Still Other Process ModelsModels

Component based developmentComponent based development—systems are built by —systems are built by integrating Commercial off-the-shelf (COTS) software integrating Commercial off-the-shelf (COTS) software components. Following the following steps:components. Following the following steps:1.1. Research and evaluate component-based productsResearch and evaluate component-based products

2.2. Resolve component integration issuesResolve component integration issues

3.3. A software architecture is designed to accommodate the A software architecture is designed to accommodate the componentscomponents

4.4. Components are integrated into the architectureComponents are integrated into the architecture

5.5. Comprehensive testing is conducted.Comprehensive testing is conducted. Formal methodsFormal methods—emphasizes the mathematical —emphasizes the mathematical

specification of requirementsspecification of requirements

23

Still Other Process Still Other Process ModelsModels

Aspect-oriented software development (AOSD)Aspect-oriented software development (AOSD) Certain concerns span the whole system architectureCertain concerns span the whole system architecture

High-level properties of the system: security, fault toleranceHigh-level properties of the system: security, fault tolerance Application of business rulesApplication of business rules Systemic: task synchronization or memory managementSystemic: task synchronization or memory management

AOSD is a process and methodological approach for AOSD is a process and methodological approach for defining, specifying, designing, and constructing aspects.defining, specifying, designing, and constructing aspects.

Unified ProcessUnified Process—a “use-case driven, architecture-—a “use-case driven, architecture-centric, iterative and incremental” software centric, iterative and incremental” software process closely aligned with the Unified Modeling process closely aligned with the Unified Modeling Language (UML) – Details coming soonLanguage (UML) – Details coming soon

24

inceptioninception

The Unified Process (UP)The Unified Process (UP)

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration

25

UP PhasesUP Phases

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

26

UP Work ProductsUP Work ProductsInception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment

Delivered software increment Beta test reports General user feedback

27

The Manifesto for The Manifesto for Agile Software Agile Software DevelopmentDevelopment

““We are uncovering better ways of We are uncovering better ways of developing software by doing it and helping developing software by doing it and helping others do it. Through this work we have others do it. Through this work we have come to value: come to value:

•Individuals and interactionsIndividuals and interactions over over processes and tools processes and tools •Working softwareWorking software over comprehensive over comprehensive documentation documentation •Customer collaborationCustomer collaboration over contract over contract negotiation negotiation •Responding to changeResponding to change over following a over following a planplan

That is, while there is value in the items on That is, while there is value in the items on the right, we value the items on the left the right, we value the items on the left more.”more.”

Kent Beck et alKent Beck et al

28

What is “Agility”?What is “Agility”?

Effective (rapid and adaptive) response to Effective (rapid and adaptive) response to changechange

Effective communication among all Effective communication among all stakeholdersstakeholders

Drawing the customer onto the teamDrawing the customer onto the team Organizing a team so that it is in control of Organizing a team so that it is in control of

the work performedthe work performed

Yielding …Yielding … Rapid, incremental delivery of softwareRapid, incremental delivery of software

29

An Agile ProcessAn Agile Process

Is driven by customer descriptions of what Is driven by customer descriptions of what is required (scenarios)is required (scenarios)

Recognizes that plans are short-livedRecognizes that plans are short-lived Develops software iteratively with a heavy Develops software iteratively with a heavy

emphasis on construction activitiesemphasis on construction activities Delivers multiple ‘software increments’Delivers multiple ‘software increments’ Adapts as changes occurAdapts as changes occur

30

Extreme Programming (XP)Extreme Programming (XP)

The most widely used agile process, originally The most widely used agile process, originally proposed by Kent Beckproposed by Kent Beck

XP PlanningXP Planning Begins with the creation of “Begins with the creation of “user storiesuser stories”” Agile team assesses each story and assigns a Agile team assesses each story and assigns a costcost Stories are grouped to for a Stories are grouped to for a deliverable incrementdeliverable increment A A commitmentcommitment is made on delivery date is made on delivery date After the first increment “After the first increment “project velocityproject velocity” is used to ” is used to

help define subsequent delivery dates for other help define subsequent delivery dates for other incrementsincrements

31

Extreme Programming (XP)Extreme Programming (XP)

XP DesignXP Design Follows the Follows the KIS principle (nothing less, nothing more.)KIS principle (nothing less, nothing more.) Encourage the use of Encourage the use of CRC cardsCRC cards for classes relevant to the current for classes relevant to the current

increment.increment. For difficult design problems, suggests the creation of “For difficult design problems, suggests the creation of “spike spike

solutionssolutions”—a design prototype”—a design prototype Encourages “Encourages “refactoringrefactoring”—an iterative refinement of the internal ”—an iterative refinement of the internal

program designprogram design XP CodingXP Coding

Recommends the Recommends the construction of a unit testconstruction of a unit test for the stories for the stories beforebefore coding coding commencescommences

Encourages “Encourages “pair programmingpair programming”” XP TestingXP Testing

All All unit tests are executed dailyunit tests are executed daily ““Acceptance tests”Acceptance tests” are defined by the customer and executed to assess are defined by the customer and executed to assess

customer visible functionalitycustomer visible functionality

32

Extreme Programming (XP)Extreme Programming (XP)

unit test continuous integration

acceptance testing

pair programming

Release

user stories values acceptance test criteria iteration plan

simple design CRC cards

spike solutions prototypes

refactoring

software incrementproject velocity computed

33

Adaptive Software Adaptive Software DevelopmentDevelopment

Originally proposed for complex systems Originally proposed for complex systems by Jim Highsmithby Jim Highsmith

ASD — distinguishing featuresASD — distinguishing features Mission-drivenMission-driven planning planning Component-based focusComponent-based focus Uses “Uses “time-boxingtime-boxing” (See Chapter 24)” (See Chapter 24) Explicit consideration of Explicit consideration of risksrisks Emphasizes Emphasizes collaborationcollaboration for requirements for requirements

gatheringgathering Emphasizes “Emphasizes “learninglearning” throughout the process” throughout the process

34

Adaptive Software Adaptive Software DevelopmentDevelopment

SpeculationSpeculation Adaptive cycle planning uses initiation information Adaptive cycle planning uses initiation information

to define the set of release cycles (increments)to define the set of release cycles (increments) CollaborationCollaboration

Team members multiply their talent and creative Team members multiply their talent and creative output with mutual trust. (1) criticize without output with mutual trust. (1) criticize without animosity (2) assist without resentment (3) work animosity (2) assist without resentment (3) work as hard/harder as othersas hard/harder as others

LearningLearning As development progresses members learn toward As development progresses members learn toward

the complete cycle through the complete cycle through focus groupsfocus groups, , formal formal technical reviewtechnical review, and , and postmortemspostmortems..

35

Adaptive Software Adaptive Software DevelopmentDevelopment

adaptive cycle planning uses mission statement project constraints basic requirements time-boxed release plan

Requirements gathering J AD mini-specs

components implemented/ tested focus groups for feedback formal technical reviews postmortems

software incrementadjustments for subsequent cycles

Release

36

Dynamic Systems Development Dynamic Systems Development MethodMethod

Promoted by the DSDM Consortium (Promoted by the DSDM Consortium (www.dsdm.orgwww.dsdm.org)) DSDM—distinguishing featuresDSDM—distinguishing features

Similar in most respects to XP and/or ASDSimilar in most respects to XP and/or ASD Nine guiding principlesNine guiding principles

Active user involvement is imperative. Active user involvement is imperative. DSDM teams must be empowered to make decisions.DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of Fitness for business purpose is the essential criterion for acceptance of

deliverables.deliverables. Iterative and incremental development is necessary to converge on an accurate Iterative and incremental development is necessary to converge on an accurate

business solution.business solution. All changes during development are reversible.All changes during development are reversible. Requirements are baselined at a high levelRequirements are baselined at a high level Testing is integrated throughout the life-cycle.Testing is integrated throughout the life-cycle.

37

ScrumScrum

Originally proposed by Schwaber and BeedleOriginally proposed by Schwaber and Beedle Scrum—distinguishing featuresScrum—distinguishing features

Development work is partitioned into “Development work is partitioned into “packetspackets”” Testing and documentation are on-goingTesting and documentation are on-going as the product as the product

is constructedis constructed Work occurs in “Work occurs in “sprintssprints” and is derived from a ” and is derived from a

““backlogbacklog” of existing requirements” of existing requirements Meetings are very shortMeetings are very short and sometimes conducted and sometimes conducted

without chairswithout chairs ““demosdemos” are delivered to the customer with the time-box ” are delivered to the customer with the time-box

allocatedallocated

38

CrystalCrystal

Proposed by Cockburn and HighsmithProposed by Cockburn and Highsmith Crystal—distinguishing featuresCrystal—distinguishing features

Actually a Actually a family of process modelsfamily of process models that allow that allow ““maneuverabilitymaneuverability” based on problem characteristics” based on problem characteristics

Face-to-face communicationFace-to-face communication is emphasized is emphasized Suggests the use of “Suggests the use of “reflection workshopsreflection workshops” to ” to

review the work habits of the teamreview the work habits of the team

39

Feature Driven DevelopmentFeature Driven Development

Originally proposed by Peter Coad et alOriginally proposed by Peter Coad et al FDD—distinguishing featuresFDD—distinguishing features

Emphasis is on defining Emphasis is on defining “features”“features” aa featurefeature “is a client-valued function that can be “is a client-valued function that can be

implemented in two weeks or less.”implemented in two weeks or less.” Uses a Uses a feature templatefeature template

<action> the <result> <by | for | of | to> a(n) <object><action> the <result> <by | for | of | to> a(n) <object>Add the product to a shopping cartAdd the product to a shopping cartDisplay the technical spec of a productDisplay the technical spec of a productStore the shipping info for a customerStore the shipping info for a customer

A A features listfeatures list is created and “ is created and “plan by featureplan by feature” is ” is conductedconducted

Design and construction merge in FDDDesign and construction merge in FDD