CS 101 Introduction to Computing Lecture 24 Design

During the last lecture … • We became familiar with the various phases of

In order to understand anything, you must not try to understand everything Aristotle 3

Today’s Lecture Heuristics for System Architecting • We will try to understand the role

Heuristic Rule of thumb learned through trial & error Common sense lesson drawn from

Caution! Heuristics don’t always lead to the best results At times they even lead

System A collection of elements which working together produces a result not achieved by

System Architecture The structure (in terms of components, connections, constraints) of a product or

Heuristics for system architecting Rules and lessons learnt by system architects after long experiences

My favorite system architecting (and other relevant) heuristics --- in no particular order ---

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

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

#4 Simplify, simplify! Probably the most useful heuristics for increasing reliability while decreasing cost

Caution! Everything should be as simple as possible but not simpler Al Einstein

#5 If you can’t explain it in 5 minutes, either you don’t understand it

#6 A system will develop & evolve much more rapidly if there are stable

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

It depends! #8 It’s more important to know what the customer needs instead of

#9 If you think that your design is perfect, it is only because you

# 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

#12 Partition/repartition the problem until a model consisting of 7± 2 chunks emerges

Life is the art of drawing sufficient conclusions from insufficient premises Samuel Butler

#13 When choices must be made with unavoidably inadequate info: Choose the best available

#14 The Triage 1. Let the dying die 2. Ignore who’ll recover on their

# 15 Don’t just remove the defect; . . .

# 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

#17 Programmers deliver the same number of LOC/day regardless of the language they are

There are many more! Please post any that are familiar to you on the

In Today’s Lecture • We became familiar with the role of heuristics in design

Next Lecture: Web Design for Usability • To become able to appreciate the role

Slides: 46

Download presentation

CS 101 Introduction to Computing Lecture 24 Design Heuristics

During the last lecture … • 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 2

In order to understand anything, you must not try to understand everything Aristotle 3

1 efficiency universality

focus!

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 6

Heuristic?

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

? Heuristic Wisdom

Caution! Heuristics don’t always lead to the best results At times they even lead to the wrong ones, but mostly to results that are good-enough

system? 11

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

System Architectur e? 13

System Architecture The structure (in terms of components, connections, constraints) of a product or a process 14

? Design == Architecture

Heuristics for system architecting Rules and lessons learnt by system architects after long experiences which when followed result in sound, stable, practical systems 16

My favorite system architecting (and other relevant) heuristics --- in no particular order ---

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

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

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

Caution! Everything should be as simple as possible but not simpler Al Einstein

#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 are not Build iteratively; add features gradually

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

Customer is always right?

It depends! #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

1 3 5 6 2 4

1 8 4 2 5 7 3 6 9

#12 Partition/repartition the problem until a model consisting of 7± 2 chunks emerges

Life is the art of drawing sufficient conclusions from insufficient premises Samuel Butler

#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; . . .

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

#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

There are many more! Please post any that are familiar to you on the message board 44

In Today’s Lecture • We became familiar with the role of heuristics in design • We also discussed a few well-known design heuristics for architectural design 45

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 46