From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00,INVALID_DATE, TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!mips!decwrl!pa.dec.com!decuac!grebyn!schultz From: schultz@grebyn.com (Ronald Schultz) Newsgroups: comp.lang.ada Subject: Object Oriented Project Management Keywords: OO management Message-ID: <1991Jun19.173837.20340@grebyn.com> Date: 19 Jun 91 17:38:37 GMT Organization: Grebyn Corporation List-Id: 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