ENGR2720U

ENGR2720 Software Design II

Software Design Process and Management

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

Page 1

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 is difficult 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.

Page 2

ENGR2720U

The Waterfall Model

Com m unic a t ion
projec t init iat ion requirem ent gat hering

Planning
estimating scheduling tracking

Mode ling
analysis design

Const r uc t ion
code t est

De ploy m ent
deliv ery s upport f ee dba ck

This is a linear model Highly criticized because this linear approach is hardly ever followed. Only in small well defined projects or class projects. It is generally impossible for a customer to specify all their requirements explicitly. Working version of the program will not be available until the end of the project.

Page 3

ENGR2720U

The Incremental Model

increment # n
Co m m u n ic a t io n Pla n nin g M odeling a na l ys is d es i gn

Co n s t ru c t io n co d e t es t De p l o y m e n t d e li v e ry feed back

increment # 2
Comm unicat ion Pla nning M odeling a n a ly si s d e s ig n

deliv ery of nt h increment

Co n s t ru c t i o n c ode t es t De p lo y m e n t de l i v e ry feedback

increment # 1
Co m m u n ic a t i o n Pla nning M o de ling a n al ys i s d e si gn Co n s t ru c t i o n c o de t e st De p l o y m e n t d e l i v e ry fe e d b a c k

deliv ery of 2nd increment

deliv ery of 1st increment

project calendar t ime

Page 4

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.

Page 5

ENGR2720U

The Rapid Application Development (RAD) Model

Team # n
M o d e lin g
business m odeling data m odeling process m odeling

C o n s t r u c t io n

Com municat ion

Team # 2
Mo d eling
b usine ss m od el ing d at a m o de lin g p ro cess m o de lin g

com ponent reuse autom at ic code generat ion testing

Planning
Co nst r uct i o n

De ployme nt
int egrat ion deliv ery feedback

Team # 1 Mode ling

business modeling dat a modeling process modeling

co m po ne nt re use au t o m at ic cod e g en era t io n t e st ing

Const r uct ion

component reuse aut omat ic code generat ion t est ing

6 0 - 9 0 days

Page 6

ENGR2720U

The RAD Model

Rapid Application Development Emphasizes a short development cycle. If requirements are well understood and project scope is constrained Modeling and construction are performed in teams in parallel 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.

Page 7

ENGR2720U

Evolutionary Models: Prototyping

Q u ick p lan

Co m m u n icat io n

Mo d e l i n g Q u i ck d e s i g n

Deployment De live r y & Fe e d b ack

Co n st r u ct io n of p r o t o t yp e

Page 8

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 or
perform 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.

Page 9

ENGR2720U

Evolutionary Models: The Spiral

planning
estimation scheduling risk analysis

communication modeling
analysis design start

deployment
delivery feedback

construction
code test

Page 10

ENGR2720U

Evolutionary Models: Concurrent All activities in the generic process model are done concurrently The activity is in different states as shown in the figure. Particular events trigger transitions from state to state.

none Modeling act ivit y

Under development

represents the state of a software engineering activity or task

A wait ing changes

Under review Under revision Baselined

Done

Page 11

ENGR2720U

The Unified Process (UP)

Elab o r at io n Incep t io n

co nst r uct io n
Release
soft ware increment

t r ansit io n

p r o d uct io n
Page 12

ENGR2720U

UP Phases
Workflows Requirements

UP Phases
Incept ion Elaboration Construction Transition Product ion

Analysis Design

Implementation Test Support Iterations #1 #2 #n-1 #n

Page 13

ENGR2720U

UP Work Products
Incept ion phase
Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary . One or more prot ot y pes
I nc e pt i o n

Elaboration phase
Use-case model Supplement ary requirement s including non-funct ional Analy sis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot y pe. Preliminary design model Rev ised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual

Construction phase
Design model Soft ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment

Transition phase
Deliv ered soft ware increment Bet a t est report s General user feedback

Page 14

ENGR2720U

Foxs Approach In this course we focus primarily on the inception and the elaboration phase consisting of:  A Requirements 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

Page 15

ENGR2720U

UML Activity Diagrams

Page 16

ENGR2720U

Processes and Their Description

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

Process description notations describe design processes as well as computational processes we design.
An activity diagram shows actions and the flow of control and data between them.

Page 17

ENGR2720U

Activities and Actions

An activity is a non-atomic task or procedure decomposable into actions. An action is a task or procedure that cannot be broken into parts.

Page 18

ENGR2720U

Activity Graph Elements

Do Laundry Sort Clothes Wash Whites Dry Clothes Fold Clothes Wash Darks

initial node action node activity symbol activity edge

activity final node

Page 19

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 begins execution. When an action node completes execution, it produces tokens on each of its outgoing edges. An initial node produces a token on each outgoing edge when an activity begins. An activity final node consumes a token available on any incoming edge and terminates the activity.
Page 20

ENGR2720U

Branching Nodes

Dry Clothes

merge node

Run Drier [still wet]

decision node

[else] Fold Clothes

guards

Page 21

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.

Page 22

ENGR2720U

Deadlock RunDrier cannot execute: when the activity begins, there is a token on the edge from the initial node but not on the other incoming edge.

Try to Dry Clothes Run Drier

[still wet] [else] Fold Clothes

Page 23

ENGR2720U

Forking and Joining Nodes

Do Laundry Sort Clothes

fork node
Wash Darks

Wash Whites

Dry Clothes Fold Clothes

join node

Page 24

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 these nodes.

Page 25

ENGR2720U

Object Nodes Data and objects are shown as object nodes.

object node state object node

Page 26

ENGR2720U

Control and Data Flows

Control tokens do not contain data, data tokens

do. A control flow is an activity edge that is a conduit for control tokens. A data flow is an activity edge that is a conduit for data tokens. Rules for token flow through nodes apply to both control and data tokens, except that data is extracted from consumed tokens and added to produced tokens.
Page 27

ENGR2720U

Control and Data Flow Example

Wash and Dry Clothes Wash Clothes Clothes [wet]

control flow

data flows
Run Drier Clothes [still wet] [else ] Fold Clothes

control flow

Page 28

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.

Page 29

ENGR2720U

Activity Parameter Example

activity parameter types input activity parameter
FindMax
a : int[1..*] max : int a

max = a[0] i=1

[else] [i < a.length] [else] [max < a.[i]] max = a[i]

max

i++

output activity parameter

Page 30

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 action node can provide tokens concurrently. Use the [else] guard at every branch.
Page 31

ENGR2720U

Short Exercise Find the errors in the following activity diagram:

Molding Trim A Room

Measure Room

Cut Molding

Nail Molding

[done]

Paint

Page 32

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

Page 33

ENGR2720U

Summary
A process is a collection of related tasks that transforms a set of inputs to a set of outputs. UML activity diagrams model processes by depicting actions 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 are useful throughout software design.
Page 34

ENGR2720U

Software Design Processes and Management

Page 35

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 tracking To see how to apply project management principles to software design projects
Page 36

ENGR2720U

Topics Analysis and resolution Generic problem-solving and design processes Generic software product and engineering design processes Project management Iterative planning and tracking Applying project management to software design projects
Page 37

ENGR2720U

Analysis and Resolution Confusion arises around the term design. This confusion is removed by adopting the following terminology.
Analysis is breaking down a design problem to understand it. Resolution is solving a design problem.

Page 38

ENGR2720U

Analysis and Resolution in Software Design

Software Design
Product Idea : Problem Design Document : Solution

Product Idea

Product Design Analysis

Product Design Resolution

SRS

Engineering Design Analysis

Engineering Design Resolution

Design Document

Page 39

ENGR2720U

A Problem-Solving Process 1. 2. 3. 4. 5. 6. Understand the problem Generate candidate solutions Evaluate candidate solutions Select the best solution(s) Iterate if no solution is adequate Ensure the solution is complete and welldocumented, and deliver it

Page 40

ENGR2720U

A Generic Design Process

Generic Design
need : Problem design : Solution

need

Analyze the Problem Problem Statement Resolve the Problem [problem misunderstood] [else]

design

Page 41

ENGR2720U

A Design Resolution Process

Generic Design Resolution
problem : Problem Statement design : Solution problem

Generate/Improve Candidate Solutions

Solutions [candidate]

This diagram shows details of the resolution activity from the previous diagram.

Evaluate Candidate Solutions

Solutions [evaluated]

Select Solutions

Solutions [selected] [else] [adequate solution] Finalize Design design

Page 42

ENGR2720U

Design Process Characteristics The best solutions are rarely the first solutions designers think of.  Designers should generate many candidate
solutions.

The design process is highly iterative.  Designers must frequently reanalyze the
problem and must generate and improve solutions many times.

Page 43

ENGR2720U

A Generic Software Product Design Process

Generic Software Product Design
Project Mission Statement : Problem SRS : Solution

Project Mission Statement

Analyze Product Design Problem Analysis Elicit/Analyze Detailed Needs

Generate/Improve Candidate Requirements Evaluate Candidate Requirements

Select Requirements [else] [adequate] [else] [complete] Finalize Requirements SRS

Resolution

Page 44

ENGR2720U
Generic Software Engineering Design
SRS : Problem Design Document : Solution

SRS

Analyze SRS

Analysis

Generate/Improve Candidate Architectures Evaluate Candidate Architectures

A Generic Software Engineering Design Process

Architectural Design

Select Architecture [else] [adequate architecture] Finalize Architecture

Generate/Improve Detailed Design Alternatives Evaluate Detailed Design Alternatives Select Detailed Design [else] [else] [adequate detailed design] [adequate architecture] Finalize Design Design Document Detailed Design

Page 45

ENGR2720U Architectural and Detailed Design Architectural design is high-level software engineering design resolution. Detailed design is low-level software engineering design resolution.

Later discussions will consider architectural and detailed design, the latter being further divided into mid-level and low-level detailed design.
Page 46

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 (including design)
Page 47

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.

Page 48

ENGR2720U

Project Planning
Estimation is calculation of the approximate cost,

effort, time or resources required to achieve some end. A schedule specifies the start and duration of work tasks. Tasks are allocated resources based on the schedule and estimates. Risk analysis is an orderly process of identifying, understanding, and assessing risks (any occurrence with negative consequences). Policies, procedures, tools, and techniques are specified to govern work.

Page 49

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 good people to do the work.

Page 50

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.

Page 51

ENGR2720U

Leading a Project

Direction is needed to follow plans, use resources efficiently, etc. Directing people is not enoughpeople need inspiration, help, a congenial work environment, emotional support, etc.

Page 52

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.

Page 53

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.
Page 54

ENGR2720U

Design Project Decomposition

Work Phase
Analysis: Design Problem

Typical Work Products

Statement of interested parties, product concept, project scope, markets, business goals Models (of the problem) Prototypes (exploring the problem) Client surveys, questionnaires, interview transcripts, etc. Problem domain description Lists of needs, stakeholders Models (of the problem) Prototypes (exploring needs) Requirements specications Models (of the product) Prototypes (demonstrating the product) Models (of the engineering problem) Prototypes (exploring the problem) Architectural design models Architectural design specications Architectural prototypes Detailed design models Detailed design specications Detailed design prototypes Page 55

Product Design

Analysis: Detailed Needs

Resolution: Product Specication Analysis Resolution: Architectural Design Resolution: Detailed Design

Engineering Design

ENGR2720U

Summary
Analysis is breaking a design problem down to understand it; resolution is solving a design problem.

Design processes begin with analysis and have a highly iterative resolution phase. Designers should generate many candidate solutions and expect to reanalyze and resolve the problem repeatedly. Design management is project management and hence requires planning, organization, staffing, tracking, and leadership. Iterative planning and tracking is the best way to make and revise plans during a project.
Page 56