to object-oriented software development · to object-oriented software development a transition...

To Object-OrientedSoftware Development

108 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM

TransitionTo Object-Oriented

Software Development

A transition plan based on lessons learned from real-world

experience is presented and several effective managerial

practices are recommended.

bject-oriented software engineering(OOSE) introduces a software develop-ment model based upon the wayhumans think. OOSE promises remark-able benefits. It allows software compo-nents to be readily reused, potentiallysaving substantial development costs.Also, OOSE reduces the scope and sideeffects of software changes, potentiallysaving substantial maintenance costs.

In spite of these potential benefits,many software development groups still

hesitate to use OOSE. Many of these groups are fully occupied by their currentsoftware development work and fear being overwhelmed if they introduce anew development paradigm.

Other groups, interested in OOSE, do not know where to begin. “What’s thefirst step?” “How long will it take?” “Is it really worth it?” Six years ago mem-bers of various software development groups where one of the authors wasworking as a consultant asked these same questions when they decided to con-front the task of developing a large software system using OOSE. They wereconfident that they understood the benefits of object-oriented (OO) tech-niques, but they did not understand the theory behind OOSE. They lacked a

firm foundation from which to start and practicalexperience on which to build. Furthermore, many ofthese teams had never applied any formal or semi-formal techniques.

To make matters worse, these groups had addi-tional problems: their most recent developmentefforts were in most cases “inconsistent”; they wereusually behind schedule—perpetually 90% complete;they were constantly finding problems late in devel-opment and feverishly applying band-aids to plug theleaks. Fixing one problem frequently created others.Also, despite having a highly centralized decision-making organization, individually developed softwareparts still looked radically different. Programmers orsoftware engineers developed software by applyingtheir own unique process. In retrospect, the overallsoftware development process was chaotic.

The transition to OOSE is often problematic, andobject-oriented approaches to software developmentare becoming increasingly prevalent. Even thoughresearch concerning the technical aspects of develop-ing OO software is plentiful, many divergent opinions

exist. There is little guidance for OO software devel-opment managers on how to transition to OOSE.

On average, the transition of a single softwaredevelopment team to OOSE takes at least a year.Throughout this transition period, they transformtheir organization from an ad hoc, informal, orchaotic group into an efficient OO developmentteam. Some people may think the transition periodwould depend on the size of the projects, the numberof people involved, the techniques used, and so on.The project size has nothing (or little) to do with get-ting people to change how they approach softwaredevelopment for problem solutions. The people canchange only through the application of the process.It takes about a year of this sort of practice for thetransition to be complete.

During the last seven years, we have been involvedin the transitions of large software developmentteams from ad hoc, informal, and extremely chaoticto OOSE [11–14]. The transition became quickerand easier on each new project. The transition planthat is the topic of this article has been fine-tuned

COMMUNICATIONS OF THE ACM February 1996/Vol. 39, No. 2 109

Transition

O

Mohamed E. Fayad, Wei-Tek Tsai, and Milton L. Fulghum

over several subsequent OO efforts. This article pre-sents the most significant evolutionary steps, many ofwhich were not initially apparent.

The OO transition process encompasses threestages: the planning and pre-project stage; the technol-ogy insertion stage; and the project management stage.

Planning and Pre-Project Activities The planning and pre-project stage encompasses twomajor activities: effective development planning andchanging the existing culture.

Effective Development Planning Before a project begins, we must make key decisionsthat can make or break the project. The current soft-ware development processes and our personnel mustundergo a calculated change. What activities shouldwe perform before the project begins? How do wechange from ad hoc, informal, or chaotic proceduresto OO techniques?

Thorough preparation and planning will greatlyincrease the chances of success. Software project plan-ning is a key process area in Level 2 of the SEI Capa-bility Maturity Model (CMM). The first projectprobably will not encompass all the OO software prin-ciples we desire. Comprehensive use of OO principles

takes several projects to fine-tune—careful transitionplanning and software devel-opment will smooth the tran-sition. Software developerswho have gone through a rig-

orous process that uses structured analysis should befamiliar with some of the management issues, but theystill face some of the old problems in a newcontext—OO. For example, instead of worrying aboutthe data, processes, and data flow among the process-es, they need to think in terms of objects, methods,and inheritance. A transition plan and a complete soft-ware development plan are necessary.

Transition Plan. The transition plan is examinedwith respect to two central themes: “What makes thetransition to OOSE a mission with a lot of problems?”and “How can the transition be accomplished withminimum impact on the cost and schedule?” Anassessment of the software development processes is amust. This will establish some sense of where thesoftware development team is. For a smooth transi-tion to OOSE, an effective transition plan must be fol-lowed. Figure 1 illustrates a framework for atransition process.

Software Development Plan (SDP). The first docu-ment for any software development project should bethe SDP [9]. For government contracts, this documentbecomes part of the contract and is the final word onwhat the developer is going to deliver to the customer.For both government and commercial projects, theSDP indicates who will do what and when they will doit. It describes what techniques to use, what tools toemploy, and what risks are involved. For the softwaredeveloper it is probably the most important documentproduced because it defines the scope of the project.

Changing the Existing Culture Adopting OO development techniques will definitelyrequire a change in culture in the entire project orga-nization. This change can be made gradually and sys-tematically. Almost every step of the softwaredevelopment process must be adapted to fit the newway of thinking. As a result, the following activitiesare recommended to help readers achieve the neces-sary change in their culture.

Understand the Culture Change. OOSE affects every-one participating on the project, not just the softwareengineers. It is, therefore, necessary to change theculture in disciplines outside as well as inside the soft-ware engineering group. Changing the culture in anyorganization is not an easy task. For example, duringthe transition to OOSE, we felt that it would be easi-er to convince people that the world is flat than toconvince them to use OOSE.

Demonstrate Management Commitment. Perhaps thesingle most important factor in changing an organi-zation’s culture is demonstrating management com-mitment. Humphrey points out that a basic principleof software process modification is that major changesmust start at the top [15]. The following steps, whichare shown in Figure 2, can help demonstrate man-agement commitment:

• Demonstrate commitment to process changes.Top-level management not only should start thechanges but must also demand or reinforce the


• Effective development planning

• Changing the existing culture 1. Understanding the culture change 2. Demonstrating management commitment 3. Selling OOSE to the customer 4. Preparing the software development team

• Selecting an OO technique• Selecting a CASE tool• Staffing and organizing the project• Training the team• Dealing with the legacy systems• Budgeting for reuse

• Analyzing, modeling, and prototyping• Effective project tracking and controlling• Defining and documenting OO development process• Collecting software metrics• Inspecting OO software products• Integrating software documentation

III. Project Management Stage

II. Object-Oriented Insertion Stage

I. Planning and Pre-Project Stage

Figure 1.A framework for atransition process

changes. Our experience confirms the top man-agement must frequently remind people of theimportance of process changes. Otherwise, peopletend to slip back to their old ways of doing thingsdue to familiarity and habit.

• Provide time in the schedule. The project manageror software manager should set aside at least aweek or two at the beginning of the developmentprocess for training and discussion of processchanges. During this time managers should expectno project-related work to be done. Team mem-bers’ full concentration should be on the newprocesses and their definition.

• Provide proper tools. Although CASE tools areoften expensive, we believe they are essential tothe new OO process. Without proper tools, soft-ware engineers waste effort and creativity on trivialtasks instead of the analysis and design of the soft-ware system. By not committing any capital to thepurchase of tools, management sends a wrongmessage—that it is unsure about the new para-digm shift and the success of the new OO process.Software engineers may interpret this as a lack ofmanagement commitment to the new OO process.

• Strictly enforce the new OO process. Almost certain-ly, there will come a time when a member of theteam wants to bypass all the rigorous OOSE activitiesand develop the source code directly. This individ-ual will undoubtedly provide numerous reasons whygoing directly to coding will save time and money.Managers should not back down from the processchange under any circumstances. A manager whobacks down, even in the most trivial of cases, will notonly be setting a bad trend but will also demonstratea lack of commitment to the newly defined process.Selling OOSE to the Customer. In addition to

clients and users, the customer is defined as the

high-level management,other projects’ managers,the project team next door,colleagues on the sameteam, and so on. In mostcases we must overcomecustomer resistance tousing OOSE, especially ifthe customer knows it is our first OOSE project. Foran organization to succeed, it is important that thecustomer be involved in the transition to OOSE.Customers frequently associate new technology,such as OOSE, with high risk.

The following steps may help to make the cus-tomer a believer:

• Provide capability briefing charts. The customerusually has a negative attitude toward software pro-jects with any element of risk. Many people consid-er an OO development high risk because they feelthe tools and techniques are immature. To over-come the customer’s concerns, we provide a set ofbriefing charts that address the perceived riskareas. The main purpose of the charts is todemonstrate that we have thought through ourtransition plan. Some example topics are benefitsversus cost; training schedule; CASE tool strategy;OO process documentation; organizational issues;and return on investment (ROI). We have foundthat the more we prepare for the transition, thesmaller the customer perceives the risk to be.

• Train the customer. If possible, the customershould attend formal training on OO topics withthe development team. If the customers are unfa-miliar with OO terminology, they may feel theyhave lost control of the project. We diminish theiruneasiness by including them in training as early


Transition

Figure 2. Culture changesrequire manage-ment commitment[6, 7]

J F M A M J J A S O N D J F M A

Demonstrate Commitment ToProcess Changes

Provide Time In Schedule ToFoster Change

Provide Proper Tools Strictly Enforce The New Process

OOSE willhelp ourbusiness

Project Schedule

Ads OORA/OOD Software Development Process

and as much as possible. • Explain long-term payoffs. Make sure the customers

understand the long-term payoffs of OOSE. Someimportant benefits of an OO development, such asreusability and maintainability, directly affect thecustomer’s pocketbook. The cost saving is not firm-ly established, but initial data seems to be encourag-ing; more data is needed to establish this.

Preparing the Software Development Team. Surpris-ingly, we must often overcome resistance from oursoftware development team. There seems to be aninstinctive suspicion of any deviation from the exist-ing software development process, even if the processis chaotic. The team’s first opinion of the new processis typically that it requires significantly more work forsmall benefit. The major purpose of the team prepa-ration is to get people who have become accustomedto working independently to operate as team mem-bers. The principle of software process improvementis that ultimately everyone on the project must beinvolved [15]. The following ideas can be used to pre-pare the development team for the transition:

• Work with Process Improvement Groups. We mustwork with our company’s process improvementgroups to document the project software processesand to get the team involved in documenting thenew process, taking responsibility for the process,and establishing self-ownership of the process. Donot establish a special process group on the project.Why? Because the members of the software develop-ment team are software developers, not processbuilders. With the help of our team, the company’sprocess improvement group upgrades the newprocesses to fit the project needs. This processforces the software engineers and other members ofour team to understand the development processesso they can claim ownership in them. Both theunderstanding and the ownership of the processare keys to successful OO development.

• Initiate Participative Management. In participativemanagement, the developers help to generateschedules and make management decisions. Thegreatest benefit is to enlighten the developmentstaff as to the importance and the sequence of thevarious software development stages of a formaldevelopment. Under participative management,development teams gain an awareness of the sched-ules and the products that need to be delivered ateach important milestone. Participative manage-ment offers development teams an even greaterfeeling of buying into the new OO developmentprocess. Although participative management mayseem a bit risky considering everything else we arechanging, we still recommend this technique.

Object-Oriented Insertion Activities OO insertion is the second stage of the transitionprocess. This stage focuses on the insertion of OO tech-nology before the initial application of the technology.

Selecting an Object-Oriented TechniqueThe first insertion activity, and possibly the mostimportant task, is to select one of the many availableOO software development techniques. The OO tech-nique provides the step-by-step activities and a set ofgraphic notations to be used for reviews, inspections,and documentation. Therefore, this selection willhave an impact on almost every step in the softwaredevelopment process.

As OOSE has matured, the number of projectsapplying OO techniques has multiplied. Choosingsome of the more popular methods and trying todetermine which one best fits the application is a dif-ficult area to master.

Consider the following factors, shown in Figure 3,when selecting an OO technique:

Select a fully object-oriented technique. We highly rec-ommend choosing an OO technique that covers asmuch of the software life cycle system as possible.Most OO techniques are focused only on require-ments analysis, software design, and OO program-ming languages, resulting in a potpourri ofrepresentations and models. Unfortunately, testingand verification and validation (V&V) are completelyignored in most OO techniques. Using OO tech-niques on a single activity (i.e., only analysis or onlydesign) is risky. For example, some projects haveused a functional analysis approach followed by anOO design approach. Paradigm shifts in the middleof a software project have generally ended in failure.

Similarly, taking an OO analysis technique and com-pleting it with an OO design technique can produceunpredictable results. Mixing of techniques should beleft to teams experienced in OO development and notto an organization in transition. Some OO techniquesare available that take a software organization fromrequirements analysis through at least the detaileddesign activity. These are the most appropriate.

Domain considerations. The application domain isusually supported by a particular class of OO tech-niques. Partitioning the available techniques intounambiguous classes is impossible. However, one sim-ple guideline we use is a distinction between a top-down abstract object approach and an informationmodeling approach.

The top-down abstract object approach uses a suc-cessive breakdown of objects. The analyst successivelydecomposes high-level objects into lower-level objectsuntil the lowest-level objects are all easily understood.Computation-intensive systems in which the data isnot initially well understood (e.g., digital signal pro-cessing, pattern recognition) map better to a top-down, abstract approach. Examples of OO techniquesusing a top-down approach are Colbert’s OO softwaredevelopment (OOSD) technique [4, 7, 12, 13],Fayad’s object-engineering technique (O-ET) [10],and Selic’s real-time OO modeling (ROOM) [8, 18].

An information modeling approach uses dataobjects as the starting point and builds up from there.Information management systems (e.g., payroll sys-tems, scheduling systems, and insurance applications)


map better to an information modeling approach.Since the analyst fully understands much of the dataearly in the project, how to build objects from the datais reasonably clear-cut. Examples of OO techniquesusing an information modeling approach are Object-Modeling Technique (OMT) [17], Fayad’s O-ET [10],and Shlaer and Mellor’s OOA [6, 7, 13, 19].

Target language considerations. Some OO techniquesconform to the features of a particular target lan-guage. For a first OO development it is best to use anOO technique that maps easily to the target language.

For example, if the target language is Smalltalk orC++, choose a technique that fully uses the features ofthese languages. OO techniques like Fayad’s O-ET[10] and OMT [17] use inheritance as a major featureof the technique. Other techniques may not use inher-itance at all. Since Smalltalk and C++ feature inheri-tance as an integral part of the language, we want touse a technique that has inheritance with them.

Availability of formal training. Typically, each soft-ware development team member will learn each stepof the technique and then apply it to a small exam-ple. Obviously, each member will not be an expertimmediately after formal training. But at least eachmember will get to see how an experienced user cre-ates objects using the specific technique. This type ofknowledge is often impossible to derive from a text-book describing the technique. One major warning:Make sure formal training is available from an expe-rienced user before selecting a particular technique.

CASE tool support. For a first OO development, it isessential to have a CASE tool that can adequatelyimplement the chosen technique. The CASE tool letsthe developers concentrate on the analysis anddesign of the system and not on the mechanics anddiagramming of the OO technique.

Consider a consultant. A good consultant can save a

great deal of time by helpingthe development team withOO technique evaluationand selection processes. Inaddition, new techniquesare frequently being pub-lished and old techniquesare constantly being updated. This is a difficult areato track on a part-time basis. A good consultant couldbe well worth the cost.

Selecting a CASE Tool Modern CASE tools are the subject of controversy,having been credited and blamed for substantialincreases and decreases in productivity. Few wouldargue that the right tools in the right hands can effec-tively increase software quality and reduce costs. Thekey is identifying the right tools.

We found the use of a CASE tool essential to a suc-cessful transition to OOSE. However, be aware thatthe CASE tool will not eliminate all the obstacles asso-ciated with first-time OO development. There is stillno substitute for qualified software engineers who areopen to change. The following key factors are impor-tant in selecting a CASE tool.

Implement the technique correctly. Numerous CASEtool vendors (and even the OO authors) have pro-vided a “mapping” of a particular OO technique toCASE tools that implemented structured analysis anddesign. Although this is undoubtedly possible withcareful engineering, we found it intuitively difficult.Additionally, people familiar with the functionalgraphics often have trouble making a completeswitch to OO thinking. Avoid using a CASE tool thatrequires a “mapping” of the graphical representa-tions to a particular technique.

Enforcement of OO technique. The CASE tool should


Transition

Figure 3. Six major factors forselecting an OOtechnique [6, 7]

+ = =

C++ / Smalltalk

Ada83 / Ada 95

C / Pascal

Fortran / Cobol

Maintenance

Testing

Code andUnit Test

DetailedDesign

PreliminaryDesign

Requirements

Covers at Least OORA and OOD CASE Tool Support Training Available

Method Language CompatibilityMethod Domain CompatibilityMethod “Guru” Available

Object Interaction Diagram

Real-time Scientific

MIS/Database

enforce the rules of the OOtechnique as much as possi-ble. The best time to findmistakes is while the devel-opers are making them. Ifthe CASE tool can catchthese faults before reviews or

inspections, then a great deal of time will be saved.This is especially important when the technique isnew. The continual enforcement of the technique bythe CASE tool serves as a good training mechanismfor the developers.

Watch out for low pay-off “features.” CASE tool vendorsare constantly trying to add more features to outdo thecompetition. Features such as “reverse engineering” or“automated code generation” are generally not themost important reasons to buy a CASE tool. We found

these items to be marginallyuseful. The most importantparts of the CASE tools weregraphical editors that enforceconsistent application of thegraphical rules. Consistency

checking between diagrams and adata dictionary are useful.

Also be aware that the CASEtool will not work entirely as thevendor promised. For example,after several tries we eventuallygave up on one feature of a CASEtool: “automated documentationgeneration.” The poor quality andhigh overhead of this feature con-vinced us we were better off usinga commercial word processor.

A CASE tool should also supportseveral OO techniques and theirdevelopment processes, and must beflexible for generating and updatingthese development processes.

Staffing and Organizing the ProjectStaffing for a first OO software development requiresspecial consideration. We found that the standardsoftware engineering organization did not supportthe needs of OO software development. As teams pro-ceded through the development process, they madeseveral improvements to their software organization.Key positions, such as OO guru, domain analyst, andprototyping expert (“super hacker”), are essential tosuccessful OO software development (Figure 4). Thepeople in the new positions have direct responsibilityfor eliminating several problems that developmentteams have encountered early in development.

Staffing of the new positions within the organizationrequires careful consideration. Software engineers whohave experience in the application of complete OOdevelopment techniques are difficult to find. Howshould we organize and assign our staff to minimize therisk involved in introducing OO techniques?

OO Guru. An OO guru is required in the organiza-tion to refine the use of the OO technique. Eventhough each team member receives formal trainingin a specific OO analysis and design technique, there

are still many technique-relatedquestions. Numerous clarificationsand extensions of the techniqueare necessary to accommodate theunique elements of the project,such as reviews, documentation,particular CASE tool, target lan-guage, etc. Poor decisions in tech-nique-related areas can necessitateextensive rework efforts. There-fore, appropriate staffing of theOO guru position must be a highpriority. Figure 5 shows some ofthe OO guru’s responsibilities.

Domain Analyst. A primary goalof OOSE is to lay a firm founda-tion for software reuse. The pro-ject needs a domain analyst tospecifically address the reuse prob-lem. The domain analyst is also


PrototypingExpert

SoftwareManager

OO Guru

SoftwareSystems

Engineering

SoftwareQuality

Assurance

TechnicalLead 1

TechnicalLead 2

TechnicalLead N

DomainAnalyst

Key Positions for OO SoftwareDevelopment

. . .

Real-timeExtensions

Object-Oriented

Development

Solve Method Limitations NotUncovered During Training CASE Tool Adaptation

Training Example Your Problem

Requirements

Design

Code

Extensions for Problem Domain orCurrent Organizational Standards

New Employee Training andOn The Job Reinforcement

Figure 4. Key positions for asuccessful OO soft-ware development

Figure 5. OO guru’s responsi-bilities [6, 7]

responsible for understanding multiple software pro-jects within the domain, extracting the common ele-ments, and designing practical, reusable softwareparts and components. Figure 6 shows the domainanalyst’s responsibilities.

The domain analyst must be an expert in theapplication domain. Without a thorough knowledgeof the application area, it will be difficult to createcommon parts. The domain analyst must also have afirm understanding of “classes” and “objects.” Encap-sulation of the details within a class or object isimportant. If too many internal details are visible,designers will be less likely to use the part.

Prototyping Expert. Even in the middle of semi-for-mal OO development there is still a need for a superhacker—someone who can develop a software productrapidly and correctly without necessarily following anyspecific techniques. The activities of the prototypersmust be carefully separated from those of the rest ofthe software developers. This is especially true when weare using OO techniques. The software product willnot be consistent if software designers incorporate pro-totypes directly into the formal development. Figure 7shows the prototyping expert’s responsibilities.

Once the prototypes are complete, the prototypingstaff must communicate the requirements to the devel-opment personnel, who are then responsible for OOdevelopment. Therefore, an important qualificationfor the prototyping position is the ability to explicitlycommunicate the prototypes to the development staff.

Other personnel. It is important that all software per-sonnel understand the OO concepts quickly. We havehad the best success with people experienced in anOO programming language. Even though these peo-

ple had not used an OOtechnique, they could relatethe concepts to the OO lan-guage constructs. RelatingOO principles to languageconstructs is a good way tounderstand and explain the more abstract conceptsof OO development.

Training the TeamTraining is essential for new OO development teams.Even experienced software developers benefit from aformal introduction to OO tenets. An early traininginvestment pays large dividends in increased qualityand productivity throughout the developmentprocess. Additionally, just as with reusing OO soft-ware systems, the benefits of reusing an experienced,highly trained work force increase dramatically as weapply their knowledge to the next project.

After selecting an appropriate OO technique, wearrange for in-house training. For a first-time OO devel-opment, we recommend contracting with an experi-enced training organization. Such an organization canprovide experience and valuable insight into applica-tion of OO techniques and tools. This approach is help-ful for the development team, in that it forces thesoftware developers to clearly explain the project to thetrainer, who has little domain knowledge.

A requirement for 40 hours of training may be ful-filled in one week if that week is totally dedicated tothe training activity. The same training may be spreadacross two weeks if employees are available only half-time. The training may also be spread across 10 weekswith the addition of a part-time consultant. The


Transition

Figure 6. Domain analyst’sresponsibilities [6, 7]

Class LibraryClass Part No. DescriptionSensorQuick SortSignalGPS NavigationAir Data UnitInertial Navigation

A-001B-001A-002C-001A-001C-002

Sensor MonitorsEfficient SortAlarm SignalsNav with GPS updatePressure/TempBasic Nav Routines

PartA-007

PartA-009

PartB-012

PartE-002

Reuse Cost Evaluation

Estimated Number of Uses

Cos

t $

Cost-Effective Range

Coordinate With Domain ExpertsOn Different Projects

Decide When It Is Cost-EffectiveTo Design For Reuse

Create/Maintain A Class LibraryDevelop Specifications ForReusable Software Parts

authors favor the last approach,for several reasons. Compressingthe training tends to overwhelmthe students. They are exposedto too much, too fast. Spreadingthe training across a longer peri-od allows the students time to

reflect on and practice each significant detail. Addinga consultant provides the opportunity for much moreone-on-one learning.

Software engineers are not the only people who ben-efit from training. Each member of the developmentteam, including managers, contract engineers, cost esti-mators, and system engineers, needs to understand his

or her role in an OO develop-ment. A training programshould be tailored to comple-ment the entire developmentteam. Figure 8 shows the five W’sfor training the project team.

Dealing With Legacy SystemsThe preexisting non-object-ori-ented software system is called alegacy system. This issue is ofgreat concern to managementand will come up often. The waysof dealing with legacy systemscan be categorized as follows: (1)use as is; (2) reverse-engineerthem; or (3) modify them to fitwith OO systems. Each of theseapproaches has its own set ofproblems and issues that wemust deal with. We used thethird approach, using the preex-isting software modules by creat-ing an OO shell around them, as


Figure 7. Prototypingexpert’sresponsibili-ties [6, 7]

Figure 8.The Five W’s for trainingthe project team

Prototypes Objects

C++ Code

Ada Code

Evaluates Requirements Completeness Evaluates Design Efficiency

Throughput Study

Memory Utilization Study

Accurately Communicates Requirements/Designto Software Developers

J F M A M J J A S O N D J F M A

Project Schedule

ManagersCustomers

QualityAssurance

SoftwareEngineers

IV & VTesting

Subcontractors

Qualified Object-Oriented Training In-House

Just In TimeEveryone Involved In Project

Rapid Change In Culture

1. What 2. Where

3. Who 4. When

5. Why

Paradigm Shift Software Factory

Functional

Object-Oriented

shown in Figure 9. The shell approach provides a clean-er interface, and the OO software will interact with thesemodules as existing objects or classes.

Budgeting for ReuseReusable software costs extra time and money to devel-op. If there are software parts that must be reused, besure to budget the time and resources to make themreusable. Determining how much to spend on reuse isa strategic decision. We must determine how muchextra money we want to spend right now to save moneyin the future. It should be remembered that moneyspent now will save money in the future.

We should not expect huge gains from our firstOO project. Many people still associate OO designwith automatic reusability. We found that justbecause we used an OO technique, that did not makethe code reusable. The software organization mustlearn how to develop reusable software. Therefore,we recommend budgeting at least a small portion ofthe effort to developing reusable software.

Object-Oriented Project Management ActivitiesThis is the third stage of the transition framework. Upto now, we have focused on the preparation—layinga foundation for a significant cultural and paradigmshift. Once the project begins, additional activitiesare required.

Analyzing, Modeling, and PrototypingBecause OO techniques optimize the life-cycle costs,reusability, and supportability of software development,penalties often arise in performance and memory uti-lization. This can be especially true with inexperiencedOO development teams, who may over-apply some OOtenets. For example, we found that many new develop-ment teams tend to ambitiously create several layers ofabstracted objects. The resultant increase in systemoverhead is usually not noticed until system integration.It is essential that software parts considered critical toproject success be fully evaluated early in the projectlife cycle to reduce development risks.

The first step is to establish a computer resourcebudget. This budget should be based on a full exam-ination of the capacity of the target machine, includ-ing memory, CPU performance, and I/O bandwidth.This budget must now be compared to the specificrequirements of the application program.

This is where the plan gets interesting. Detailedresource requirements are difficult to establish, espe-cially for OO developments. Designers must under-stand not only the resource requirements of thealgorithms but also the overhead associated withtheir construction.

OO designs may introduce more overhead thantraditional developments. This overhead ranges fromimplementations of polymorphism and inheritanceto dynamic binding. Also, as designs maximize objectencapsulation and privatization, dedicated methodsand messages must be created to gain access to hid-den data. The resource impacts of all of the OO

trade-offs must be understood before the softwaredesign can safely mature.

Software prototypes, on the other hand, are func-tional approximations of some aspect of the actual tar-get system. These approximations can be generated toevaluate alternative software designs. Eventually, theseprototypes evolve into “rules of thumb” to help guidefuture design decisions.

It is important not to over-design models or proto-types. These tools should be used to estimateresource utilization or iron out design issues. Oncethis is done, the models and prototypes should beconsidered disposable.

Effective Project Tracking and ControllingLarge software projects require accurate and detailedtracking systems to provide insight into development

progress. Tracking systemsbecome even more indispens-able for large developments,because several softwareparts, at various life cyclestages, typically coexist. Usingthe tracking system, managerscan always ascertain currentperformance against schedule and project personnelalways have access to the latest development data.

Deciding what and how much information to trackdepends upon how the system will be used. A systemused solely to chart progress will contain less infor-mation than one used to plan future work. A systemused for management overview may contain signifi-cantly less data that one used for future cost estima-


Transition

Figure 9. Using the shellapproach to createobjects from legacysystems

Requirements

Design

Code

Functional Representation



Develop Object Shell



tion. It is more efficient to decide what we want out ofa system before we decide what to put in.

A tracking system identifies, estimates, allocates,and tracks the software objects, or “work-packages.”In the development sense, these work-packages are“objects” and “classes” in most OO techniques. Inaddition to object and classes, the work-packages arealso called “blocks” in Jacobson [16], and “modules”in OMT [17]. A work-package can consist of one ormany work-packages. We think of work-packages asindividual orders for which we contract and measurework. Work-packages exist for requirements, design,code, and testing/integration. We identify sufficientinformation with each assignment to allow an exter-nal contractor, knowledgeable about the specificapplication and processes, to execute the assignment.

The typical work-package allocates about one per-son-week of work. We found that this level of detail issufficient to adequately estimate the work withoutbeing unmanageable.

After the system’s engineering organization createsand estimates the initial system work-packages. Thesetypically identify several subsystems’ requirements todefine and prototypes to implement. This initial set ofwork-packages recursively spawns additional work-packages to complete the system. For example,design, code, test, and integration work-packages arecreated for sufficiently decomposed software objects.

Additionally, we estimate the required effort andresource utilization for each new work-package.Required effort is usually estimated in the form of per-son-hours or lines of code. Resource utilization esti-mates the required access to development facilities,such as unique test stations. The tracking system main-tains these estimates to help establish and maintain real-istic system development and integration schedules.

The work-packages must be closed after satisfactorycompletion. The process mandates the authenticatingagent, such as SQA or system engineering, to close thework-package. Closure typically involves a formalreview of the work, documentation of actual resourcesused or created (such as lines of code), and collectionof appropriate quality metrics. The closure of work-packages earns (accumulates) value for the project.

The developers, managers, and customers use thesystem to quickly view project status. Developers canidentify what new work is available and how their com-pleted pieces fit into the big picture. Managers canreview the recently completed work, compare progressto schedule, and compare actual to estimated metrics.The customer, with limited access to the system, canreview the up-to-date schedule and quality metrics.

Consider the following ideas before implementingthe tracking system.

• Incorporate tracking system updates directly intothe existing software development processes. Thesoftware development processes should specifywhat, when, and how to update. Complete compli-ance is imperative for tracking system usefulness.

• Make the tracking system readily available and easy

to use. People naturally resist tedious systems, andresistance is the enemy of compliance. It is worthspending time up front to ensure that the trackingsystem is easy and helpful. Automation of key fea-tures, including extensive use of default or boiler-plate data, and template data is always appreciated.Time invested in tracking system simplification isalways well spent.

• Establish trust in the tracking system. The faith thatis placed in the system must be visually obvious andunwavering. Set high quality standards and expectno less. The development team must clearly under-stand the importance of the tracking system andthe potential results of neglect. This attitude willbecome contagious and spread through the group.Ensure the system works—and trust it.

Defining and Documenting theDevelopment ProcessDefining and documenting the development processis an important step. The processes that tailor the OOtechnique to the project must be defined. Theprocesses transform the theories of the textbook intothe real world—our world. Documented processesenable the development team to consistently applyand benefit from the new OO technique.

The customer may want progress reviews, extensivedocumentation, and bidirectional traceability fromrequirements models to code. The OO techniques weused did not address these topics. To address such top-ics, we need a detailed, documented process that canconsistently apply the features of the OO technique tothe target system and satisfy the customer’s demands.

We recommend appointing a team member tointeract with the company’s process improvementgroup to document exactly how to apply the OO tech-nique to the target system. The team member shouldattend the process group meeting on a regular basisand work with them to determine what, how, andwhen to document. Forming a project’s process teammust be avoided because of process paralysis. Processparalysis, as defined by Yourdon, is what happenswhen the project team becomes thoroughly over-whelmed by the new technology and gradually endsup spending all of its time (1) trying to understandthe new technology, (2) arguing about its merits, or(3) trying to make it work [18]. We must watch for thisparalysis and get our project team on track with theproject objectives and goals by using a specialized soft-ware process improvement team outside the project.

The process’ definition concentrates on what andwhen software products are required. For example, whatlevel of documentation is required for a preliminarydesign review? Which graphics are incorporated into ourrequirements specification? What are the exit criteria forobject-level testing? We found that by precisely definingthe software products required for each developmentphase, each developer can maximize individual contri-butions and still maintain system consistency.

The software process must be defined with sufficientdetail that any competent developer outside the scope


of the current project could correctly answer the ques-tion, “What’s next?” Specifically, the process defines theintent, techniques, entry and exit criteria, and appro-priate quality standards for each step of development.Figure 10 shows appropriate process detail.

There is a common misconception that we cannotdocument techniques, such as software development,that involve creativity. We would argue, as may ourcustomer, that without defined processes the devel-opment team cannot consistently apply any develop-ment approach. Indeed, the Software EngineeringInstitute strongly advocates this position [15]. With-out the process, developers freely apply their versionof software development. This approach becomesespecially risky when implementing a new OO tech-nique. Core development processes should existbefore starting a project, and should be continuouslytuned as the program matures.

Collecting Software MetricsWhile documented processes provide the frameworkfor improvements, metrics provide the ruler thatmeasures success or failure. Carefully selecting mea-sures indicating application of the process will help toprove a growing proficiency. The collection of valu-able software metrics should be permanentlyingrained in each software process.

Collecting software metrics is easy; collecting use-ful software metrics requires effort. What makes themmeaningful? Consider the following suggestions:Gather metrics only in support of specific, predeter-mined objectives, and evaluate the measures in thatcontext. Figure 11 illustrates software metrics collec-tion principles. Measures of planned versus actualclass or object reuse, or of cost of designing for reuse,help guide follow-on projects. Measures of objectquality, such as coupling or cohesion between classesor objects, provide insight on how well developers areapplying OO technique concepts.

Before measuring any process, rank the metrics

based on the potential valuethey add. The act of measur-ing human processes is per-sonal and disruptive. Therisks range from offendingthe developers to erroneous-ly invalidating long-standing values. Also, the act ofmeasuring some processes alters what we are measur-ing. With all of this at stake, we make sure that we col-lect metrics only for high-value, repeatable processes.Collect metrics on processes, not people. Figure 12shows some useful software management metrics thatwere collected on several projects.

We conclude that collecting measurements isimportant for software development tracking andcontrol. However, there are no universally acceptedmeasurements for OO. Jacobson [16], Chen and Lu[2], and Chidamber andKemerer [3] suggest well-known and accepted mea-surements. They could beused as the starting point.

Jacobson [16], treats met-rics in a very general fashion


Transition

Figure 10. Appropriate processdetail

– depends upon environment– specifies “who,” “what,” “when”– reference “how”

Cost-effective range

Too Much• not cost-effective• typically too much “why”

Not Enough• useless• typically only “what”

SET RESET

Reliability

Objectives

Collect Metrics in Support ofPredetermined ObjectivesMeasure Processes — Not People

Collect Metrics from Repeatable Processes Ingrain Metrics Collection into Processes

EnterReliabilityMetric intoDatabase

Figure 11. Software metricscollection princi-ples [7]

and divides them into twocategories: (1) process-related metrics, such astotal development time,development time ineach process and sub-process, and time spentmodifying models from previous process, and (2) prod-uct-related metrics, such as total number of classes, ofwidth and height of inheritance hierarchies, averagenumber of operations in a class, and length of operations(in statement). Chen and Lu [2] present eight metricsfor OO design. Chidamber and Kemerer’s work [3] ismost frequently quoted; they propose a set of six metrics:Weighted methods per class, depth of inheritance tree,number of children, coupling between objects, responseof a class, and lack of cohesion in methods.

Inspecting Object-Oriented Software ProductsSoftware inspections substantially improve productquality and help to keep new OO development on trackby reducing defects and costs [5]. As with anything new,the application of specific concepts may not be fullyunderstood. Even concepts that are well understoodmay allow several implementations, all equally correct.

Documentation is a good example. Those who haveattempted to integrate several developers’ writing into acoherent document are well aware of the difficulties.Without formal interim reviews, the final product willresemble a United Nations meeting—several seeminglyunrelated individual elements trying to work together.

Approach software inspections as a rigorous formof peer review or walkthrough. As such, inspectionsshould formally compare developed software toestablished standards. Standards vary with the pro-ject, but inspections will ensure that the developmentteam follows the appropriate standard.

Thoroughly reviewing all software on a large projectis time-consuming. Because of this, inspection processesshould be optimized by defining specific, complemen-tary roles for individual reviewers. For example, onereviewer may ensure all requirements are sufficientlyallocated in the design, while another may verify a unit’stestability. The number and specific responsibilities ofthe reviewers must be formally documented for eachtype of material reviewed. We have found that inspec-tion checklists are a good way to ensure that severalindependent reviewers cover all the bases.

Some software teams feel they can not affordinspections. We contend that inspections are themost cost-effective technique for ensuring softwarequality. Removing defects at their point of insertionsignificantly reduces the cost of their repair. Effi-cient inspections are always a wise investment.

We make some finalsuggestions about inspec-tions:

• Review products forspecific qualities ofobject orientation.These qualities rangefrom consistentabstraction levels forgeneric objects andmethods to appropri-ate utilization ofinheritance. Addition-

ally, potential for reuse may be scored and docu-mented. These reviews will help reinforce OOconcepts by revealing several applications in theproject domain. Applying these theories is the bestcontinuing education available.

• Develop quantifiable metrics to ensure adherenceto specific technique. These measurements shouldconcentrate on the specifics of the application ofthe technique itself. They may include definitionof an object, correct utilization of graphics, andother documentation.

• Inspect the quality of documentation, includinggraphics. Standards should be developed to definedocumentation quality. These standards are oftenoverlooked in software development, especiallywhen CASE tools are introduced as documentationaids. We’ve found that while good graphics increasemaintainability, poor graphics detract. Rememberthat the customer’s main perception of systemdevelopment quality is through the documentation.

Integrating Software DocumentationDocumentation may be the most visible sign of soft-ware quality. It exposes not only the construction butthe logic behind the physical connections. The docu-mentation is usually the only link maintenance per-sonnel have to the original designers. It is imperativethat this link be strong.

Mapping an OO technique to documentation stan-dards can be difficult. The problem is compoundedwith extensive use of graphics. This difficulty is usual-ly traced to understanding the term “standard” asimplying “applicable to all developments exceptmine.” What is worse, OO developments were proba-bly uncommon when the documentation standardoriginated. Undoubtedly, the documentation stan-dard will need to be revised for compatibility with anOO development technique.

We have found that the best approach is to tailorthe documentation standard to the specific tech-nique before the development begins. This includestranslating all the terms given to the developmentphases, concepts, and deliverable pieces. It is impor-tant to define and to maintain the focus on the realpurpose of the documentation. Poor documentationis worse than none at all.

Technique-specific graphics (possibly generated by


Figure 12. Useful softwaremanagement met-rics [7]

100

80

60

40

20

0

Orig. Est.ActualCurrent Plan

Jan.Feb.

Mar.Apr.

May Jul. Sep. Nov.Jun. Aug. Oct. Dec.

• Staffing Profile by Discipline• Software size – Objects – Lines of Code – Interfaces• Objects Integrated• Target System – Throughput – Memory Utilization – I/O Utilization• Software Defects by Phase (STRs)

Track actual progress against original and current plan

CASE tools) should be mapped into specific docu-mentation sections. This step may prove surprisinglydifficult to achieve. The mapping requires several revi-sions; however, the results are well worth the effort.

If customer approval is required for documenta-tion decisions, include the customer in the early dis-cussions. The customer, who will often be the ultimatesystem maintenance agent, may have strong feelingson specific documentation issues. Simple agreementsearly in a program may avert many later headaches.

One final note about documentation. In many cases,documentation revisions are more common than soft-ware revisions. Without software configuration man-agement, documentation integrity is impossible.

Using Software Configuration ManagementConfiguration management is the process of identify-ing and defining the configuration items in a system(e.g., class diagram, design document, object test case),controlling the release and change of these itemsthroughout the system life cycle, recording and report-ing the status of configuration items and changerequests, and verifying the completeness and correct-ness of configuration items [1]. A large number of con-figuration items (e.g., design artifacts and products)are produced by an OO technique. These configura-tion items, such as requirements, class diagrams, object-interaction diagrams, object diagrams, object-hierarchydiagrams, process diagrams, object/class design, code,and test cases must be placed under software configu-ration management. During development, updating,and reuse, these products are revised several times andmust be placed under version control. This intensifiesthe need for a powerful yet simple software configura-tion management and version control system.

ConclusionsWe have shown that a successful transition to OO soft-ware development techniques requires the use ofmanagement processes designed for the paradigm.The project must be preceded by an effective softwaredevelopment planning process that includes OO tech-nique considerations—A critical part of these earlyactivities is changing the culture.

We have concluded that the OO insertion stage ofthe transition defines the development environmentand allocates the required resources. The critical activ-ities during this stage include defining techniques andtools and selecting and training the development team.

We recommend that managers make every processand tool used during development their own. Thisrequires that processes be customized for the currentproject and that tools be used in the most effectivemanner for the current project. Managers should notbe frightened away from good concepts becausesome documented implementation seems expensive.They should instead study what the concept means inthe context of their project and adapt it to their ownpurposes. Good concepts and techniques do not haveto be forced on people who want to maximize effec-tiveness. If concepts and techniques are truly good,

developers will fight to be able to use them.Management of software projects can proceed

effectively when good management techniques areapplied. We have shown that the best of softwaremanagement techniques can be effectively applied toOO development projects.

References1. Bersoff, E.H. Elements of software configuration management.

IEEE Trans. Softw. Eng. SE-10, 1 (Jan. 1984), 79–87.2. Chen, J.Y. and Lu J.F. A new metric for object-oriented design.

Information and Software Technology (Apr. 1993), 232–240.3. Chidamber, S.R. and Kemerer, C.F. Toward a metrics suite for

object-oriented design. In Proceedings of OOPSLA ‘91 (1991).4. Colbert, E. The object-oriented software development method:

A practical approach to object-oriented development. In Pro-ceedings of ACM TRI-Ada ‘89 (Oct. 1989), pp. 400–415.

5. Fagan, M.E. Advances in software inspections. IEEE Trans.Softw. Eng. SE-12, 7 (July 1986), 744–751.

6. Fayad, M. E. Managing Object-Oriented SoftwareDevelopment Pro-jects. Three-day seminar, Technology Training Corporation(TTC), Toronto/Washington DC, April/May 1993.

7. Fayad, M.E. Managing Object-Oriented Software Development Pro-jects. Full-day tutorial, ECOOP ‘93. July 1993, Kaiserslauter,Germany

8. Fayad, M.E. Object-Oriented Experiences. In Proceedings of theTOOLS USA Conference ‘93. (Santa Barbara, Calif., Aug. 1993).

9. Fayad, M.E. Software Development Plan for Object-Oriented Projects.IEEE Computer Society Press, March 1996.

10. Fayad, M.E. Object-oriented software engineering: Problemsand perspectives. Ph.D. dissertation, June 1994.

11. Fayad, M.E., et al. Using the Shlaer-Mellor object-orientedmethod. IEEE Softw. (Mar. 1993).

12. Fayad, M.E., et al. Adapting an object-oriented developmentmethod. IEEE Softw. (May 1994).

13. Fayad, M.E., et al. Object Modeling Technique (OMT): Expe-rience report. J. OO Programming (JOOP) (Nov.–Dec. 1994).

14. Fayad, M.E. and Fulghum, M. Object-Oriented Experiences. SIGSBooks, New York, 1996.

15. Humphrey, W. Managing the Software Process. Addison-Wesley,Reading, Mass., 1989.

16. Jacobson, I., et al. Object-Oriented Software Engineering: A Use CaseDriven Approach. Addison-Wesley, Reading, Mass., 1992.

17. Rumbaugh J., et al. Object-Oriented Modeling and Design. Prentice-Hall, Englewood Cliffs, N.J., 1991.

18. Selic, B., et al. Real-Time Object-Oriented Modeling. Wiley, NewYork, 1994.

19. Shlaer, S., and Mellor, S.J. Object Lifecycles: Modeling the World inStates. Yourdon Press, Englewood Cliffs, N.J., 1992.

20. Yourdon E. A Game Plan for Technology Transfer. Tutorial: SoftwareEngineering Project Management. R.H. Thayer, Ed. ComputerSociety Press, 1987, 214–217.

About the Authors:MOHAMED E. FAYAD is an associate professor of computer sci-ence at the University of Nevada, Reno. Author’s Present Address:Computer Science/171, University of Nevada, Reno, NV 89557;email: [email protected]

WEI-TEK TSAI is a professor of computer science at the Universi-ty of Minnesota. Author’s Present Address: Computer ScienceDepartment, University of Minnesota, Minneapolis, MN 55455;email: [email protected]

MILTON L. FULGHUM is a senior staff engineer at FlightSafetyInternational in St. Louis, MO. Author’s Present Address: FlightSafety International, St. Louis, MO 63042; email:[email protected]

Permission to make digital/hard copy of part or all of this work for personalor classroom use is granted without fee provided that copies are not made ordistributed for profit or commercial advantage, the copyright notice, the titleof the publication and its date appear, and notice is given that copying is bypermission of ACM, Inc. To copy otherwise, to republish, to post on servers,or to redistribute to lists requires prior specific permission and/or a fee.

© ACM 0002-0782/96/0200 $3.50

C


Transition

to object-oriented software development · to object-oriented software development a transition...

Documents