Lecture
One of the most remarkable aspects of managing object-oriented projects is the fact that in the steady state one usually observes a reduction in the resources required and a change in the schedule of their expenditure compared with traditional methods. Precisely "in the steady state." Generally speaking, the first object-oriented project undertaken by an organization will require somewhat more resources - chiefly in accordance with the learning curve that describes adaptation to any new technology. The benefits will show up in the second or third project, when the developers have gained experience in designing classes and in finding common abstractions and mechanisms, and the managers have grown accustomed to the method of iterative development.
In the analysis phase, the need for resources usually changes little with the transition to object-oriented methods. However, since the object-oriented process devotes more attention to architecture, we strive to bring in architects and other developers as early as possible, sometimes beginning architectural experiments while still in the final stage of analysis. During evolution, as a rule, fewer resources will be required, because the work will be eased by the common abstractions and mechanisms invented earlier when designing the architecture or issuing preliminary versions. Testing may also require fewer resources, because new functions are usually added to a class structure or mechanism that already behaves correctly. Thus, testing begins earlier and is a continuous and incremental activity rather than a one-time one. Integration usually requires considerably fewer resources compared with traditional methods, chiefly because it too takes place incrementally, from release to release, rather than in a single leap. Thus, in the steady state the labor costs turn out to be far lower than with traditional approaches. Moreover, if one takes maintenance costs into account, it turns out that the entire life cycle of object-oriented software is often cheaper, since the final product will most likely be of better quality and will prove more adaptable to change.
The Roles of Developers
It is useful to remember that software development is in the end carried out by people. Developers are not interchangeable parts, and the successful creation of any complex system requires the unique and varied skills of all the members of a dedicated team.
Experiments show that object-oriented development requires a somewhat different division of labor compared with traditional methods. We consider the following three developer roles to be the most important in the object-oriented approach:
The project architect is its creator, a person with a highly developed imagination; he is responsible for the evolution and maintenance of the system's architecture. For small or medium-sized systems, architectural design is usually performed by one, at most two, bright individuals. For large projects this responsibility may be distributed across a large team. The project architect is not necessarily the most senior developer, but is certainly one who is competent to make strategic decisions (as a rule thanks to extensive experience in building systems of this type). Thanks to experience, developers know intuitively which general architectural patterns are appropriate in a given problem domain and which efficiency problems arise in certain architectural variants. Architects are not necessarily the best programmers, although they must be able to program. Just as building architects must understand construction, it is imprudent to hire a software architect who is not a decent programmer. Project architects must also be well versed in the notation and in the organization of the object-oriented development process, because they must ultimately express their architectural vision in terms of clusters of classes and interacting objects.
It is very bad practice to hire an architect from outside who, figuratively speaking, rides in on a white horse, proclaims architectural principles, and then makes off somewhere while others try to cope with the consequences of his decisions. It is far better to involve the architect in active work already during analysis and to keep him on for as long a period as possible, even for the entire evolution of the system. Then he will become familiar with the real needs of the system and will in time experience the consequences of his own decisions for himself. In addition, by keeping responsibility for architectural integrity in the hands of one person or a small team of developers, we increase the chances of obtaining a flexible and simple architecture.
The subsystem leads are the chief creators of the project's abstractions. They are responsible for designing entire class categories or subsystems. Each lead, in collaboration with the project architect, develops, justifies, and coordinates with the other developers the interface of his class category or subsystem, and then heads up its implementation, testing, and release throughout the entire evolution of the system.
The subsystem leads must have a good knowledge of the notation and of the organization of the object-oriented development process. They usually program better than the project architects, but do not possess the latter's extensive experience. Subsystem leaders make up from a third to a half of the team's headcount.
The application programmers (engineers) are the most junior participants in the project. Two duties are laid upon them. Some of them are responsible for implementing a category or subsystem under the guidance of its lead. This activity may include the design of certain classes, but is mainly connected with the implementation and subsequent testing of the classes and mechanisms developed by the team's designers. Others are responsible for writing the classes designed by the architect and the subsystem leads, thereby realizing the function points of the system. In a certain sense, these programmers are engaged in writing small programs in the language of the problem domain defined by the classes and mechanisms of the architecture.
The engineers understand the notation and the organization of the development process, but not too brilliantly; on the other hand they are, as a rule, very good programmers who know the basic idioms and weak points of the chosen programming languages. Engineers make up half of the team or more.
The difference in qualifications poses the staffing problem for all organizations, which usually have a few strong designers and a larger number of less qualified personnel. The social benefit of our approach to staffing policy is that it opens a career path for beginning employees: young developers work under the guidance of more experienced ones. Once they have gained experience in using well-defined classes, they will be able to design classes themselves. The conclusion: not every developer has to be an expert on abstractions, but every developer can learn this in time.
Large projects may call for other roles as well. Most of them (for example, the role of the development-tools specialist) are not explicitly connected with object-oriented technology, but some follow directly from it (such as the engineer responsible for reuse):
| ® Project Manager | Responsible for managing the project's materials, assignments, resources, and work schedule. |
| ® Analyst | Responsible for developing and interpreting the requirements of end users; must be an expert in the problem domain, yet should not be isolated from the rest of the development team. |
| ® Reuse Engineer | Manages the repository of the project's materials; taking part in walkthroughs and other activities, actively looks for commonality and promotes its use; finds, develops, or adapts components for common use within a specific project or an entire organization. |
| ® Quality Assurance Engineer | Measures the results of the development process; sets the general direction (at the system level) for testing all prototypes and releases. |
| ® Integration Manager | Responsible for assembling mutually compatible versions of categories and subsystems into releases; oversees their configuration. |
| ® Documentation Lead | Prepares the documentation on the product being released and on its architecture for the end user. |
| ® Toolsmith | Responsible for creating and adapting the programming tools that facilitate the production of programs and (especially) the generation of code. |
| ® System Administrator | Manages the physical computing resources on the project. |
Of course, not every project requires all of these roles. For small projects the duties may be combined. On the other hand, for very large projects each of the roles may be handled by an entire organization.
Experience shows that object-oriented development can get by with fewer people involved compared with traditional methods. In fact, to produce a high-quality program of several hundred thousand lines in one year, 30-40 developers are sufficient. However, we agree with Boehm, who holds that "the best results are obtained when fewer developers are employed and their qualifications are higher" . Unfortunately, if in developing a project one tries to get by with fewer people than is considered necessary, one may encounter well-known resistance. As was noted in the previous chapter, such an attitude is possibly caused by the attempts of certain managers to build an empire. Other managers like to hide behind a multitude of employees, because a greater number of people means more power. Besides, in case the project fails there is someone to pin the blame on.
The application of the most sophisticated design method or of the newest tools does not relieve the manager of responsibility for selecting designers capable of thinking, and is no grounds for letting the project drift .
Comments