W06-T&M-I L1

For every complex problem, there are millions of simple, wrong answers.

The Silver Bullet Complex

• A tool or method will make a dramatic "order of magnitude" difference in productivity.

Waterfall lifecycle

• General Structure

• Analysis Phase (what)
• Design Phase (how)
• Implementation Phase (coding)
• Testing Phase

• Benefits of Waterfall

• Simple
• Predictable
• Easy to Schedule

• Problems with waterfall

• Makes too many unrealistic Assumptions
• Does not manage complexity well
• Process is inherently unpredictable. Saying it is predictable doesn't make it so.
• Lacking feedback between the phases
• Tests for "correctness" are deferred until the end of the project

Iterative and Incremental Development

• General Structure

• Integration of Analysis, design, implementation and testing

• Benefits of Iterative and Incremental Development

• Early rather than late mitigation of high risks (technical, requirements, objectives, usability, and so forth)
• Is evolutionary. Does not require stable requirements
• Early visible progress
• Early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders

o Managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and complex steps

o The learning within an iteration can be methodically used to improve the development process itself, iteration by iteration

• Problems with Iterative and Incremental Development

• Difficult to manage
• See as chaotic
• Used as an excuse when people are being lazy

· Warning: Superimposing Waterfall on Iterative

o Most of the requirements are written before development begins

o Attempt to create many thorough and detailed specifications or UML models and designs before programming

· How to do Iterative and Evolutionary Analysis and Design?

o Before iteration-1, hold the first timeboxed requirements workshop, such as exactly two days.

§ On the morning of day one, do high-level requirements analysis

§ Ask the chief architect and business people to pick 10% from this high-level list (such as 10% of the 30 use case names) that have a blending of these three qualities:

· 1) architecturally significant

· 2) high business value

· 3) high risk (such as "be able to handle 500 concurrent transactions"). UC2, UC11, UC14.

§ For the remaining 1.5 days, do intensive detailed analysis. When finished, 10% are deeply analyzed, and 90% are only high-level.

o Before iteration-1, hold an iteration planning meeting in which a subset from UC2, UC11, and UC14 are chosen to design, build, and test within a specified time

o Do iteration-1 over three or four weeks.

§ On the first two days, developers and others do modeling and design work in pairs, sketching UML-ish diagrams at many whiteboards, coached and guided by the chief architect.

§ Then the developers take off their "modeling hats" and put on their "programming hats."

§ Much testing occurs: unit, acceptance, load, usability, and so forth.

§ One week before the end, ask the team if the original iteration goals can be met; if not, de-scope the iteration, putting secondary goals back on the "to do" list.

§ On Sunday of the last week there's a code freeze; all code must be checked in, integrated, and tested to create the iteration baseline.

§ On Monday morning, demo the partial system to external stakeholders, to show early visible progress. Feedback is requested.

o Do the second requirements workshop near the end of iteration-1. Then pick another 10% or 15% of the use cases that are architecturally significant and of high business value, and analyze them in detail for one or two days. When finished, perhaps 25% of the use cases and non-functional requirements will be written in detail.

o On Thursday morning, hold another iteration planning meeting for the next iteration.

o Do iteration-2; similar steps.

o Repeat, for four iterations and five requirements workshops, so that at the end of iteration-4, perhaps 80% or 90% of the requirements have been written in detail, but only 10% of the system has been implemented.

§ Note that this large, detailed set of requirements is based on feedback and evolution, and is thus of much higher quality than purely speculative waterfall specifications.

o We are perhaps only 20% into the duration of the overall project. In UP terms, this is the end of the elaboration phase. Because of the significant realistic investigation, feedback, and early programming and testing, the estimates of what can be done and how long it will take are much more reliable.

o After this point, requirements workshops are unlikely; the requirements are stabilized though never completely frozen.

Predictive Process models

• Aimed at applying engineering principles in an attempt to make software development more predictable and efficient.
• Like a recipe.
• Tend to be beaureaucratic and documentation centric
• Based on the notion that the majority effort is spent on construction
• Treat people as a second order effect (ie. it doesn't matter whom pours the concrete)
• Tend to be resistant to change
• Tend to be based on Waterfall lifecycle

Adaptive (Also called "Agile" methods)

• In response to the beaureaucracy and complexity of Predictive Process models
• Tend to be more resilient to change
• Tend to be less documentation centric
• Regard people as a first order effect
• Tend to be iterative and incremental
• Different perspective on Software development:

• In software: construction is so cheap as to be free
• In software all the effort is design, and thus requires creative and talented people
• Creative processes are not easily planned, and so predictability may well be an impossible target.
• We should be very wary of the traditional engineering metaphor for building software. It's a different kind of activity and requires a different process