* Object Oriented Project Management
@ 1991-06-19 17:38 Ronald Schultz
0 siblings, 0 replies; only message in thread
From: Ronald Schultz @ 1991-06-19 17:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~1991-06-19 17:38 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1991-06-19 17:38 Object Oriented Project Management Ronald Schultz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox