<Previous Lesson

Introduction To Computing

Next Lesson>

Lesson#24

Design Heuristics

During the last Lesson …

  We became familiar with the various phases of the process that developers follow to develop SW
systems of reasonable complexity
We looked at a couple of problems related to the Waterfall SW development model

Today’s Lecture

Heuristics for System Architecting

We will try to understand the role of heuristics in architectural (or high-level) design
We will become familiar with a few popular design heuristics

24.1 Heuristic

Rule of thumb learned through trial & error
Common sense Lesson drawn from experience
Qualitative principle, guideline, general judgement
Natural language description of experience

24.2 System

A collection of elements which working together produces a result not achieved by the things alone

24.3 System Architecture

The structure

(in terms of components, connections, constraints) of a product or a process

24.4 Heuristics for system architecting

Rules and Lesson s learnt by system architects after long experiences which when followed result in sound, stable, practical systems

# 1 My favorite system architecting (and other relevant) heuristics

--- in no particular order ---

#2 Given many parts of a system to be designed/built,
do the hard part 1st

# 3 All the serious mistakes are made on the very first day

# 4
Simplify, simplify, simplify!
Probably the most useful heuristics for increasing reliability while decreasing cost & time-to-build

# 5
If you can’t explain it in 5 minutes, either you don’t understand it or it does not work

# 6
A system will develop & evolve much more rapidly
if there are stable intermediate forms than if there
Build iteratively; add features gradually

# 7
Success is defined by the user, not the builder

# 8
It’s more important to know what the customer needs instead of what he says he wants

# 9 If you think that your design is perfect, it is only because you have not shown to anyone else
--- Get your designs reviewed ---

# 10
A good solution to a problem somehow looks nice & elegant

# 11
In partitioning, choose the chunks so that they are as independent as possible
Chunks should have low external complexity & high internal complexity
Organize personal tasks to minimize the time individuals face interfacing
 
# 12 Partition/repartition the problem until a model consisting of 72

chunks emerges

# 13 When choices must be made with unavoidably inadequate info:
Choose the best available & then watch to see:
whether further solutions appear faster than future problems .
If so, the choice was at least adequate .
If not, go back & choose again

# 14
The Triage
1. Let the dying die
2. Ignore who’ll recover on their own
3. Treat only those who’ll die without your help

#15 Don’t just remove the defect; correct the process that caused it

# 16
The number of defects remaining in a system after
a given level of tests is proportional to the number found during the test

# 17
Programmers deliver the same number of LOC/day regardless of the language they are writing in .
Use the Highest level Language
In Today’s Lecture
We became familiar with the the role of heuristics in design
We also discussed a few well-known design heuristics for architectural design
In Today’s Lecture
We became familiar with the the role of heuristics in design
We also discussed a few well-known design heuristics for architectural design

Next Lecture:

Web Design for Usability
To become able to appreciate the role of usability in Web design
To become able to identify some of the factors affecting the usability of a Web page

<Previous Lesson

Principles of Management

Next Lesson>

Home

Lesson Plan

Topics

Go to Top

Copyright © 2008-2013 zainbooks All Rights Reserved
Next Lesson
Previous Lesson
Lesson Plan
Topics
Home
Go to Top