Improving DesignImproving Design

#1 Reduce complexity

- narrow-down the project scope

- optimize underlying process

- eliminate unneeded parts

# 2 Find and eliminate redundancies

Design by ContractDesign by Contract

In principle a detailed technical spec should contain a precise description of what the inputs and outputs of the system should be, hence the spec can be viewed a as contract specifying what the system should do.

Contract ApproachContract Approach

1) Supplier

2) Client

3) Preconditions (requirements)

4) Post-conditions (guarantees)

5) Consistency constraints (safetry checks)

Dictionary ExampleDictionary Example

1) Supplier: provides source data to be inserted into dictionary

2) Client: inserts data into the dictionary3) Preconditions: the client requires source

data to be available for reading; the supplier requires the dictionary not to be full.

4) Post-conditions: the client ensures that the dictionary is not full; the supplier ensures that there is source data.

5) Consistency constraints: source data + dictionary size = const.

Fault TreesFault Trees

Display logical path from effect to cause.1) Think of what can go wrong;2) Trace how events unfold and build a

graph whose nodes are failures;3) Graph edges represent related

components labeled by logical relationships (AND/OR).

Once the graph is constructed we can improve design by searching for:

- single points of failure- Undefined or ambiguous behavior

Fault Tree ExampleFault Tree Example

Comparing DesignsComparing Designs

Criteria for comparison:1) Implementation cost2) Ease of algorithms change3) Ease of data structure changes4) Ease of functionality expansion5) Performance6) Reusability7) Maintainability

Design ReviewDesign Review

1) Preliminary review of conceptual design: uncovers design traits that are unacceptable to customer

2) Critical review of technical design: cross-examination of the design by developers, testers, hardware & network administrators, analysts, and customer reps uncovers design deficiencies.

Questions to AskQuestions to Ask

1) Does the design solve the problem?2) Does design address all the requirements?3) Is the design easy to understand?4) Can the design be improved / simplified / optimized?5) Does the design allow for feature expansion?6) Is the design compatible with available (target)

hardware?7) Is the design compatible with available (interfacing)

software?8) What upgrade path does the design support?9) What maintenance issues arise from the design?

RefactoringRefactoring

Bad design requires extensive refactoring, i.e. patching to accommodate unforeseen or neglected issues.

As a result the system may fail and require redesign due:

- to inadequacy of the original design- gradual degradation of design due to

refactoring

Bad Design TraitsBad Design Traits

Also caused by refactoring…- Reduced performance- Loss of clarity / elegance- Increased complexity- Increased development time (deadline

risks)- Increased maintenance costs (both passive

and active)- Increased bug introduction probability- Reduced faith in the system

Why We Need Open SourceWhy We Need Open Source

Proven fact #1: peer review increases software quality.

Proven fact #2: we need source code to fix bugs that we’ve discovered.

Proven fact #3: we need source code to figure out poorly documented features and side-effects.

Commercialization IssuesCommercialization Issues

- Potentially cheaper software (thanks to unpaid development)

- Potentially higher code quality (thanks to peer review)

- Potentially surviving software (not linked to vendor fortunes)

- Potentially a disaster?(no support & accountability)

Commercialization ParadigmCommercialization Paradigm

You can’t sell open-source software, but you can make money on it anyway!

How?

Assume responsibility / accountability and sell support (as well as assurance)!

Commercialization DownsideCommercialization Downside

Intellectual property (IP) transfers into public domain.

Good bye to trade secrets.

Forget your software patents.

One has to strike a balance between open and closed source.