Fayad & Laitinen/TransitionOOChapter 13Defining and Documenting the Development Process13.1 The Manager's Roles and Responsibilities in the OO Software ProcessThroughout this book we have been emphasizing the link between OO and controlled development. OO techniques by themselves do not include progress reviews, extensive documentation, or bi-directional requirements traceability althoughsuch features are necessary to make any significant development successful. To address such topics, we need detailed, repeatable documentation that can guide and control our work. The process is the fundamental way of implementing that control. A process is a description of the steps required to implement some goal, usually part or all of a method. Processes transform textbook theories and method descriptions into real action steps. Documented processes enable the development team to consistently apply and benefit from the application of OO techniques. It is essential torealize that processes are codified steps that describe a particular organization's way of achieving development goals. This means that processes cannot be acquired off the shelf, but must rather be developed over time [Fayad97a]. As shown in Figure 13.1, detailed processes are dependent on the application area, object-oriented methods, tools, and languages in use.Figure 13.1: General Processes Must Be Tailored to Your Projects.Fayad points out that “Management must support the move to process-based development. This implies that process must not be abandoned when schedule pressures loom or process costs initially slow some development phases. Processes are especially important for new object-oriented development teams. Even in a well-organized group, new methods and tools introduce confusion. Individuals will often perceive themselves as less skilled than before and the routines they had established with others will certainly change. Management must make sure that establishing process-oriented development will allow team members to contribute positively. It is management's job to show how processes will help achieve the overall goals of the organization and how each team and its members fit into the big picture. But perhapsthe hardest challenge management has in promoting processes is to make sure that people do not view processes as weapons to be used against them. Promoting this view requires a change in management's thinking from the individual as the basic unitto the team, and from individual performance measurement to process measurement.Process measurement will highlight problems and errors in the process. If these measurements are used for performance reviews rather than process improvement indicators, the process is doomed to fail” [Fayad97a].13-1Fayad & Laitinen/TransitionOO13.1.1 Measure Processes rather than PeopleProcess orientation has developed a somewhat tarnished reputation because of the way it has been implemented. The goals of process orientation are to improve reliability and efficiency, thereby increasing quality. Too often, organizations try to "install" quality by the use of techniques such as processes. With the increased emphasis on process as technique, problems may arise [Laitinen98]. Process paralysis and losing sight of the goal of creating products are common traps. Attempting to use off the shelf processes, devaluing skill and experience in favor of processes, and putting "experts" in the position of defining and imposing processes allcontribute to the failures that have damaged the reputation of quality management. Having installed processes, some clever management types often decide to "speed" things up by setting goals above the current statistical average for processes. This is destructive. The only way to improve goals is to change the process. Processes are tools that, if done with a sincere organization-wide approach, can help improve work quality and increase productivity [Laitinen98].If management succeeds in creating a process-oriented approach, the next logical step is to base management on the use, improvement, and measurement of processes. This is a radical step, and we cannot do full justice to the idea in this shortsection. We refer the reader to sources that expand upon this idea [Deming 86; Latzko 95; Senge 90]. We lay out the basic idea by reiterating that effective development is a team effort. Just as the misuse of process data will cause people to subvert error reporting, a system of processes that allow one part of the system to succeed at the expense of another will also be destructive. Processes help organizational systems run effectively, and to do that, processes cannot be viewed in isolation. When we suggest a different approach to managing people and processes, we do not mean that traditional issues such as absenteeism and personal responsibility should be ignored. Rather, by focusing on the process, a fairer evaluation of people can be made. And since coordinating people to reach a goal thatcannot be met by individual action is one of the prime tasks of management, measuring processes is an excellent measure of management itself [Laitinen98].13.2 The Top Five Excuses for No Process DocumentationProcess orientation is hard to adopt. Processes are commonly seen as extra bureaucracy that only serves to make a project less effective. In far too many cases, this perception is correct, and process adoption is resisted. Even if the organization is sincerely committed to adopting a process oriented approach, many excuses will be offered at first. We list a few in Figure 13.2 and discuss them in detail in [Fayad97a]. Many others will require much effort to overcome. While there may be some truth in the excuses, they are still excuses rather than valid reasons for lack of documentation. The emphasis must be made to move forward.Figure 13.2: Top Five Excuses For No Process Documentation13-2Fayad & Laitinen/TransitionOOOur short answers for the above listed excuses are that undocumented procedures are not scalable or transferable. Using repeatable processes reduce avoidable mistakes, and free developers up for more creative, less routine work. Processes are meant for the people who implement and use them. Other uses are usually, and rightly, considered busywork, and such processes will end up buried on shelves, unread and unused. There is no ideal time to start implementing processes, but documenting processes while performing them gives