TMP3413

Software
Engineering Lab

Lecture 07:
Designing with
Teams
Topics
 Design Principles.
 Designing in Teams.
 Design Standards.
 Designing for Reuse.
 Designing for Usability.
 Designing for Testability.
 Design Reviews and Inspections.
 The TSPi Design Scripts.
Requirements
Analysis and
Specification

Design And
Specification

Coding And
Module Testing

Integration And
System Testing

Delivery And
Maintenance
1.0 Design Principles (cont…)

Design is the creative process of deciding

how to build a product.

Software Design Specification (SDS)

WHAT IS SOFTWARE DESIGN?

It is a process by which the

software requirements are translated
into a representation of software components,
interfaces, and data necessary for
the implementation phase.
 1.0 Design Principles (cont…)

Conceptual design questions:

• Where will the data come from ?
• What will happen to data in the
system?
• How will the system look to users?
• What choices will be offered to users?
• What is the timings of events?
• How will the reports & screens look like?
 1.0 Design Principles (cont…)

Technical design describes :

• Hardware configuration
• Software needs
• Communication interfaces
• I/O of the system
• Software architecture
• Network architecture
• Any other thing that translates the require-
ments into a solution to the customer’s
problem.
1.0 Design Principles (cont…)

• Correct & complete

• Understandable
The design • At the right level
needs to be • Maintainable
1.0 Design Principles
HOW DO WE DOCUMENT OUR
SOFTWARE DESIGN?

Through Software Design

Specification or SDS

SDS shows how the software system will be

structured to satisfy the requirements.
It is the primary reference for code development
and, therefore, must contain all the information
required by a programmer to write the code.
Design & Specification

The SDD is performed in two stages.

The first is a preliminary design in which the overall system
architecture and data architecture is defined.
In the second stage, i.e. the detailed design stage, more
detailed data structures are defined and algorithms are d
eveloped for the defined architecture.
Design & Specification
 2 Sub-phases:
 Architectural or High Level Design
 Detailed or Low Level Design

 High Level: deals with overall module structure and

organization
 Component Diagrams
 State Diagram

 Low Level: high level is then refined by

 Designing each module in detail.
 Detailed Modules: Functions performed by each module.
 Solving individual problems
 Individual State Diagrams for each module.
Making of High-Level SDS
 The SRS required the system to interact with two types of
users:
 Staff
 Customers
 The staff user should be able to perform the following
operation:
 Starting and stopping ABM services.
 Refill the vault when it is low.
 The customer should be able to perform the following
operations:
 Withdraw money
 View Balance
 Transfer Money within accounts.
 Deposit money
 Also, Bank should perform the following main functions:
 Verify card and PIN number
 17 12/4/2009

Component Diagram for ABM

Power off
User Interface Staff Services
Vault Refill

Data Verification
Bank

Withdraw Transfer

Deposit
View/Print
Transactions Group 302
 State Chart Diagram
18 12/4/2009

System ON or
Exit = False
WELCOME SCREEN

Verify pin

Data Verification
UI
Deposit OR Withdraw OR Transfer OR View

Customer
Transaction complete

Print Receipt

VAULT Balance Staff No

Yes

E: refill
Vault

Vault >10000 Power Off

BANK

Group 302
Exit = True
 19 12/4/2009

High-Level to Low-Level SDS

 Listed activities and entities
 Split up similar activities (functionalities)
 High Cohesion, Low Coupling
 Address functions and respective
variables
 Classes
 Real life modularity

Group 302
 2.0 Designing in Teams
 When we design a product by ourselves, the
principal questions concern;
 how to produce the design and
 the order in which to design the product’s
various parts.
 Questions that arise when working in team:
 Who should design each part?
 In what order should they do the work?
 How do the parts fit together?
2.1 Using the Entire Team
A common problem in designing large
software systems is the need to define the
overall system structure before we can specify
anything else. How?
 have the entire team work together on the
overall structural design
 identify other tasks that the rest of the team can
do while one or two of the engineers define this
structure and specify the system’s components
in enough detail
2.2 Design Studies
 start with some preliminary ideas about product
components and their functions.
 These ideas are generally defined during the
team’s initial brainstorming design session
 Then, while the system designers are producing
the external component specifications, other
engineers could think about alternative ways to
design components
 The user interface is another function for which
prototyping is often worthwhile.
 One or two engineers could build a simple user
interface and possibly even test it with typical
users.
2.3 Using All the Team’s Talent
 Another issue in team design concerns the
effective use of all the members’ ideas.
 A principal benefit of teams is their potentially
powerful range of skills and knowledge
 The most critical problem in teamwork - to get all
the members to fully contribute.
 When people work in groups, they are occasionally
reluctant to speak up or to offer suggestions and
ideas
 All the team members should be aware of this
problem and should recognize that the team has a
wide variety of experience and knowledge
3.0 Design Standards

Many Types of design

standards
• Naming convention
• Interface formats
• System and error messages
• Defect standards
• LOC counting
• Design representation
standards
3.1 Design Representation Standards

 important because the team must frequently

determine whether or not it has a complete
design-for example, at the start of every
design review or inspection
 Without clearly understood and agreed-on
standard, engineers often cut corners.
 Save implementation time and reduces a
reviewable design that verified before
implementation.
3.2 Use-cases or PSP Operational
Scenarios
 scenario- a sequence of input actions and the
system responses that result from each of these
actions
 can also be used to define test conditions.
 During high-level design,
 produce scenarios that specify the test sequence
for every one of the program’s key functions.
3.3 State Machine Analysis
 help to uncover complex and hard to
detect logical issues and problems
 important when programs are being
enhanced in several development cycles
 It is a good idea to define and analyze the
program’s state machine behaviour
3.4 Producing Precise Designs
 important in team projects because superficial
designs frequently have basic logical problems
that no individual engineer can see
 These problems are generally hard to
diagnose during tests and sometimes they
cannot be fixed without reworking major
portions of the implementation
4.0 Designing for Reuse
 Identify common functions and propose an
initial set of reusable parts.
 Team achieve higher reuse levels and
increase productivity
 Save engineering time in the first
development cycle.
 Reuse at the beginning at the beginning of
a project for a small TSPi products and reuse
during requirement and strategy
development for large scale project.
5.0 Designing for Usability

 Usabilityis a large subject that warrants

an entire book and course of its own
 One way to make products usable is to
produce scenarios for every key user
function
 Then analyze the scenarios and make
sure that they reflect the kind of system
we believe the users will want
6.0 Designing for Testability

 Itis also important to do a through job of

test planning. When teams properly plan
their integration and system tests, they
generally find more defects during test
planning than they do during the actual
testing
 There are two general kinds of testing:
black bow and white bow testing
6.1 Black box Testing
 Testing at the system level requires no special
provisions because these tests simulate the way
users are supposed to use the product
 Tests verify the program’s external specifications
and do not consider the program’s internal
structure
6.2 White box Testing
 Consider the program’s logical paths and
structure
 Requires some thought during design.
 Here, the problem is to provide a
capability to test every aspect of the
program’s structure
6.3 Black box Testing vs. White box
Testing
 Bothkinds of tests are highly useful and
should be used
7.0 Design Review and
Inspections
 Design review an be very effective in
improving the quality of the software designs.
 Stages for effective design inspection;
 well documented design
 do thorough design analysis
 check each design element (eg.: interfaces,
loop initiation, stepping, and termination; and
analyze state behaviour)
7.0 Design Review and
Inspections (cont…)
 Inspection s are valuable for much more than
finding defects.
 An experienced and capable inspection
team often sees requirements and design
issues.
 The more people involved in an inspection,
the more engineering time it will take.
 If you have the time, use more reviewers.
8.0 The TSPi Design Scripts
 TSPi design scripts DES1 and DESn are
similar axcept DES1 script describes the
design steps for development cycle 1,
whereas DESn describes the subsequent-
cycle design steps.
Reference
 SoftwareEngineering (3rd ed.), By K.K
Aggarwal & Yogesh Singh, Copyright © New
Age International Publishers, 2007