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

INFO 637Lecture #62 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 637Lecture #63 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 637Lecture #64 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 637Lecture #65 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 637Lecture #66 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 637Lecture #67 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 637Lecture #68 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 637Lecture #69 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 637Lecture #610 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 637Lecture #611 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 637Lecture #612 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 637Lecture #613 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 637Lecture #614 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 637Lecture #615 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 637Lecture #616 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 637Lecture #617 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 637Lecture #618 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 637Lecture #619 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 637Lecture #620 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 637Lecture #621 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 637Lecture #622 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 637Lecture #623 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 637Lecture #624 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 637Lecture #625 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 637Lecture #626 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 637Lecture #627 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