unexpected behavior—what questions are being asked, and occasionally crashes in the system that probably upset the FR quite a bit. Another problem that I’ve heard is the relatively small amount of use of development artifacts, software artifacts. And that doesn’t mean only pieces of code but also the tests—whatever the test suites are, along with the documentation. And then, finally, we’ve heard that there’s very little time to produce documentation.

So all of these problems are common in many software projects, and there are a couple of principles that we might pursue in finding a solution to these problems. They are also becoming more widespread generally in software development. One of them is to integrate the process—the development process itself. That is, how people actually go about developing software. And the concepts here are that we want to have close involvement at all stages of the lifecycle by all the stakeholders in the process (or at least in the product). And perhaps that bias comes from my own previous position, working as a product manager, where I had to be sure that all the stakeholders were in agreement from the very beginning. But actually we can do a lot more here than what I was able to do.

Another concept that’s important here is iterative development, and a number of people have mentioned this before. We don’t want to have—particularly if there’s a hard deadline—everybody spending a lot of time initially doing requirements analysis and then, you know, design and implementation. And then, at the end, we find that we send it over the fence and the customer rejects it because of a requirements issue that could have been found much earlier in the process. So, we should have iterative development, with small iterations where each iteration produces a useable—or at least a testable—product. And that concept hascomeupherebefore.

Well, what we haven’t discussed is a particular methodology that in-corporates these concepts. And there are others as well; I don’t mean to be advocating this particular one. This is a an example, and you should look at its strengths and its weaknesses before you get into it.

The other principle is integrated tools. We should try—the two ideas here are first, that, during the lifecycle we produce many software artifacts. Requirements, specifications, test cases, code, design, and so on. We should formally try to capture them as much as possible. And then what we can do is use automated reasoning techniques to derive the next level from the previous level—[to] help go from the specification to the implementation, for example.

So, let’s take a little bit of time to look at the interesting aspects of “extreme programming” (XP). This is a style of development that’s particularly suited to program domains with changing requirements. And