Improving Design #1 Reduce complexity - narrow-down the project scope - optimize underlying process - eliminate unneeded parts # 2 Find and eliminate redundancies

Design 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 Approach 1)Supplier 2)Client 3)Preconditions (requirements) 4)Post-conditions (guarantees) 5)Consistency constraints (safetry checks)

Dictionary Example 1)Supplier: provides source data to be inserted into dictionary 2)Client: inserts data into the dictionary 3)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 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 Example

Comparing Designs Criteria for comparison: 1)Implementation cost 2)Ease of algorithms change 3)Ease of data structure changes 4)Ease of functionality expansion 5)Performance 6)Reusability 7)Maintainability

Design 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 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?

Refactoring 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 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 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 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 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 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.