info 637lecture #61 software engineering process ii designing with teams info 637 glenn booker

INFO 637 Lecture #6 1

Software Engineering Process IIDesigning with Teams

INFO 637

Glenn Booker


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


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


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!)


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!


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


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


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


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


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)


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


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…


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


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


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)


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


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


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


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


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


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


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


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)


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]


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


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


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

info 637lecture #61 software engineering process ii designing with teams info 637 glenn booker

Documents

design phases

design studiesoften

design principlesdesign

low level design

rapidlyhigh level design

design standardslines

completed high level

reuseone aspect of design