- Planning and Pre-Project, which includes activities to condition the development environment, such as changing the culture.
- Technology Insertion, which includes activities to identify and plan for the required OO resources, such as selecting the right OO technique and tools, staffing, training the team, budgeting for reuse, and dealing with legacy systems.
- Project Management, which includes activities to monitor and direct the project, such as effective project tracking and controlling, collecting software metrics, defining and documenting the OO software-development process, inspections, and documentation.
- Post-Project and Maintenance, which includes activities to provide maintenance and product support for the software, such as software configuration management.
- have clean interfaces. Clean interfaces have very little legacy code to violate the project's API. New projects automatically have clean interfaces, which is ideal. If the project is a rewrite of a subsystem in a legacy application, the APIs of that interface must be respected by the other subsystems. For example, if a significant amount of legacy code violates the APIs of the subsystem to be replaced, the design and implementation of the replaced subsystem become overly constrained, adding considerable difficulty to the OO project. This significantly increases the chance of failure.
- be large enough to be meaningful but not larger than the organization is used to handling. The development organization won't learn anything from tiny projects. Also, a small project won't convince others that the transition to OO is worth the trouble. On the other hand, if the project is larger than the organization is used to dealing with, many new problems having nothing to do with OO will increase the chance of failure.
- be supported by senior management. Projects without sufficient support may get killed for reasons that have nothing to do with OO.
- risk management,
- the scheduling and activity network,
- corrective action, and
- software development.
THE FIRST DOCUMENT. Everyone knows that a business must have a business plan before anyone talks to investors, yet we've seen millions of dollars allocated for software development projects that have no planning whatsoever.
The SDP defines each major task and estimates the time and resources required. It also provides a framework for management review and control. The organization should have a policy requiring every major software development project to have an SDP before funding is approved. This will ensure that project managers perform effective planning by developing and maintaining an SDP for the projects under their supervision. This policy is normally required in a US Department of Defense environment, since an SDP draft must be provided by the software development contractor and included as part of a prospective contractor's proposal.
In a commercial environment, the SDP should be prepared and approved by management; in a military environment, by the program manager. On commercial projects, the SDP is the contract with the project manager's management or company. On military projects, the SDP is the vehicle by which the development contractor tells the program manager how the contractor will do what was promised. The SDP is also the contract between the project manager and all software development teams.
STAYING CURRENT. A complete SDP doesn't guarantee success. Even a good one is sometimes ignored by the development team. The SDP may have been written by a consulting firm or by another group who doesn't participate in the management or development activities. Key development team members may not even know it exists.
In commercial settings, managers must enforce the SDP—which may be defined under ISO 9000 or any of the IEEE standards—and make certain product managers do what the SDP promised. In military settings, the program manager must make sure the contractor delivers the promises in the SDP—which must be defined according to military standards—and then verifies contractor compliance.
An update cycle (say, quarterly) must be established to make sure that a "living" or timely plan always exists. The vital processes of the original plan must not be eliminated while updating. In a commercial setting, this is the responsibility of management; in a military setting, it's up to the program manager. To track changes to the SDP, it may be helpful to place it under software configuration management after initial management approval.
ATTITUDE. Developers' attitudes can make or break the project. Selected team members should have two personality traits: They must be aggressive enough to push forward with new ideas, but willing to learn with a service-oriented demeanor. An uncontrolled ego will prevent even the most talented developer from making the transition to OO. This is especially true for OO because it promotes teamwork; developers cannot work in isolation.
MENTORING. Development of a large software system may require an OO mentor to ensure that the methods and tools are rigorously followed, as well as to provide follow-up training to the development team when needed. This allows OO to be "caught rather than just taught." 4
WRITING CODE. It's difficult for people to understand OO analysis and design if they don't understand the underpinnings of OO programming. We have found it helpful when all involved, even architects, spend three months programming. This can be emotionally difficult for some, but those who feel that programming is beneath them generally have an ego problem anyway. 1
SPECIALIZED SOFTWARE DISCIPLINES. After someone has fully made the transition to OO, it may be helpful to have them perform a specialized task, such as OO requirements analysis, design, design patterns, programming, or testing. Specialization leads to quality work, promotes teamwork, improves processes, and leads to the discovery of problems early in the development cycle. Rather than having one person work with a given object through all phases of the development process, give one group of developers the responsibility for OO requirements analysis and handing off the requirements product (for example, providing object interaction and state transition diagrams to other groups for design or programming).
EARLY INVOLVEMENT. The entire team should be involved as early as possible. Ideally most of the developers will be involved in the requirements analysis sessions. In addition to helping everyone thoroughly understand the system being built, bringing everyone together early helps forge the team and creates buy-in for the development process.
CURRICULUM. The curriculum shouldn't focus on OO analysis or design alone. A view of the entire life cycle should be presented, demonstrating how OO analysis, design, programming, and testing all support subsequent stages. The training should emphasize how the requirements are traced through the entire cycle, to validate and verify the user requirements and assure that you develop the right system.
A case study of similar size and complexity as the target system is helpful for spotting early indications of problems. Customers should also be included in the training if they will be participating in the development process by evaluating documents (such as the Software Requirements Specification) or participating in reviews (such as the Software Specification Review).
SPREADING IT OUT. Training can either be crammed into a 40-hour week, or it can be spread out over several weeks. For example, a requirement for 40 hours of training may be fulfilled in one week if it's totally dedicated to the training activity. The same training may be spread across two weeks on a half-time basis. Training may also be spread across 10 weeks by adding a part-time consultant.
We have both used all these combinations and have found the trainees' depth of understanding and retention rates to increase significantly when a course is spread over a longer time period. Compressing the training tends to overwhelm the trainees.
Although retaining a trainer over several weeks does cost more, this overhead can be eliminated by some creative scheduling. For example, if two 40-hour courses are planned anyway, rather than being taught in two consecutive weeks, they can be taught simultaneously over the same two-week period. That is, one course is taught in the mornings and the other in the afternoons. The instructor cost is the same as it would have been if each course were taught in a single 40-hour workweek, but the trainees have the material spread over a two-week period.
LABORATORY PARTICIPATION. Because OO techniques must be practiced, laboratory participation is mandatory. 3 Participation should be checked by the management representative responsible for the training budget.
- Software metrics. Metrics are the ruler with which to measure success or failure. Useful software metrics measure process, not people. Simon Moser and Oscar Nierstrasz report on their study of 30+ projects, which shows that using OO frameworks has a substantial effect on productivity.
- Traceability. Jean-Pierre Corriveau sketches a comprehensive OO software-development process that attempts to maximize software evolvability while minimizing problems caused by late integration. For Corriveau, traceability extends far beyond referencing back to requirements—it is central to the entire development process.
- Processes and techniques. The other four articles discuss OO management and processes and techniques, describing experiences and lessons learned.