In the iterative approach, development is organized into a series of short, fixed-length (e.g. four week) mini-projects called timeboxes; the outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.
Benefits of iterative development include: early mitigation of high risks, be it technical, requirements, objectives, or usability; earrly visible progress; early feedback, user engagement, and adaptation. The end result is a refined system that more closely meets the real needs of the stakeholders.
Test-driven development is another key concept that goes together with timebox-based project management. In principle, test-driven development is just about writing the test before the program (what? yes, indeed this is better than testing as an after-thought). It leads the developer to firstly think about "how to use the component (why need it, what's it for?)" and only secondly about "how to implement". It results in components that are easy to test, enhance and adapt. In the end, there is no code without a test. The developer can tell at any time whether everything still works as it should, or what exactly does no longer work as it once did. Only in this way, can anyone expect to have an automated mechanism for routine (daily) testing and integration.
If you think about it, the tests are the specification in executable form. You understand the programs behavior by looking at the tests. The tests tell you more than just an API description, they show the dynamics, how to use the API. You develop just enough. There is no code without a test.There is no test without a user requirement. Once you get one test working, you know it is working now and forever. You use the tests as regression tests.
Some of you may say: "But wait, haven't we been doing all of our lab assignments since 100 level that way?" Yes, indeed. But that was made possible by Dr. Plank doing all the million-dollar work on your behalf! Think back hard, did you really understand the entire spec of a lab assignment when you were just starting a lab?
Now that you have learned about this, you know how far you are from reality. Well, that's the reason to take this course, isn't it?
As we have discussed before, a timebox represents a mini-project. So naturally, it contains the whole set of regular steps: requirement, design, implementation and tasks. The following is just a short example of an initial timebox description. As time goes on, this description will continue to be refined with more detailed and accurate descriptions.
Graphics Timebox: the basic graphics functionality to support mermaidhunter have the following requirements (just an initial draft):
Design elements: the design elements in this timebox are primiarily driven by application states, referring to the design document. The "states" determine not only the current status of the overall universe but also how each player sees the universe. In result, we can classify states into global, group, individual states.
This timebox is also concerned with loading graphics data in different formats. We will focus on one format for geometry and one format for imagery texture.
...
...
Timebox Evaluation: the description (in pseudo code, at least) of a list of tests designed right after design and before implementation goes here.
...
But take heed here please. Timebox is a "practice" that helps to manage an "agile" process. The silver bullet is still "design for change". The other way around, even you have a greatly elegant design, you still need to do the following every single day to manage an evolving project: