schultz@grebyn.com (Ronald Schultz) (06/18/91)
I posted a net query approximately two weeks ago requesting people's comments and experiences on differences they noted in managing OO development efforts vs. non-OO efforts. I received very few replies, but in general these replies noted that from a project management standpoint few replies noted any significant differences except in terms of the technology employed. Some commented how naming standards changed, and some metrics changed, but the general consensus was that project management is project management, and that OO had little impact. I contend that the project management aspects of object- oriented software development is significantly different than that proposed from many other software development approaches in the domain of MIS shops (those organizations that develop applications for use in their corporations, such as financial or inventory applications). For example, the state of the art in MIS software development is Information Engineering (IE). This methodology, developed by Clive Finkelstein and others in the late 70s and popularized by James Martin in the late 80s has taken by storm the MIS marketplace. A Computerworld article noted that experienced "Information Engineers" are in so much demand that they received 10-20% more salary than their non IE experienced peers. Information Engineering is the methodology of choice for many Fortune 1000 MIS shops. For those of you unaware of what Information Engineering is, IE as defined by Martin is: 1. An interlocking set of formal techniques in which business models, data models, and process models are built up in a comprehensive knowledge base and are used to create and maintain information systems. 2. An interlocking set of automated techniques which apply structured planing, analysis, and design to the enterprise as a whole rather than to merely one project. 3. A methodology that creates a corporatewide architectural framework for information systems. 4. An interlocking set of computerized techniques in which enterprise models, data models, process models, and system designs are built up in an encyclopedia (knowledge base) and used to create and maintain more effective DP systems. 5. An enterprisewide set of disciplines for getting the right informations to the right people at the right time and providing them with tools to use the information. Note the emphasis in the definition of Information Engineering (IE) on techniques, methodology, and automation. The project management of IE (as well as many other MIS directed methodologies) is based on the execution of a "cookbook" approach to software development. Cookbook software approaches are characterized by "fill-in- the-blank" forms, checklists, and volumes of procedures. Cookbooks generally adhere to the waterfall cycle of development. Cookbooks attempt to decompose software engineering into simple and very discrete activities and steps. Such approaches discount the skills, education, and training of the people by assuming that individuals can learn and execute quickly a simple set of activities. Cookbook authors assure software project management that the cookbook itself is internally consistent, rigorous, and complete, and that complete adherence to the presented approach will yield a usable result. Object-Oriented Software Engineering (OOSE), on the other hand, focuses on the application of sound and proven engineering practices to the engineering of software. These practices should include project management. OOSE is not a cookbook approach to software engineering. Although it recognizes that certain steps must be executed, it acknowledges that steps may, and indeed will need to be reexecuted to refine the results. Since I know of no OOSE Cookbook , project management must rely on experience and intuition which may be inappropriate for OOSE. This distinction between cookbook (most MIS) approaches and OOSE has numerous implications for the manager of an object- oriented software engineering effort. These impacts include, but are not limited to, changes to existing roles and responsibilities, the creation of new roles and responsibilities, and changes to the software management process itself. CHANGES TO THE SOFTWARE PROCESS - SCHEDULING ISSUES Take for example, the oft mentioned recursive and parallel nature of object-oriented software development. Berard, Booch, and others have noted that the definition of objects, subsystems, and systems can occur with a significant amount of parallelism. Also, a common theme is OO articles is the recursive technique of "analyze a little, design a little, implement a little, and test a little." How does your project manager estimate, schedule and manage such parallel activity? From a scheduling standpoint the estimating of a project is still largely a black art dependent on the complexity of the project, and how much alike the project is to previously conducted OO projects. When a candidate object is identified, the amount of effort necessary to develop the object depends upon the complexity of the object. If the object can be readily converted into code, and the object is non-critical, than the need for further analysis and design is uncalled for. Complex objects may need a number of interations to fully define them and their components. How is this effort currently planned for, estimated, and controlled in your OO projects ? CHANGES TO THE SOFTWARE PROCESS - PROJECT MANAGEMENT TOOLS From a project management tool viewpoint most project plans are currently managed using some form of a project management tool. Such tools (on a personal computer) include Project Workbench, Primavera Planner, Microsoft Project, and Claris MacProject. A Pert chart consists of a set of nodes representing activities, and directed arcs depicting the process flow through the chart. A node can not be connected to itself, or any other node that was completed prior in time to the current node. The waterfall lifecycle process software engineering model is easily represented in such tools, but the recursive/parallel process of OOSE is significantly harder to represent. Some propose planning multiple iterations of the same set of activities, but as each iteration occurs less and less time is required for the iteration. This adds an order of magnitude of complexity to managing an OO project from a project management tool perspective. For a large project, managing this additional complexity is not an insignificant cost. Some other method of representing and scheduling development activities must be created to address this issue but in the interim current tools can be used, and abused, to meet the need. (It must be noted that all too often the manager abuses the project to meet the limitations of the project management tool, rather than abusing the tool to meet the needs of the project. This is especially true of managers not adequately educated in the management of OO efforts.) What kinds of project management tools are being used to manage OO projects, and are these tools being "abused" due to the recursive/parallel nature of the effort? SOFTWARE PROCESS CHANGE - PROJECT DELIVERABLES From a deliverables aspect there appears to be a significant difference in the managing of OO development vs. other MIS approaches due to the difference in nature of the documentation developed. For example, conventional development yields systems requirements documents containing: o A Design Unit Process Model o Many Data Flow Diagrams o Many Decomposition Diagrams o Many Logical Data Encyclopedia Listings for Attributes, Processes, External Agents, Entity Types, Data Stores, Relationships, and Data Flows o A Fully Attributed E-R Model o Many Module Action Diagrams o Many Screen and Report Layouts and Data Structures o Many Data Access Models o A Set of Test Requirements o A Set of Security Requirements On the other hand, an OO effort may yield systems requirements documents containing: o Many Object and Class Specifications o Many Application-Specific Information o Many Reuseable Component Information o Possibly Many Subsystem Specification Documents o Possibly Many System of Interacting Objects Specifications o A Set of Test Requirements o A Set of Security Requirements Managing these very different deliverable sets would have a significant impact on the project management activities of estimating, controlling, and reporting progress. Completion criteria, quality assurance measures, cost and estimating techniques are all very much different in the specifics of OO development from other development. At a macro level both approaches to development yield requirements documents, but the nature of these documents is very much different. How are these different deliverable sets planned for, estimated, and managed in your OO projects? REUSE Information Engineering touts data reuse as a key benefit of its use. Data Asset Management was developed by DACOM to actually account for data as a corporate asset. Object- Oriented Engineering touts object reuse as a strategic benefit. But has anyone developed an accounting process to track "object assets"? Articles by Meyer, Cox, and others present powerful and persuasive arguments for software reuse but few specifics exist in the form of tools, training, methodology, or hard cost justifications to support MIS management in justifying reuseable software engineering or the purchase of reuseable software components. How is reuse accommodated in OO project planning and estimating? SUMMARY In summary, I still believe the project management of OO efforts is significantly different than the management of other development approaches, (e.g. Information Engineering). I will grant that management of small OO efforts is similar to other approaches; get out there and develop code! But for large efforts, involving significant resources and staff, OO project management requires significant exploration and definition. I look forward to your responses. REFERENCES Boehm, B., August 1985. A Spiral Model of Software Development and Enhancement. Software Engineering Notes, vol. 11 (4). Booch, G., 1991. Object Oriented Design with Applications. Benjamin Cummings. Ernst and Young, 1990. Navigator Systems Series Overview Monograph. Humphrey, W., 1989. Managing the Software Process. Addison Wesley. Martin, J. 1990. Information Engineering Book III, Design and Construction. Prentice Hall. Metzger,P. 1973. Managing a Programming Project. Prentice- Hall, Inc. Youdon, E. 1989. Modern Structured Analysis. Yourdon Press. Ron Schultz schultz@grebyn.com 614-798-0295
denisl@col.hp.com (Denis Lambert) (06/19/91)
Ron, Although I have done only a small amount of OOP, we do use quite a bit of iterative prototyping here, which may or may not be similar. I can comment on how the current offering of project management tools really does fit into this environment. I have not found it necessary to warp the project to fit the tool, or warp the tool to fit the project. The problem with iteration lies in its perceived definition of: keep doing something until you get it right. If this is your definition, then no project management tool or methodology will work. I prefer to look at "Objective or Goal Driven" iteration sets. By this I mean that each set of iterations should have a clear and well defined goal, such as to understand the menuing interface system or in the OO sense to design an implement class strings. The trick is to decompose the project into a series of well defined, goal driven iteration sets and to use the project management tool for what it was designed for, as an overview tool to see and control an entire project. Without having objective driven prototyping I have seen many projects prototype forever. Each prototype cycle adds to the programmers knowledge base and forms the catalyst for the creation of new ideas which require another cycle, which leads to increased knowledge, and so on. With objective driven prototyping, no cycle is started until a clear end result or goal has been established, and the cycle ends when the goal is reached. Decomposing the project into a series of these objectives fits well within the current project management models. What doesn't fit into the current PM models is what goes on within the objective, in other words the set of iterations required to achieve the end result. Current PM software is not well designed to handle micro- management. Its' main purpose is to aid the project manager in seeing and managing the total project. What I suggest is to find a project management tool that supports out-of-sequence progress and task summarization. Primavera, Prestige, OpenPlan, and a few others fill these requirements (but they may have shortcomings in other areas). With these features the objective can be described with summary tasks, and the details of the set of iterations can be the children of the summary task. The project would be planned for summary tasks to be performed in the order that they have been scheduled, while the details of the summary task will be performed in an iterative fashion. The following is an example of this hierarchy. Design and Implement Class String Design 4 weeks Code 2 weeks Test & Evaluate 2 weeks The summary task, Design and Implement Class String, would have clearly defined objectives (i.e. efficient string search, concatination, etc.). The actual process through the details would be to design a little, code a little, test a little and then repeat the process. The total amount of design would be 4 weeks even though it may be done in one four week chuck or several 2 or 3 day iterations. The same holds true for Code and Test tasks. Packages that do not allow the detail tasks to be performed in an out-of-sequence fashion while retaining the overall logic will be a nightmare in this situation. Packages such as TimeLine and MS Project fit this category. When we report project status, we report the summary task in a graphical format (Gantt Chart), and report the detail in a tabular format listing the effort remaining. Let me know what you think of this. I would look forward to additional comments. Denis Lambert denisl@col.hp.com