Process Fundamentals
We believe that the best way to make process more attractive is to educate as many people as possible about the benefits of answering the questions we raised earlier, along with similar questions, and about the risks of failing to answer them. Building good object models is straightforward if you keep ruthlessly focused on answering the fundamentally important questions about the system you are building and refuse to get caught up in superfluous modeling issues. That philosophy lies at the heart of the ICONIX process.
The people who have to use the process, and management, are both customers of a software development process. We think of a process as a road map for a team to follow, a map that identifies a set of landmarks, or milestones, along the way to producing a quality product.
There are various paths a team can travel, depending on the capabilities and preferences of its members. But no matter which path they go down, at some point, they must reach the milestones. At these points in the process, their work becomes visible to management—during reviews of intermediate results. Passing the milestones does not guarantee a quality product, but it should greatly improve the chances.
We believe milestones for an object-oriented process should include, at a minimum, the following.
The team has identified and described all the usage scenarios for the system it's about to build.
The team has taken a hard look for reusable abstractions (classes) that participate in multiple scenarios.
The team has thought about the problem domain and has identified classes that belong to that domain—in other words, the team has thought about reusability beyond just this system.
The team has verified that all functional requirements of the system are accounted for in the design.
The team has thought carefully about how the required system behavior gets allocated to the identified abstractions, taking into consideration good design principles such as minimizing coupling, maximizing cohesion, generality, and sufficiency, and so forth.
Beyond these milestones, there are at least four other fundamental requirements of a process.
It has to be flexible enough to accommodate different styles and kinds of problems.
It has to support the way people really work (including prototyping and iterative/incremental development).
It needs to serve as a guide for less-experienced members of the team, helping them be as productive as possible without handcuffing more experienced members.
It needs to expose the precode products of a development effort to management in a reasonably standard and comprehensible form.