Transcript Software Engineering Process II Designing with Teams INFO 637 Glenn Booker INFO 637 Lecture #6

Software Engineering Process II
Designing with Teams
INFO 637
Glenn Booker
INFO 637
Lecture #6
1
Philosophy
The TSP deals with the principles of
designing software, not the particular
methods used (which change rapidly)
High level design is captured using a
Software Design Specification (SDS)
Detailed, or low level design is done in
the implementation phase
INFO 637
Lecture #6
2
Design Principles
Design focuses on how to structure and
build the product
Starts once requirements have been
defined and approved
Design needs to be precise enough to
guide the developers accurately, yet not
over-specify what needs to be created
INFO 637
Lecture #6
3
Design Principles
High level design focuses on defining the
components of your product, and what
each must do
Then low level design works out how each
component will accomplish its objectives
Design is often iterative, with each
iteration getting closer to a final workable
solution (we hope!)
INFO 637
Lecture #6
4
Why Bother?
Many organizations skip or shortchange
the design phases, and jump into coding
This is akin to building a house without a
blueprint – it can be done, but you’re much
more likely to miss something important!
INFO 637
Lecture #6
5
Team Design
Biggest challenge is to create the high
level design; when the entire team’s effort
depends on having a completed high level
design from which to proceed
Often one or two people will develop initial
design concepts, then have more people
investigate them in detail
INFO 637
Lecture #6
6
Design Studies
Often several approaches are tried out
to see which one will best meet the
project’s needs
Approaches may use different system or
network architectures, programming
environments, types of subsystems or
interfaces, or be based on different COTS
(commercial off the shelf) products
Prototyping is often very helpful in
evaluating approaches
INFO 637
Lecture #6
7
Avoid Tunnel Vision
The biggest problem with design is that
people often pursue the first idea
proposed
Keep looking for other ways to solve the
problem, until you’re really convinced you
have found the best way
Prod quieter team members for their
ideas; gems are often very quiet
INFO 637
Lecture #6
8
Design Standards
Many kinds of standards can help a team
produce a product that looks like one
person developed it, instead of fifty
Naming standards are a CM tool to ensure
everyone uses the same format for
naming files, variables, procedures, etc.
Avoid differences like FileName vs. File Name
vs. filename vs. File-Name, ad nauseum
INFO 637
Lecture #6
9
Design Standards
Interface formats ensure that components
of your product communicate with each
other using the same language
Messages (both error and informational)
need a consistent format and to be clear
Defects need to be identified by their type
consistently (see Table 7.1, page 126)
INFO 637
Lecture #6
10
Design Standards
Lines of code always need to be counted
in the same manner (see Appendix A)
Design modeling needs to follow a clear
set of terminology, so its meaning is
correctly interpreted
The UML standard, for example
INFO 637
Lecture #6
11
Design Modeling
Many forms of modeling can be used to
show your product’s design
Use case diagram
Sequence diagram
Data flow diagram
Entity relationship diagram
State transition diagram
And so on…
INFO 637
Lecture #6
12
Design for Reuse
One aspect of design getting more
attention is deliberate reuse of code
or design
Designs, code, and documentation
can all be reused
Early in design, someone can look for
functions which are used by several
parts of the system – those are prime
candidates for reuse
INFO 637
Lecture #6
13
Design for Reuse
Realize that designing code for reuse
costs more initially than for normal code,
but produces higher quality code which
is easier to maintain and reuse again
Many design standards can be reused by
subsequent projects, so they don’t have
to reinvent them
INFO 637
Lecture #6
14
Design for Reuse
Large scale reuse is also possible
and encouraged
Design patterns help identify solutions to
common problems (see Erich Gamma’s
Design Patterns classic)
Entire related systems may reuse
subsystems (see SEI Product Line
research)
INFO 637
Lecture #6
15
Reuse Quality
High quality components are necessary
for reuse – otherwise, why bother
reusing garbage?
Components to be reused usually get
more complete review and inspection
cycles, and more extensive documentation
Adds to their cost, but increases usability
INFO 637
Lecture #6
16
Reuse Library
To find components for reuse, need
to have:
Some library where they are known to reside
Clear conventions for documenting their
assumptions, usage, and test cases
Reuse works best for medium or large
components – it’s often not worth finding
little or simple components
INFO 637
Lecture #6
17
Usability
Usability of your system depends on
anticipating how users will want to
perform its functions
Clear instructions, logical work flow, and
prototyping all can help improve usability
INFO 637
Lecture #6
18
Testability
Designing for testability means
recognizing that various levels of testing
will be performed (unit, integration,
system, and maybe more), and hence
we need to conduct those tests as easily
as possible
Test scenarios, test data, and test plans
all need to be created to ensure adequate
testing coverage
INFO 637
Lecture #6
19
Black vs. White Box Testing
Black box testing assumes no knowledge
of how the system was designed – tests
are to see if typical user functions can be
performed correctly
White box testing allows knowledge of the
internal design of the product – hence
tests can focus on potential weaknesses
INFO 637
Lecture #6
20
Design Reviews and Inspections
Design problems often become invisible
to the designer after missing them a few
times
Reviews and inspections can help uncover
problems and inconsistencies
Appendix C covers inspections in
more detail
INFO 637
Lecture #6
21
Inspection Methods
Many inspections methods are specific
to the type of product being examined
General methods include
Use checklists
Look at it from another person’s viewpoint
Concentrate on one way of analyzing the
product at a time
Practice inspections on paper
INFO 637
Lecture #6
22
Inspection Data
Inspections can produce much raw data
Volume of product inspected (LOC or pages)
Amount of design effort (hours)
Amount of design inspection effort (hours)
Number of defects found (in inspection, and in
other phases)
INFO 637
Lecture #6
23
Inspection Data
These data can produce metrics like:
Inspection ratio (LOC/hour or pages/hour),
equals the volume inspected divided by the
inspection time
Development ratio (percent), the inspection
time divided by the design time
Inspection yield (percent), the percent of
defects which were found as a result of the
inspection [which can’t be known immediately]
INFO 637
Lecture #6
24
Inspection Reporting (INS)
Inspections are captured using form INS
(page 343)
It captures the individual results from
the inspection (effort, and number of
defects found)
Then during the inspection meeting,
agree on the defects found
INFO 637
Lecture #6
25
Design Scripts
The initial design script is DES1 (p. 133)
Conduct high level design to identify and
name the major components
Capture the design using one or more methods
mentioned on slide 12
Define design standards
Allocate design tasks to team members
INFO 637
Lecture #6
26
Design Scripts
Prepare parts of the SDS separately
Prepare the integration test plan
Inspect the draft design document and
test plan
Update and agree upon the final SDS,
and prove that it is traceable to the SRS
INFO 637
Lecture #6
27