View this page as series of slides through the magic of xslt.
- Overview
- What's wrong with Waterfall? (for the zillionth time)
- Iterative and Incremental Development
- Variable Scope
- Test First Programming
- History of Waterfall
(Your mother told you about this)
"Managing the Development of Large Software Systems" by Winston Royce, Proceedings of IEEE WESCON, 1970
The Dept. of Defense liked the diagram and thus MilSpec 2167 was born.
Karl Marx liked the waterfall so much he created the Five Year Plan methodology.
- Real History of Waterfall
(Your mother didn't tell you about this)
Winson Royce said the waterfall would be nice if it actually worked in the real world, but unfortunately for most systems it would not, an iterative approach would be better.
Royce's actual suggestion:
- What's Wrong with Waterfall? (for the zillionth time)
- No real progress tracking
- Too many "wasted" features put in (45% are not used)
"Since customers often don't know exactly what they want at the beginning of a project, they tend to ask for everything they think they might need, especially if they think they will only get one shot at it. This is one of the best ways we know to increase the scope of a project well beyond what is necessary to accomplish the project's overall mission." -Mary & Tom Poppendieck
- Temptation of a monolithic architecture
- Too many features not added (new or forgotten)
- Too long until it gets here (Capitol cost)
- Risky
- Customer does not see all the results til it's too late to change
1995 DoD report: 37 Billion US dollars spent on software, 75% of projects failed.
We now have hard, statistical evidence that the more closely waterfall is followed, the more likely it will fail.
- Iterative and Incremental Development (IID)
- Frequent iterative releases of production quality code. The system is not complete, but is a usable subset of the real thing the customer can use.
- Next iteration items are risk driven and client driven
- Timeboxed iterative devlopment
Scrum specifies 30 days, other methodologies 1-6 weeks. This helps to focus everyone since deliverables are due soon, not in 8 months.
- Evolutionary Requirements
- Adaptive Planning
- Close relationship with the customer
- Agile Methodologies:
- Extreme Programming
4 values: communcation, simplicity, feedback, courage. 12 practices: refactoring, testing, big room...
- Scrum:
Daily Stand-Up Meeting, 30 day iterations, demo to stakeholders, team-managed
- Crystal (Alistair Cockburn)
Tailorable to different team sizes. Empasises Frequent Delivery, Reflective Improvement, and Close Communication.
- Lean Development
Modeled on Japanese manufacturing philoshopy.
- Unified Process
If it really wants to, it can be agile.
- Extreme Programming
- Iterations
- A few features are selected for the iteration based on risk and customer priority
- Each iteration has only enough architecture for that iteration.
- Must have automated testing
- Must commit to refactoring
- Must have flexible architecture
- Must have automated build and create installer from version control
- Should have continuous integration
- An iteration is done when all the tests for the features pass
- Select Features for Next Iterations
At the start of the project each proposed feature is assigned a "story point" value. The point value reflects the difficulty of development, similiar in purpose to Albrecht's Function Points.
At the beginning of each iteration, the customer and the software team select a few features, or stories, to go into the next release.
- Track Progress
With story points we can track progress for iterations and give better estimates of future completion.
- Track Progress
A "countdown" chart is helpful to get a sense of progress.
- Lame Car Example
Suppose you want a new car in an alternate universe where cars are custom made. You live three miles from work and are tired of walking. You decide you need the following: engine, transmission, roof, heater, CD player, espresso machine, HDTV (for the kids), windows, front seat, back seat.
- Waterfall Method
In the waterfall method of car making your car, consultants from the Athena Group meet with you for four months and create a specifications document detailing everything down to the psi on the espresso machine. It will take 24,000 dollars and two years. You agree to pay them $1,000 a month. They go away and in two years return with your car.
- Iterative Approach
In the iterative model the consultants from the Nautilus Group meet with you for 2 weeks. You tell them the most important things for your car are the engine and front seat. They spec out the engine and front seat completely and jot notes about the other items. You pay them $1,000 a month. They go away for a month and bring you a drivable car with an engine and front seat with only first gear. Now you can drive the three miles to work, albeit at only 20 mph, but still it's better than walking.
The Nautilus consultants ask what are your highest priority needs now. It's winter time and you are tired of being cold and wearing your raincoat, so you tell them a roof and windows. Two weeks later they return and install the roof and windows. They ask you what is most important to you now. You tell them. This process repeats itself with the Nautilus consultants.
After a year and a half you have everything you need except the espresso maker and the HDTV. You think about it and decide you don't really need them and would rather have air conditioning.
- Waterfall Method
- Variable Scope
Why not have all requirements specified?
The customer really doesn't know all the requirements and the needs will change.
Pick the top requirements and spec out in medium detail. Make high level notes on the rest, but don't do complete requirements gathering. (Just in time requirements?)
Your mother said to design the database and classes with all the features in up front. If you are going to be multilingual, design everything to be multilingual. If you have to support multiple currencies, do that up front.
Building all the infrastructure up front does not gain you as much as you think. Putting extra features in later is much easier than supposed if you have a flexible architecture. It does not cost 10x for each step of the waterfall for new features.
- Testing
- Programmers write unit tests before coding module
- QA and customer write functional tests in high level language or tables in something like fit or fitnesse.
- You only have automated tests
- The way we write code must change so the code is more testable
- QA does detailed requirements analysis at the beginning or just before the iteration starts
- Quality Assurance team is not insanely busy on the four days between code complete and shipment, but is comfortably busy all during development. QA clarifies requirements by working with the customer and converting needs into executable tests like tables of inputs and expected outputs.
- Test Driven Design can produce much better architecture than standard design practices
- Problems with Iterative and Incremental Development
- Only works with certain types of projects, not very well with large teams
- Creating and maintaining all those tests is expensive
- Testing GUIs is hard
- Review
The trend in software process design this year is
- Develop software in timeboxed iterations containing the next most important features
- Variable Scope: Constantly adjust the features into the next release
- Test relentlessly with automated, executable tests