1. (Brainstorming Question)

Consider steps 1, 2, 3 and 4 in Section 9.1. Answer the following questions from the perspective of software development (preciseness is not a concern at the moment; the questions are meant to get you thinking about how to analyse and solve problems):

a) Which steps would you execute (and how much time would you spend on each step)

for the following kinds of projects?

 Adding/modifying functionality in an existing application.

 A project to test the feasibility of a new algorithm or model.

 A new project that has no precedence (has never been done before) in your organisation.

 Integrating third-party software into your application.

b) When working on software projects whose functional requirements are missing, incomplete or even wrong you should determine how the following heuristics are useful in getting a better understanding of what needs to be designed (see P´olya, 1990, 1990A for more discussions and examples):

 H1 Analogy: find a problem that is similar to the current problem and solve it.

 H2 Variation of the Problem: vary or change the problem to create a new problem whose solution helps you to solve the original problem.

 H3 Auxiliary Problem: reduce the scope by finding a subproblem or side problem whose solution helps you solve the original problem.

 H4 Precedence: find a problem that is related to the current problem and that has been solved before.

 H5 Diagrammatic Reasoning: can you draw a picture of the problem?

 H6 Working Backward: start with the goal and work backward to something that is already known.

 H7 Decomposing and Recombining: decompose the problem and recombine its elements in some new way.

 H8 Auxiliary Elements: add a new element to the problem in order to get closer to a solution.

 H9 Generalisation: find a problem that is more general than the current problem.

 H10 Specialisaton: find a problem that is more specific than the current problem.

 H11 Induction: solve the problem by deriving a generalisation from some specific examples.
The goal of applying these heuristics is to reduce risk and gain a clearer understanding of the problem that we are attempting to design. In general, you oscillate as it were between more general and more specialised versions of a problem. This is what can also happen in real-life software projects.

c) Consider the last software project that you worked on. Which of the heuristics in part

b) did you use – either consciously or unconsciously? Which single heuristic should you have used but did not?

d) Which of the heuristics in part

b) are addressed by the Gamma (GOF) design patterns?
We recall the definition of a design pattern (see GOF, 1995):
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.
Which of the above heuristics

a) are not addressed or subsumed by design patterns?
As a guideline, take a pattern that you are familiar with (for example, Strategy as discussed in Section 9.5) and compare it with each heuristic in turn. Can you see any relationships?