2 SoftwareProcessMgt-Ch2

8/2/2019 2 SoftwareProcessMgt-Ch2

1/56

Page 1

ENGR2720U

ENGR2720 Software Design II

Slides modified from: Introduction to Software Engineering Design (C.Fox) and Software Engineering (R.S. Pressman)

Software Design Process andManagement


2/56

Page 2

ENGR2720U

Software Design Process

A software process is a collection of related tasks that

transforms a set of inputs into a set of outputs for the

purpose designing a software system.

There are many different design processes because it isdifficult to agree on one precise approach, but they all

have the following 2 main tasks:

Elicitation, Analysis, and Design.

They all agree on the fact that:

The design process is highly interactive; designers must

frequently reanalyze the problem and must generate and

improve solutions many times.


3/56

Page 3

ENGR2720U

The Waterfall Model

This is a linear model

Highly criticized because this linear approach is hardly everfollowed. Only in small well defined projects or class projects.

It is generally impossible for a customer to specify all theirrequirements explicitly.

Working version of the program will not be available until the end ofthe project.

Communication

Planning

Modeling

ConstructionDeployment

analysis

designcode

test

project initiat ion

requirement gat hering estimating

scheduling

tracking

delivery

support

f eedback


4/56

Page 4

ENGR2720U

The Incremental Model

C o m m u n ic 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 r y

f e e d b a c k

analysis

design code

t est

increment # 1

increment # 2

delivery of

1st increment

delivery of

2nd increment

delivery of

nt h increment

increment # n

project calendar t ime

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

P l a n n i n g

M o d e l i n g

C o ns 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

analysis

design c o d e

t est

C o m m un 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 ns 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

analysis

designcode

t est


5/56

Page 5

ENGR2720U

The Incremental Model

Good for customers that want a quick delivery.

Suggest a scaled down fully operational system

that will be delivered in the first iteration.

Plan is developed for the next iteration before

the first is done.


6/56

Page 6

ENGR2720U

The Rapid Application Development (RAD) Model

Communication

Planning

Modelingbusiness modeling

data modeling

process modeling

Constructioncomponent reuse

aut omat ic code

generation

t est ing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling

process modelin g

Constructioncomponent reuse

automat ic code

generation

testing

M ode l ing

business modeling

data modeling

process modeling

Const ruc t ioncomponent reuse

automatic code

generation

testing

Team # 2

Team # n

integration

delivery

feedback


7/56

Page 7

ENGR2720U

The RAD Model

Rapid Application Development

Emphasizes a short development cycle.

If requirements are well understood and project scope isconstrained

Modeling and construction are performed in teams inparallel and integrated for deployment.

Drawbacks: For large, but scalable projects, RAD requires sufficient human

resources.

Developers and customers need to be committed

System has to be able to be modularized

Tuning is not possible

Must know the technology to build the system.


8/56

Page 8

ENGR2720U

Evolutionary Models: Prototyping

Comm unicat ion

Quick plan

Const ruct ion

of

prototype

Model ingQuick design

Delivery

& Fee dback

Deployment


9/56

Page 9

ENGR2720U

Evolutionary Models: Prototyping

Generally used as a mechanism for refining the

requirements.

So the modeling and design are done relatively quickly

This generally results in modules that are not complete orperform minimal functionality.

It is suggested that the prototype be thrown out but in

reality developers build up from the prototype.

Drawbacks:

Customer might think that the end product is near completion.

Less than ideal implementations become part of the design.


10/56

Page 10

ENGR2720U

Evolutionary Models: The Spiral

communication

planning

modeling

constructiondeployment

delivery

feedback

start

analysis

design

code

test

estimation

scheduling

risk analysis


11/56

Page 11

ENGR2720U

Evolutionary Models:

Concurrent

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling act ivit y

represents the state

of a software engineering

activity or task

All activities in thegeneric processmodel are done

concurrentlyThe activity is indifferent states asshown in the

figure.Particular eventstrigger transitionsfrom state to state.


12/56

Page 12

ENGR2720U

The Unified Process (UP)

soft ware increment

Release

Inception

Elaboration

construction

transition

production


13/56

Page 13

ENGR2720U

UP PhasesInception Elaboration Construction Transit ion Product ion

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support


14/56

Page 14

ENGR2720U

UP Work Products

Incept ion phase

Elaboration phase

Construct ion phase

Transition phase

Vision document

Init ial use-case model

Init ial project glossary

Init ial business case

Init ial risk assessment .

Project plan,

phases and iterat ions.

Business model,

if necessary.

One or more protot ypesI n c e p t i o

n

Use-case model

Supplementary requirement s

including non-funct ional

Analysis model

Soft ware archit ectureDescription.

Execut able archit ectural

prototype.

Preliminary design model

Revised risk list

Project plan including

it erat ion plan

adapt ed workflows

milest ones

t echnical work products

Preliminary user manual

Design model

Soft ware components

Integrated soft wareincrement

Test p lan and procedure

Test cases

Support document at ion

user manuals

inst allat ion manuals

descript ion of current

increment

Delivered soft ware incrementBeta t est report s

General user feedback


15/56

Page 15

ENGR2720U

Foxs Approach

In this course we focus primarily on the inception

and the elaboration phase consisting of:

ARequirements stage

An analysis stage

And a design stage.

Fox takes an approach that uses UML activity

diagrams to show a very generic software

design process so we need to study UML

Activity Diagrams before continuing


16/56

Page 16

ENGR2720U

UML Activity Diagrams


17/56

Page 17

ENGR2720U

Processes and Their Description

Process description notations describe design

processes as well as computational processes

we design.

A process is a collection of related tasks thattransforms a set of inputs into a set of outputs.

An activity diagram shows actions and theflow of control and data between them.


18/56

Page 18

ENGR2720U

Activities and Actions

An activity is a non-atomic task or

procedure decomposable into actions.

An action is a task or procedure thatcannot be broken into parts.


19/56

Page 19

ENGR2720U

Activity Graph Elements

Sort

Clothes

Wash

Whites

Wash

Darks

Dry

Clothes

Fold

Clothes

Do Laundry

activity symbol

action node

activity edge

initial node

activity final node


20/56

Page 20

ENGR2720U

Execution Model

Execution is modeled by tokens that are produced

by action nodes, travel over action edges, and are

consumed by action nodes.

When there is a token on every incoming edge of

an action node, it consumes them and beginsexecution.

When an action node completes execution, it

produces tokens on each of its outgoing edges.

An initial node produces a token on each outgoingedge when an activity begins.

An activity final node consumes a token available

on any incoming edge and terminates the activity.


21/56

Page 21

ENGR2720U

Branching Nodes

guards

merge

node

decisionnode

Run Drier

Fold

Clothes

Dry Clothes

[else]

[still wet]


22/56

Page 22

ENGR2720U

Branching Execution

If a token is made available on the incoming

edge of a decision node, the token is made

available on the outgoing edge whose guard is

true.

If a token is available on any incoming edge of

a merge node, it is made available on its

outgoing edge.Guards must be mutually exclusive.


23/56

Page 23

ENGR2720U

Deadlock

RunDrier cannot

execute: when the

activity begins,there is a token on

the edge from the

initial node but not

on the otherincoming edge.

Run Drier

Fold

Clothes

Try to Dry

Clothes

[else]

[still wet]


24/56

Page 24

ENGR2720U

Forking and Joining Nodes

fork node

join node

SortClothes

WashWhites

WashDarks

DryClothes

Fold

Clothes

Do Laundry


25/56

Page 25

ENGR2720U

Forking and Joining Execution

A token available on the incoming edge of a

fork node is reproduced and made available

on all its outgoing edges.When tokens are available on every

incoming edge of a join node, a token is

made available on its outgoing edge.

Concurrency can be modeled without thesenodes.


26/56

Page 26

ENGR2720U

Object Nodes

Data and objects are shown as object nodes.

object node

objectnodestate


27/56

Page 27

ENGR2720U

Control and Data Flows

Control tokens do not contain data, data tokensdo.

Acontrol flow is an activity edge that is a

conduit for control tokens.Adata flow is an activity edge that is a conduitfor data tokens.

Rules for token flow through nodes apply to

both control and data tokens, except that datais extracted from consumed tokens and addedto produced tokens.


28/56

Page 28

ENGR2720U

Control and Data Flow Example

Run Drier

FoldClothes

Wash and DryClothes

[else]

[still wet]

Clothes[wet]

Clothes

Wash

Clothes

control flow

control flow

data flows


29/56

Page 29

ENGR2720U

Activity Parameters

Activity parameters are object nodes placed on

activity symbol boundaries to indicate data or

object inputs or outputs.

Activity parameters contain the data or object

name.

Activity parameter types are specified in the

activity symbol beneath the activity name.


30/56

Page 30

ENGR2720U

Activity Parameter Example

max = a[i]

FindMaxa : int[1..*]

max : int

[else]

[i < a.length]

i++

[max < a.[i]]

[else]

max = a[0]i = 1

a

max

outputactivityparameter

inputactivity

parameter

activityparameter

types


31/56

Page 31

ENGR2720U

Activity Diagram Heuristics

Flow control and objects down the page and left

to right.

Name activities and actions with verb phrases.

Name object nodes with noun phrases.

Dont use both control and data flows when a

data flow alone can do the job.

Make sure that all nodes entering an actionnode can provide tokens concurrently.

Use the [else] guard at every branch.


32/56

Page 32

ENGR2720U

Short Exercise

Find the errors in the following activity diagram:

Measure

Room

Cut

Molding

Nail

Molding

Paint[done]

Molding

Trim AR

oom


33/56

Page 33

ENGR2720U

When to Use Activity Diagrams

When making a dynamic model of any process.

Design processes (what designers do)

Designed processes (what designers create) During analysis

During resolution


34/56

Page 34

ENGR2720U

Summary

A process is a collection of related tasks thattransforms a set of inputs to a set of outputs.

UML activity diagrams model processes by depictingactions and the flow of control and data between

them.Activity symbols contain activity graphs consisting of action nodes

action edges

data nodes

special nodes for starting and stopping activities, branching,forking, and joining

Activity diagrams can represent any process and areuseful throughout software design.


35/56

Page 35

ENGR2720U

Software Design Processes and

Management


36/56

Page 36

ENGR2720U

Objectives

To understand how design consists of analysis

and resolution activities

To illustrate and explain generic processes for

software product and engineering design

To explain the five main tasks of project

management

To understand iterative planning and trackingTo see how to apply project management

principles to software design projects


37/56

Page 37

ENGR2720U

Topics

Analysis and resolution

Generic problem-solving and design

processes

Generic software product and engineering

design processes

Project management

Iterative planning and trackingApplying project management to software

design projects


38/56

Page 38

ENGR2720U

Analysis and Resolution

Confusion arises around the term design.

This confusion is removed by adopting the

following terminology.

Analysis is breaking down adesign problem to understand it.

Resolution is solving a design problem.


39/56

Page 39

ENGR2720U

Analysis and Resolution in Software Design

Product Design Analysis

Product Design Resolution

Software DesignProduct Idea : Problem

Design Document : Solution

Engineering Design Analysis

Engineering Design Resolution

ProductIdea

SRS

DesignDocument


40/56

Page 40

ENGR2720U

A Problem-Solving Process

1. Understand the problem

2. Generate candidate solutions

3. Evaluate candidate solutions

4. Select the best solution(s)

5. Iterate if no solution is adequate

6. Ensure the solution is complete and well-documented, and deliver it


41/56

Page 41

ENGR2720U

A Generic Design Process

Analyze theProblem

Generic Designneed : Problem

design : Solution

Resolve the

Problem

need

ProblemStatement

design

[else]

[problemmisunderstood]


42/56

Page 42

ENGR2720U

A Design Resolution Process

Generate/Improve

Candidate Solutions

Generic Design Resolutionproblem : Problem Statement

design : Solution

problem

design

[else]

[adequate solution]

Solutions[candidate]

Evaluate Candidate

Solutions

Solutions

[evaluated]

Select

Solutions

Solutions

[selected]

Finalize

Design

This diagram

shows details of

the resolution

activity from theprevious diagram.


43/56

Page 43

ENGR2720U

Design Process Characteristics

The best solutions are rarely the first

solutions designers think of.

D

esigners should

generate many cand

id

atesolutions.

The design process is highly iterative.

Designers must frequently reanalyze the

problem and

must generate and

improvesolutions many times.


44/56

Page 44

ENGR2720U

A Generic Software Product Design Process

Generic Software Product DesignProject Mission Statement : ProblemSRS : Solution

Project Mission

Statement

SRS

[adequate]

[else]

[complete]

[else]

Analyze Product

Design Problem

Elicit/Analyze

Detailed Needs

Generate/Improve

CandidateRequirements

Evaluate Candidate

Requirements

Select Requirements

FinalizeRequirements

Analysis

Resolution


45/56

Page 45

ENGR2720U

A Generic SoftwareEngineering Design

Process

Generic Software Engineering DesignSRS : Problem

Design Document : Solution

Analysis

ArchitecturalDesign

Design

Document

SRS

[adequate architecture]

[else]

[adequate detailed design]

[adequate architecture]

Analyze SRS

Generate/Improve

Candidate Architectures

Evaluate Candidate

Architectures

Select Architecture

Finalize Architecture

Generate/Improve Detailed

Design Alternatives

Evaluate Detailed

Design Alternatives

[else]

Select Detailed

Design

Finalize Design

[else]

DetailedDesign


46/56

Page 46

ENGR2720U

Architectural and Detailed Design

Later discussions will consider architectural

and detailed design, the latter being further

divided into mid-level and low-level detailed

design.

Architectural design is high-levelsoftware engineering design resolution.

Detailed design is low-level softwareengineering design resolution.


47/56

Page 47

ENGR2720U

Operations versus Projects

Operations are standardized activities that

occur continuously or at regular intervals.

Payroll

Hiring and performance evaluation Shipping and receiving

Projects are one-time efforts to achieve a

particular current goal.

Process improvement

Business restructuring

New product introduction (includingdesign)


48/56

Page 48

ENGR2720U

Project Management Activities

PlanningFormulating a scheme for doing a project.

OrganizingStructuring the organizational entities

involved in a project and assigning them authority and

responsibilities.

StaffingFilling the positions in an organizational

structure and keeping them filled.

TrackingObserving the progress of work and

adjusting work and plans accordingly.

LeadingDirecting and supporting people doing

project work.


49/56

Page 49

ENGR2720U

Project Planning

Estimation is calculation of the approximate cost,effort, time or resources required to achieve someend.

Aschedule specifies the start and duration of work

tasks.Tasks are allocated resources based on theschedule and estimates.

Risk analysis is an orderly process of identifying,understanding, and assessing risks (any occurrence

with negative consequences).Policies, procedures, tools, and techniques arespecified to govern work.


50/56

Page 50

ENGR2720U

Project Organization and Staffing

Organizational structures Project organization

Functional organization

Matrix organization

Team structures Hierarchical teams

Democratic teams

Staffing Often the single most important

factor in success is having goodpeople to do the work.


51/56

Page 51

ENGR2720U

Project Tracking

Projects may not go as planned for many

reasons.

Resource consumption is not as expected.

Tasks do not take as long as expected.

Policies, procedures, tools, or techniques cause

problems.

Something bad occurs (illness, budget cuts,

equipment failures, etc.

When plans fail they must be adjusted.


52/56

Page 52

ENGR2720U

Leading a Project

Direction is needed to follow plans, use

resources efficiently, etc.

Directing people is not enoughpeopleneed inspiration, help, a congenial work

environment, emotional support, etc.

G


53/56

Page 53

ENGR2720U

Iterative Planning and Tracking

Good planning requires knowledge of tasks

and their costs, risks, and other details not

known until the project is under waybut this

is not known when plans are made.

Iterative planning and tracking is making a rough

base or initial project plan, and refining it at

fixed periods during a project in light of

tracking data and completed work products.

ENGR2720U


54/56

Page 54

ENGR2720U

Design Project Management

All five project management activities are

needed to manage a design project.

Iterative planning and tracking is the best

approach to planning and tracking.The design project decomposition on the next

slide is useful for planning, organization,

staffing, and tracking.

Design constitutes the largest activity in software

development, so design can drive an entire

development project.

ENGR2720U


55/56

Page 55

ENGR2720U

Design Project Decomposition

Work Phase Typical Work Products

ProductDesign

Analysis:

Design Problem

Statement of interested parties, product concept, project

scope, markets, business goals

Models (of the problem)

Prototypes (exploring the problem)

Analysis:

Detailed Needs

Client surveys, questionnaires, interview transcripts, etc.

Problem domain descriptionLists of needs, stakeholders

Models (of the problem)

Prototypes (exploring needs)

Resolution:

Product

Specication

Requirements specications

Models (of the product)

Prototypes (demonstrating the product)

Engineering

Design

Analysis

Models (of the engineering problem)

Prototypes (exploring the problem)

Resolution:

Architectural

Design

Architectural design models

Architectural design specications

Architectural prototypes

Resolution:

Detailed Design

Detailed design models

Detailed design specications

Detailed design prototypes

ENGR2720U


56/56

ENGR2720U

Summary

Analysis is breaking a design problem down tounderstand it; resolution is solving a design problem.

Design processes begin with analysis and have a highlyiterative resolution phase.

Designers should generate many candidate solutionsand expect to reanalyze and resolve the problemrepeatedly.

Design management is project management and hencerequires planning, organization, staffing, tracking, andleadership.

Iterative planning and tracking is the best way to makeand revise plans during a project.

Documents

2 SoftwareProcessMgt-Ch2