Lecture
Software development still remains an extremely labor-intensive undertaking; to a large degree it continues to resemble the building of cottages more than the industrial construction of buildings . The report by Kishida et al. testifies that even in Japan, at the early stage of projects, developers "still largely rely on an informal approach - pencil and paper" .
The situation is aggravated by the fact that design is by no means an exact science. Consider database design, one of the technologies that preceded object-oriented design. As Hawryszkiewycz observes: "Although everything looks simple and clear, an appreciable amount of personal judgment about the importance of various objects in the enterprise is inevitably mixed in. As a result, the design process is not reproducible: different designers may create different models of the very same enterprise" .
From this one may conclude that no matter how sophisticated and theoretically well-founded a design method may be, practical considerations cannot be ignored. This means that we must take into account managerial experience in such areas as staffing, release management, and quality assurance. For the technologist this is exceedingly dull material, but for the developer these are the realities of life that must be dealt with in order to create complex software systems. And so, in this chapter we take up the practical issues of object-oriented development and the influence of the object model on management.
7.1. Management and Planning
If in our design we rely on the method of iterative development, then what matters most is having strong leadership capable of managing the course of the project and directing it. Too many projects have gone astray because of an inability to focus on what is essential, and only a strong management team can do anything about this.
Risk Management
Ultimately, the chief responsibility of the software product manager is the management of both technical and nontechnical risk. Technical risk for an object-oriented system lies in resolving such problems as the choice of a class inheritance structure that provides the best compromise between the usability and the flexibility of the software product. A serious decision must also be made when choosing mechanisms for simplifying the architecture and improving efficiency. Nontechnical risk comprises such matters as monitoring the timely delivery of software products from third-party firms, or regulating the relationship between the customer and the developers, which is necessary in order to determine the real requirements for the system during the analysis phase.
As was described in the previous chapter, the micro process of object-oriented development is unstable by its very nature and requires active management and concentration of effort. Fortunately, there exists a macro process of development that puts forward a number of concrete requirements and characteristics. The project manager, by studying the correspondence between requirements and actual results, can assess the state of development and, if necessary, redirect the team's resources. The evolutionary essence of the macro process of development means that problems can be recognized early in the life cycle and the risk associated with them can be thoughtfully addressed before the project is put in jeopardy.
Many kinds of software development management activity, for example task planning and walkthroughs, are not provided for by object-oriented technology alone. However, in managing an object-oriented project the tasks laid out and the results examined are not quite the same as in other systems.
Task Planning
Regardless of the size of the project you are engaged in, it is useful to hold a meeting of all developers once a week to discuss the work completed and the activities for the coming week. Some minimum frequency of meetings is necessary in order to foster communication among the members of the team. On the other hand, meetings that are too frequent reduce productivity and are usually a sign of having lost one's bearings. Object-oriented development requires that developers have sufficient time for reflection, for introducing innovations, and for informal communication with colleagues. Team managers must also allow for this unstructured time in the plan.
The meetings that are held provide a simple but effective opportunity for smoothly adjusting the plans of the micro process and for recognizing dangerous situations that have appeared on the horizon. The result of such a meeting may be a small correction in the distribution of work that ensures the stability of the process: no project can afford to have even one of its developers sitting idle, waiting for other members of the team to put their part of the architecture in order. This is especially true for object-oriented systems, in which the architecture is represented by a set of classes and mechanisms. A project can stall if the developers simply cannot manage to sort out one of the key classes.
Task planning is connected with building the schedule for delivering the results of the macro process. In the intervals between successive releases, the team managers must assess the difficulties threatening the project [Gilb observes: "if you do not attack the risks, the risks will attack you" ], concentrate resources in order to resolve the problems that have arisen, and then take up a new iteration of the micro process, which must result in a stable system satisfying the scenarios planned for the new release. Task planning at this level very often turns out to be unsuccessful because of overly optimistic schedules . Development that was regarded as "just a matter of programming" stretches out over many days of work; schedules are thrown in the wastebasket when a developer working on one part of the system assumes certain protocols for other parts of the system and then receives classes that are incompletely or incorrectly built. Mortal danger can be posed by suddenly discovered errors in the compiler, or by the program's failure to fit within the prescribed execution time. Both of these often have to be overcome by sacrificing tactical decisions made earlier.
The key to not succumbing to overly optimistic planning is the "calibration" of the team and its development tools. Typical task planning proceeds as follows. First the manager directs the developer's energy toward specific parts of the system, for example toward designing the classes for the interface with a relational database. The developer analyzes the effort required and estimates the time to completion, which the manager takes into account when planning that developer's other activities. The problem is that these estimates are not always realistic: they are usually made assuming the most favorable case. One developer may agree to solve the task in a week, while another will ask for a month for the very same task. When the work is actually done, it may turn out that it took three weeks of working time from both developers: the first developer underestimated the effort (a common problem with many programmers), while the second developer estimated the real effort more accurately (for example, because he understood the difference between actual working time and calendar time, which is often filled with a multitude of nonfunctional activities). Thus, in order to develop schedules that the team can have confidence in, managers need to introduce a kind of "calibration coefficient" for recomputing the time estimates declared by developers. This is not a sign that managers do not trust the developers, but simply a recognition of the fact that most programmers are focused on technical problems rather than on planning tasks. The manager must help developers learn to plan - but this is a skill that can be acquired only through experience.
The object-oriented development process helps to bring out explicit principles of calibration. The method of iterative development makes it possible, at the beginning of the project, to find a multitude of intermediate points that team managers could use for accumulating data about each developer's achievements, for setting work schedules, and for planning meetings. With evolutionary development, team leaders will over time gain a better understanding of the real productivity of each of their developers, and developers will be able to learn to estimate the volume of the work ahead more accurately. The same conclusions apply to tools as well: architectural releases early in the project stimulate the use of development tools that help to check structural constraints in a timely manner.
Walkthroughs
Walkthroughs are a generally accepted practice that every development team ought to use. Like task planning, software walkthroughs were introduced independently of object-oriented technology. However, in walkthroughs of non-object-oriented systems, attention is directed at other things.
The manager must conduct walkthroughs at a reasonable frequency. With the exception of the most critical and error-prone places, it is simply uneconomical to check every line of the program. Consequently, the manager must direct the limited resources of the team toward examining problems that are dangerous to the development strategy. For object-oriented systems this means greater formality in conducting walkthroughs of the scenarios and of the system architecture, and a less formal review of tactical decisions.
As described in the previous chapter, scenarios are the primary result of object-oriented analysis. They must express the required behavior of the system in terms of its function points. Formal walkthroughs of scenarios are conducted by the team's analysts, together with domain experts or end users, with the possible participation of other developers. It is better to conduct such walkthroughs throughout the entire analysis phase than to wait for a single global walkthrough at the completion of analysis, when it will already be too late to do anything useful by redirecting the analysts' efforts. Experiments show that even nonprogrammers can understand scenarios presented in the form of text or object diagrams [We have encountered the use of this notation in the work of such nonprogramming groups as astronomers, biologists, meteorologists, physicists, and bankers]. Ultimately, the walkthrough helps to develop a common vocabulary for the developers and the users of the system. Involving other members of the team in the walkthrough helps them to grasp the real requirements for the system in the early stages of development.
The architecture walkthrough must encompass the entire system, including its mechanisms and class structure. As with scenario walkthroughs, the architecture walkthrough (by the architect or by other designers) must be carried out throughout the entire project. At first the walkthrough is focused on general architectural decisions, and later it may be centered on certain class categories or specific mechanisms. The main purpose of the walkthrough consists in validating the architecture early in the life cycle and developing a shared view of it. A secondary purpose is the search for recurring patterns of classes or interactions, which may then be used to simplify the architecture.
An informal walkthrough should be held weekly. At it, certain groups of classes or lower-level mechanisms are usually examined. The goal is to check tactical decisions; a side goal is to give senior developers the opportunity to teach newcomers.
Comments