INFO 637 Lecture #6 1
Software Engineering Process IIDesigning with Teams
INFO 637
Glenn Booker
INFO 637 Lecture #6 2
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 3
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 4
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 5
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 6
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 7
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 8
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 9
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 10
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 11
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 12
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 13
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 14
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 15
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 16
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 17
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 18
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 19
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 20
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 21
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 22
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 23
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 24
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 25
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 26
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 standardsAllocate design tasks to team members
INFO 637 Lecture #6 27
Design Scripts
Prepare parts of the SDS separatelyPrepare the integration test plan Inspect the draft design document and
test planUpdate and agree upon the final SDS,
and prove that it is traceable to the SRS
Top Related