..... ::i ....
m

Z _

= _n

J

T

_ - ---2. ............

......_-.-:: _ ...._.:.-- - --;:- .

w
SOFTWARE ENGINEERING LABORATORY SERIES SEL-88-002

COLLECTED SOFTWARE

ENGINEERING PAPERS: VOLUME V!

NOVEMBER 1988

National Aeronautics and

Space Administration

Goddard Space Flight Center

Greenbelt, Maryland 20771
- --_

\

i

i

i

ii

m

u

ms

m

i

i
FOREWORD

The Software Engineering Laboratory (SEL) is an organization

sponsored by the National Aeronautics and Space Administration/Goddard Space Flight Center (NASA/GSFC) and created for

the purpose of investigating the effectiveness of software

engineering technologies when applied to the development of

applications software. The SEL was created in 1977 and has

three primary organizational members:

NASA/GSFC (Systems Development Branch)

The University of Maryland (Computer Sciences Department)

Computer Sciences Corporation (Systems Development

Operation)

The goals of the SEL are (i) to understand the software

development process in the GSFC environment; (2) to measure

the effect of various methodologies, tools, and models on

this process; and (3) to identify and then to apply successful development practices. The activities, findings, and

recommendations of the SEL are recorded in the Software

Engineering Laboratory Series, a continuing series of

reports that includes this document. The papers contained

in this document appeared previously as indicated in each

section.

Single copies of this document can be obtained by writing to

Systems Development Branch

Code 552

NASA/GSFC

Greenbelt, Maryland 20771

5207

iii

PRECEDING PAGE BLANK NOT FILMED
i

II

z

i

_J

• 'II

Di

wr

V

Ii r

m

m

v

i

Im

I

I

I
L

z -

=

TABLE OF CONTENTS

Section 1 - Introduction ............... i-i

Section 2 - Software Measurement and Technoloqy

Studies .................. 2-1

"The Effectiveness of Software Prototyping: A

Case Study," M. V. Zelkowitz ........... 2-2

"Measuring Software Design Complexity," D. N.

Card and W. W. Agresti .............. 2-11

"Quantitative Assessment of Maintenance: An

Industrial Case Study," H. D. Rombach and

V. R. Basili ................... 2-24

"Resource Utilization During Software

Development," M. V. Zelkowitz ........... 2-35

Section 3 - Measurement Environment Studies ...... 3-1

"Generating Customized Software Engineering

Information Bases from Software Process and

Product Specifications," L. Mark and

H. D. Rombach ................... 3-2

"Software Process and Product Specifications:

A Basis for Generating Customized SE Information

Bases," H. D. Rombach and L. Mark ......... 3-11

"The TAME Project: Towards Improvement-Oriented

Software Environments," V. R. Basili and

H. D. Rombach ................... 3-21

"Validating the TAME Resource Data Model,"

D. R. Jeffery and V. R. Basili .......... 3-37

Section 4 - Ada Technoloqy Studies .......... 4-1

"Experiences in the Implementation of a Large

Ada Project," S. Godfrey and C. Brophy ...... 4-2

"General Object-Oriented Software Development

with Ada: A Life Cycle Approach," E. Seidewitz. . 4-9

"LessonsLearned in the Implementation Phase

of a Large Ada Project," C. E. Brophy,

S. Godfrey, W. W. Agresti, and V. R. Basili .... 4-24

5207

v

pRE.CED|NG PAGE BLANK NOT FILMED
TABLE OF CONTENTS (Cont'd)

SectiQn 4 (Cont'd)

"Object-Oriented Programming in Smalltalk and

Ada," E. Seidewitz ................

Standard Biblioqraphv of SEL Literatur@

4-32

I

W

i

i

I

z

I

I

I

i

I

m

m -

I

5207

vi i
L

SECTION 1 - INTRODUCTION
i

7 ---:

T Z

= =

=

..: ;7 zzizzzz zzzz ; . _ ; zz 7;

=

V

I

_r

w_ ;w; ;;
v

SECTION 1 - INTRODUCTION

I

This document is a collection_f technical papers produced

by participants in the Software Engineering Laboratory (SEL)

during the period June i, 1987, through January 1, 1989.

The purpose of the document is to make available, in one

reference, some results of SEL research that originally appeared in a number of different forums. This is the sixth

such volume of technical papers produced by the SEL.,--A-I-i_

though these papers cover-several topics_-related to_:soft_a_e__

._, ................ J %

englneering, they do not encompass the entire scope o!-SEL

activities an_ interests. Additional information ___5qut the_

SEL and its research efforts may be obtained fromthe_source_

listed in the bibliography at the end of thisd0cu_t.

For the convenience of this presentation, the twelve papers

contained here are grouped into three major categories:

• CZ,_"Software Measurement and Technology Studies)

• <z Measurement Environment Studies. -:_;

• _ Ada Technology Studies --!

The first category presents experimental research and evaluation of software measurement and technology; the second

presents studies on software environments pertaining to

measurement. The last category represents Ada technology

and includes research, development, and measurement studies.

The SEL is actively working to increase its understanding

and to improve the software_development process at Goddard

Space Flight Center (GSFC). Futur_e_:effort_will be documented in additional volumes of the Collected Sof_e Enqineerina Papers and other SEL publications.

5207

I-I
-j,

am

J

qB

w

lip

V _

a

I'

W _

m

V

m _

m

r__

im

g

i
SECTION 2 - SOFTWARE MEASUREMENT AND

TECHNOLOGY STUQIES
W

=-

z :L i
V

=F

v

SECTION 2 - SOFTWARE MEASUREMENT AND TECHNOLOGY STUDIES

The technical papers included in this section were originally

prepared as indicatedbelow.

• "The Effectiveness of Software Prototyping: A Case

Study," M. V. Zelkowitz, Proceedinqs of the 26th

Annual Technicai Symposium of the Washinqton, D.C.

Chapter of the ACM, June 1987

• "Measuring Software Design Complexity," D. N. Card

and W. W. Agresti, The Journ_l Qf Systems and Software, June 1988

• "Quantitative Assessment of Maintenance: An Industrial Case Study," H. D. Rombach and V. R. Basili,

Proceedinqs from£he Conference on Softw_r@ M_intenance, September 1987

• "Resource Utilization During Software Development,"

M. V. Zelkowitz, The Journal Q( SMstems and Softw_re, 1988

5207

2-1
THE EFFECTIVENESS OF SOFTWARE PROTOTYPING:

A Case Study

=

Marvin V. Zelkowitz

Department of Computer Science

University of MarylLnd

College Park, Maryland 20742

ABSTRA CT

_r_h_paper d/ae_se# resource utilization over the life

cycle o/software development, and dbeuaves the role

that the current "waterfall model" plays in the actual

softtoare life clscte, The effects of protot_iny are

measured with respect to the life CllCtS model.

Software production in the NASA environment was

analysed to mcaat_re these differences. The data col.

lected from thirteen different project" and one prate.

tFpe development were collected by the Software Enoineerlng Laboratory at NASA Goddard Space Flight

Center and analyzed for similarities avd differences.

The results indicate that the waterfall model is not

vcr Vreal/uric in practice, and that a prototype develop.

meat follows a similar life cycle as a production

system..althouoh, for this prototype, issue• like system

design and the user interface took precedence aver i_-

awes each ea carrcctncu and robuctneu of the re#siting system.

KEN'WORDS: Life cycle, Measurement, Prototyping,

Resource utilization, Waterfall chart

1. Introduction

As technology impacts the way industry build•

software, there is increasing interest in understanding the

software development model and In measuring both the

processand product.New work_tatlontechnology,new

languages (e.g.,Ado, requirements and specification

languages)as wellas new techniques(e.g.,prototyp_ng,

lneudocode)are impacting how softwareis builtwhich

furtherimpactshow management needsto addressthese

concerns in controllingand monitoring a softwm'e

development.

In thispaper,data are first presentedwhich analyze

severalfairlylargesoftwareprojectsfrom NASA Goddard Space Flight Center (GSFC) and put the current

"waterfall" model in perspective. Data about software

costs, productlvity, reliability, modularity and other f_ctars ,re collected by the Software Engineering Labor_-

tory (SEL), a research group consistingof ind]vlduals

© 1957 Association for Computing Mschlnery, Inc.

Pecmlssioa fo cop)- withoul fee •1] o4" pmrl of ¢hi$ motet'in] Is gr•aU_d

pre.,_led thai the copies -.re not made or distributed for direct commercial ,d_•ntage ' the ACM cop)rlght notlc_ and the title of tlte

public•ties •nd its date appeai, •nd notice is given that copying is

I_ permission of Ihe Assocleiion for Computing Machinery. To

_._ otherwise, or to republish, requires • fee sad/or specf1_ per.

uutss_a.

from NASA/GSFC, Computer SciencesCorporation,and

the Universityof Mmryland, for researchon improving

both the software product and the procem for bu_ldlng

such software [SEL 82]. The Software Engineering

Laboratory wu establbhedin 1976 to investigatethe

effectivenessof software engineering technlquesfor

developing ground Supp6_ soRware for NASA [BAS 78].

A recentprototyping experimentwas conductedand data

were collectedwhich compare this prototype with the

more tradltlonMway to buildsoftware.The paper concludeswith comments on the roleof prototypingas a

softwaredevelopmenttechniqfie.

The softw,re development process is typically

product-drlven,and can be dividedinto six major llfe

cycle_ctivities,each associatedwith a specific"end product" [WAS 83,ZEL 78]:

(1) Requirement_ phase and the publicationof i

requirementsdocument.

(2) Deaign ph_e and the creationof a designdocument.

(3) Code and Unit Test phase and the generation of

the source code library.

(4) System s'ni-e_g('a_;on ana/_¢silng phase and the

fulfillmentof thetestplan.

(5) Acceptance test phase and completion of the

acceptance test plan.

(S) Operation and Maintenance phase arm the

delivery of the completedsystem.

In orderto presentconsistentdata acrossa largenumber

of projects,this paper only focuseson the ]ntervml

between design and scdeptadce_est snd involvesthe

actualimplementation of the •)'stemby the developer

group.

In thls paper, we will refer to the term activity as

the work required to complete a Specific task. For example, the coding actlv]ty refers to all work done in generating the source code for a project, the design activity

refers to building the program design, etc. On the other

hand. the term phase will refer to that period of time

when • certain activity is supposed to occur, For example. the Coding Phase will refer to that period of time

26TN ANNUAL TECHNICAL SYMPO$1UM

WAS_|N¢;O_ D.C. Cvt*,p_'t_ Of ACM

Gaiihersbuf 9, MD-June 11, 1987

5207

2-2

Tin

g

w

I I

m

m

m
w

during a software development when coding artlvitles are

supposed to occur. It is closely related to managementdefined milestone dates for a project. But durins thls

period, other activitiesmay also occur.

IREQUIREMENTS

I

DESIGN

l

CODE

I I

INTEGRATION

J

ACCEPTANCE TEST

I I

OPERATION

I I

Lifecyclc Calendu Time _>

Ficu_ 1. TypicM Life Cycle

The waterfall model makes the mumptlou that all

activityof a certain type occurs during the phase of that

same name end phases do not overlap. Once a phase

ends, then the next phase begins. Th_ allrequirements

for a project occur during the Requirements Phase; Ml

design activity occurs during the Des|gn Phase. Once a

project has a design _eview m_.d enters the Cod]ng Phase,

then all activity is Coding. Since many companies keep

data based upon hours worked by calendar date, thls

model isvery easy to track. However, as Figure 1 shows,

activitiesoverlap and do not liein separate phases. We

willgive more data on this later.

2. The waterfall chart Is all wet

In the NASA/GSFC environment that we stud_ed,

the software life cycle follows a fairlystandard set of

activities[SEL 81]:

The reqm'rement$ actlvlty involves translating the

functlonM specificatlonconsisting of physical attributes

about the spacecraft to be launched into requirements for

a software system that is to be built.

The design aetlvky can be divlded Into two sub_ct|vitles:the preliminary deslgn activity and the detailed

desi#n activity. During prellminaxy deslgn, the major

subsystems are specified, input-output [nterfaees and

lmplementatlon strategiesare developed. During detailed

design, the system archltecture isextended to the subrout[ne and procedure level. Data structures and formal

models of the system are defined. These models intrude

procedural descriptions of the system, datafiow descri_

tions, complete description of all user input,system output, and input,-output files,operational procedures, functional and procedural descriptions of each module, and

complete description of all internal interfaces between

modules.

The Codi,# and Unit Test activity involves the

translation of the detailed design Into s source program

in some appropriate programming [angua4_e (usually

FORTRAN). Each programmer will unit test each

module for appaxent correctnees.

The System Integration and Teat activity validates

that the completed system produced by the coding and

unit test activity meets its specifications.Each module,

as it is completed, is integrated into the growing system

and integration test is performed to make sure that the

entire package executes as expected. Functional testing

of end-to-end system capabilitiesis performed according

to the system test plan developed as pazt of the requirements activity.

In the Acceptance Test activity, the development

team provides a._lstance to the acceptance test team,

which checks that the system meets itsrequirements.

Operation and Maintenance activities begin d'ter

acceptance testingwhen the system becomes operational.

For flight dynamics softwm-e at NASA, these activities

axe not slgniflcmatto the overallcoat. Most softwm-e produced ls highly reliable.In addltlon, the flightdynamics

software isusually not mission criticalin that a failureof

the software does not mean spacecraft failurebut simply

that the program has to be rerun. In addkion, many of

these programs {'i.e.,spacecra_'t)have limited lifetimesof

six months to about three years.

Table I presents the raw data on the fourteen projects analyzed in this paper. The thirteen numbered projects are all fairly large flightdynamics programs, ranging in size from 15,500 linesof FORTRAN code to 80,513

llnes of FORTRAN, with an average size of 57,800 lines

of FORTRAN per system. The average work on these

projects was 89.0 staff months; thus, all represent

signifcant effort.The last project listed in Table I -

FDA$ - represents a prototype development and will be

discussed in more detaillater.

In moat organizations, phase data axe collected

weekly so that they are the usual reporting mechanism.

However, ]n the SEL, activity data axe also collected.

The data that are collectedconsistof nine possibleactivities for each component (i.e.,source progratn module)

worked on for that week. In this paper, these will be

grouped as Design activities,Cod;ng activities (code

preparation and unit testing),Integration testing,Acceptance testing and Other. Specific review meetings, such

as design reviews, willbe grouped with their appropriate

activity (e.g., & design review is a design activity, a code

walkthrough is a coding activity, etc.). Thls allows us to

look at both phase and activity utl]]zation.

26TH ANNUAL TECHNICAL _¥MPOSlUM

WASHINGTON O.C. CHAPTER OF ACM

Gaithersburg, MD*June 11, 1987 8

5207

2-3
pRoJECT $|ZE AND STAFF-_* :_TH EFFORT

PR-PR-6_CT SIZE (LI_ES TOTAl, _.FORT STAFF1

Z

$

5

6

7

|

9

1o

11

12

13

AvenM[e

FDAS

OF CODE| HOUR*

15,500 17,715

50,911 12,5_

6i,17B 17,039

28,844 10,946

25,731 1,514

6T,3._5 19,475

66,260 17,097

+ ÷

5S,05T 15,2t_2

75,420 5,792

89,513 15,122

75,393 14,506

85,3($9 14,309

57,890 13j52'2

33,967. 141150

+ - Raw data not ivailable in dss_ blum

* - All _cbnical effort including progrlmmer Lnd mtnalement

Tale 1. Project Size imd Stall-month F__ort

MONTHS

116.5

82.g

112.1

72.0

I0.0

128.4

118.4

÷

100.4

381

99.5

95.4

94.1

89.0

93. !

time

The results of thls can be briefly summaclzed by

Table 2. According to this, in NASA, 22% of a project's

effort is during the design phase, while 40% is during

coding. Integration testing takes 16%_ _ other

activities take 12%. (Remember that requirements data

are not belng collected here. We are simply reporting the

percentage of design, coding, and testing activities. A

significant requirements activity does occur.)

1 Desil_n Code Int. Test. Other

By phase 22 40 16 12

By activity 25 30 15 29

Table 2. Activit]es performed in each phase (by o_)

However, actual activlties dlffer somewhat from simply ]ooklng at effort spent between somewhat arbitrary

calendar dates set up months in advance. By looking at

all design effort across all phases of the projects, design

actlvlty is actually 25% of the total effort rather than the

22% Hsted above. Coding is a more reasonable 30%

which means that the coding phase includes many other

activities. "Other" increased from 12% to 20%, and

include many time-eonsumlng tasks that are not

accounted for by the usual life cycle. (Here, Other

includes acceptance testing, u well as activities that take

a slgniflcant effort but are usually not separately

identifiable using the standard model. These activities

Include meetings, training, travel, documentation, and"

other various activities assigned to the project.)

The situationis actually more complex than shown

in Table 2. Although using Ph_ Date shows that total

design effort differs by only 3% from the design phase

effort, the distrlbutlon of design activity throughout the

project ls not reflected in the table. These data are

presented in Table 3.

IDeslgn [ Code Int. Test ] Accept. Test ]

so I _J 2o I 21

Table 3. Design Activity During Life Cycle Phases (by %)

As Table 3 shows, only 50°7o of "1i design work

occurs during the Design Phase and just under one third

of the total design activity occurs during the coding

period. Over one fifth (20%+2_) of all design occurs

during testing when the system is "supposed-" to be

finished.

As to coding effort,Table 4 shows that while ,

major part, or 70_ of the coding effort,does occur during the Codln_ Phase, almost one quarter (i6_}'o+70:o)

occurs during the testlng periods..Ks _xpectbd, only a

small amount "of coding (7%) occurs during the design

phase; however, It does indicate that some codlng does

begin on parts of the system while other parts are still

under design.

Desil_n7 I Code70 Int" TestI16 ] Accept" Test7

Table 4. Coding Activity during Life Cycle Phases (by %)

Similarly, Table 5 shows that significantintegration

testlng actlv|tles(about 34_) occur h_ore the _ntegratlon testingperiod. Once modules have been unit tested,

programmers begin to piece them together to build larger

subsystems.

[Design [ Code I l'nt.;rest ] Accept. Test ]

I 0 t s4 I 63 I 3 I

Table5. ]ntegrat|on Act_v|tyduring LifeCyft, Phues

3. PrototypinE

As can be seen, programmers readily flow from one

activity of a project to anOther-omore _ke a series of

rapids and not as a discrete set of waterfalls. Any model

that does not reflectthls cannot hope to accurately portray software development. Boehm has proposed a spiral

model [BOE 86] of software development which takes

some of this into account. In addltlon, the concept of

prototyplng has been proposed as an alternative concept.

The remainder of this paper will address the prototyping

issue.

The current model of software development is

becoming even more complex. As new techniques are

developed, how do they fitinto the llfecycle? For example, pseudocode is often written to describe a design.

This pseudocode is often iterated in greater detai! to

evolve into the source program. However, when does

pseudocode stop being deslgn and when does itbecome a

source program? Prototyping is another technique which

doesn't fit into this model well. in a prototype, the

W

w

=_.

V

m

i

U. i

m

5207

9

2-4

26rH ANNUAt. TECHNICAL SYMPOSIUM

WASHINGTON D.C. CHAPTER OF ACM

Gaithers_urg.MD*June 11, i987

l
v

developer builds some operational aspect of the system

and then evaluates the prototype with respect to some

criteria. _/here does thLq coding and testing fit? What

activity is this in the overall life cycle?

At NASA, a prototype was developed to investigate

implementation strategies for a new product. In this seetion, the role of the prototype will be described and the

resulting data collected from building the prototype will

be compared with the historical life cycle data presented

In the preceding section.

A prototype Flight Dynamics Analysls System

(FDAS) was implemented by NASA/GSFC. Data were

collectedduring the development of the system. For typicalflightdynamics software, which NASA has considerable experience in building, prototyping would be of limited benefitdue to significantknowledge of how previous

systems were built. However, in this case, FDAS was to

be a source code maintenance system to manage other

source code libraries.It would enable NASA analysts to

test new spacecraft orbit models by providing a humanengineered common interface which could be used to

invoke other fllght dynamlcs pankages. Since it was

unlike previous NASA projects,and since NASA personnel had limited knowledge of exactly how to build this

system, FDAS was a good candidate for prototyping.

The goal of the prototype Was to understand the

problem domain better. As such, an early decision was

made to build the system with every expectation of

throwing it away. If part of the source program could be

transferred to the final system, then that would be

viewed as an unexpected bonus. After the prototype was

built,it would be evaluated and from this experience the

requirements for a production version of FDAS would be

developed. Therefore, the basic Idea of the prototype

was to learn, and it fitsinto the lifecycle as part of the

requirements phase of Figure 2.

Thls definition of prototyp]ng differsfrom others

that view a prototype as a firstreleaseof a system. The

goal was clearly to be able to understand the problem

mad not to generate useable source programs. In another

study [BOE 84], prototyping was viewed as an |teratlve

process converging on the finalproduct.

We viewed the prototype as part of the requirements

analysis of the problem. However, since the prototype

was to execute, it itself had a full development life cycle.

As Table I previously showed, since FDAS was almost

34,000 lines of code and took about 93 staff months to

complete, it was a rather large project by itself.

FDAS was to be an interactive system. That meant

that the user interfacewas crucial.Because of this,itwas

determined that the prototype should emphasize that

aspect of system design.

The prototype was built in FORTRAN for a DEC

VAX II/780. In hindsight it is not clear that such an

Implementation was the wisest. However, at the start,

the problem did not seem that complex, and personnel

experience and available hardware and softwMe lent

Requirements

(Prototype System)

Requirements

Design

Code & Test

System Test

Acceptance Test

DESIGN

CODE & TEST

SYSTEM TEST

ACCEPTANCE TEST

Figure 2. Prototype as part of Software Life Cycle

themselves to a FORTRAN implementation. Since the

goal was to give the user a taste or what services the

system would provide, a screen simulation applications

package (e.g., Rapld/Use IWAS 86]), a very high level

simulation, or a 4th generation language might have been

adequate.

The use of FORTRAN, however, did have some

benefits. For one, it gave the developers experience In

using FORTRAN in a type of text-processing application

for which they had llttieprevious experience. One of the

reasons that the NASA group generally has high productivityis that they have had considerable experience in its

application area. By building the prototype in FORTRAN, they were using Brooks' second system property

where he advises "plan to throw one away" [BRO 75].By

building a first prototype in FORTRAN, mistakes would

undoubtedly be made. By planning on discarding the

prototype rather than patching it to correct errors, the

ultimate FDAS system should be more reliable and better

structured - even if it dld not turn out to be cheaper.

This by itselfis a valuable property, although it is not

clear that itisa measurable one on most projects.

2_TH ANNUAL TECHNICAL SYMPOSIUM

WaSHiNGTON D.C. CHAPTER OF ACM

Gailhersburg, MD*June 11, 198F 10

5207

2-5
t

A more important aspect of a FORTRAN amplementatiou (at le_t with respect to thls paper) is that the

FDAS prototype was a "typical" FORTRAN project.

Hence its llfe cycle characteristics and the data that were

collected could be compared with many other projects in

the NASA database. This would not have been potable if

some other mechanism (e.g.,simulation package of some

sort) were used.

In the next section, the prototype will be evaluated.

However, here *re some of our general conclusions. The

handling of requirements differedfrom a production system; FDAS requirements were incomplete when design

began. Unlike previous projects, they were not stated

precisely because aspects of the system were still an open

subject during development IZEL 84]; even identifying

the potential user community and its impact on the user

Interfaceand itseffecton "assumed computer experience"

was stillbeing considered. Dates for completion of each

phase were more flexlble than in the historical data and

milestones were less rigid than in a production development. During other phases, requirements were generally

modifi•ble which in turn affected g]] activities in each

phase.

More time was spent in design, than is usual for a

typicalproject. Unlike other NASA projects, an exten-

_ve r_view process took place almost weekly as design

decisionswere made and altered. The coding and testing

effortsbad no formal review. AJthougb status meetings

were held almost weekly, the developers placed less

emphasis on testingthan w_th a production system; and

since the prototype had • very llmlted lifetime,features

thai seemed well understood but cumbersome to implement were deleted from the requirements. According to

the finalreport, coding took less time than in previous

projectsbut testing did consume the same amount of

effort.Very littleeffortwas spent on acceptance testing,

sincethe effectiveHfe of the prototype was short.

4. Evaluation of Prototype

In • manner similar to the 13 other NASA projects,

the FDAS project was analyzed by phases and activities

usingdata in the SEL database.

4.1. Phase Analysis

Data ¢ollectlon based on phases is shown in Table 6.

The effort expended for design, coding, and testing were

romparahle, hut notice that acceptance testing was only

1.3c'_or the prototype effort,but 12.7% in the historical

d_:a. %%3th • limited lifetime,reliabilitywas a ]imlted

b,ture. As long as the system worked for evaluation, it

• _ tdeq,•te. In addition,integration testlngtook 10%

m_re effort(26/_ compared to 16%) in the prototype.

P*e believe this was mostly due to "schedule slippage" as

the complexity of the prototype caused activities to be

ek[syeduntil the end.

DEVELOPMENT EFFORT BY PHASE DATE

(13 Project_ v, Prototype FDA.S)

PROJECT DESIGN CODE INTEG. ACCTST

2 t6.2 48.4 123 162

3 21.8 479 17.4 129

4 35.9 39.5 24_5 O.l

5 18.2 68.11 13,0 00

6 IS.3 48.8 109 24.3

7 19.0 5,0.4 14.9 157

8 22.9 48.4 13.0 15.B

9 _,6 68.3 8.1 II

I0 _4.4 44+§ _0.2 108

ll 22.7 39.4 21.4 "165

12 16.9 53.t 109 lg,l

13 28,2 43.5 20.1 8.2

Average _.0 49.'. 16.2 12.7

FDAS 270 45.3 _.4 1.3 =..

Tzble e. $ottwzre Dev¶[0pment Effort by ,_htte

4.2. Activity An&lyais

In the previous subsection, we viewed effort by

phase date. Table 7 displays the actual activities of

deslgn, coding and integration test effortindependent of

phase. In this case the resultsdiffer.Usually during the

design phase, coding and testingactivitiesbegins On some

modules, and in the code and unit test ph_e, additional

design activity continues. Integration testing begins as

soon as coding and unit testing of a component completes. Similarly, during the testing phase, any errors

that were uncovered might require substantial redesign

and recodlng. Comparing with Table 8, we dlscover that

most NASA developments have additional design effort

later [n the lifecycle to raise tots( design effortfrom 22_

to 25.6_. In the FDAS case, total design dropped from

27% to 25_, meaning that actlvhles-_t_-er d_an design

occurred in the design phase. In both cases, activities

other than coding occur during the coding phase since

actual codin¢; activity was only 30.5_ and 17.6%

respectively,as opposed to the 45+% of effortof the codIng phase (Table 6).

Comparing FDAS with the 13 other developments,

design effortIscomparable at 25_o, but the code and unit

test effort and the integration test effort were different.

Due to the wide variability of the "other" category of

Table 7, Table 8 presents the same data as relative percent for Design, Code, and Integration testing only. This

shows the differences more clearly.

No formal review was performed on the prototype

durlnz coding and unit testing. Because of the decision

to delete hard-to-build but understood features that dld

=

m

i

r

wP

Sl

m

W

5207

2-6

28TN ANNUAt TECHNICAl. SYM_D_UM

Gaithers_ur o, MO.June 11, 1987

m £
V

_z

!

DE'VELOPMEHT EFFORT B'Y AC'rP_'rY' IN ALL PHASES

(I:_ Proltcu vs pr0tor._,P,FDA$).

PROJECT

NUM

1

2

3

4

6

4

7

6

g

I0

11

12

13

A.rqe

DESIGN CODE

17.4 064

301 394

2? 3 _7

310 35 $

149 21 6

110 139

613 435

X9 3"/3

293 3t 0

¢37 46S

32.9 363

2s_ 3os,

25 o tT 6

IN'lEG OTHER

ACT (To) ACT (,_1

04 .M3

201 ¢T

• |93 342

60 380

¢4 24 I

2410 34j_rz

143 396

93 _6

169 64

61 t64

IT2 225

240 sg

166 156

t6 0 28g

'J6I 323

T_t,k 7 Sdtw_e De.lopm4mt ,_'oh by Activity

not effect the FDAS evaluntlon, coding wu quite

straightforward. Most o/' the easy coding was completed

in a rather short time, and the more dlmcuJt coding

aspects were simply not implemented. As Table 8 indicates, at 26% coding, FDAS had the lowest relativecod-

]ng effortof any of the 14 measured projects. The next

lowest wu 30.8c_'0and the average over all 13 was 42.2%.

In addltion, while in mc_t projects the design and

integration testing efforts were le_ than the codlng

activity,in FDAS both were almost 50_0 greater than for

coding (about 37_ for each compared to 26_ for codINK).

PER CENT EFFORT IN EACH PHASE

(13 ProiecU vs Prototype FleAS1

PROJECT DESIG-N CODE&UNiT [NTEG.

NUM ACT(%) ACT(%_ AC't(%I

l 30.9 37.5 22.0

2 33.3 43.T 23.0

3 39.9 30.9 29.3

4 44.0 46.3 0@.7

5 40.8 48.9 12.3

0 24.6 35,9 30.S

7 33.5 42.9 23.9

$ 32.2 40.7 27.1

I0 4e.8 4s.7 07.S

It _.8 40.1 22.1

12 25.2 49.4 25.5

15 38,{$ 43.0 18.4

AverMe 36.2 42.2 21.0

FDAS 389 . .280 37.1

Table 8. Relative Activity

This apparent short circuiting of coding, however,

appeared to have a detrimental effect on testing, which

took s relative 37.1O0 of effort u opposed to 21.6°:o on

other projects. Only one other project (6) took as much

effort(39_) and from Table I project 6 was the most

costly,where you might expect an excessive need for testing.

Based on the original productivity rate of 1.4 source

lines of code (SLOC) per hour on most NASA pro_ects

[BAS 81 I, FDAS with s size of 33,967 SLOC had a

productivity rate of 2.4 SLOC per hour. (Note: the average project size of 57,890 SLOC of Table I cannot simply

be divided by the average effort,of 13,552 hours since

most NASA projects reuse some code from previous

terns. Table I is total system size, and the productivity

rLte is for new linesof code.)

4.2.1. Design Effort

A true picture of devdopmeut can be achieved by

investigating actual activity during each phase.

Although design Is supposed to occur prindpally during

the design phase, for both the 13 older projects and the

FDAS prototype s comparable one half of the total

design effortoccurred during the design phase, and equal

amounts wen distributed through the rest of the llfe

cycle (Table 9). This repeats Table 3 in more detail.

Only 2% of the design of FDAS occurred during the

acceptance test phue in the prototype, prineipally

because the FDAS acceptance testing phase was so short

and the few errors that were found did not get

redesigned and corrected. For the historicaldata, the

6.4O0 of design occurrlng during acceptance testing

represents errors found in testing that required source

code to be redesigned.

DESIGN ACTrVITY EFFORT IN EACH PHASE

(13 Proiecta vs Procotwe FDAS)

PROJECT

!

2

3

4

S

9

0

10

!|

12

13

Averl#l

FDAS

DESIGN CODE

PHASE(%) P_E{%)

41J$ 33.9

53.8 31._

33.3 37.1

45.3 32.6

17.4 "(S9.1

_8.9 30.7

83.0 15.3

28A 50.9

81.8 38,2

$7.8 27.2

58.7 13.7

58.9 32.8

60.S 24.7

49.2 34.1

49.8 2_ 9

IY;'rEG.

TEST(%)

10.0

9.2

19.7

_.0

13,3

4.3

9.8

7A

0.0

7.0

19.87

5.9

11.9

10.3,

19.B

ACC.TST.

14.3

9,0

9.0

0,1

0.0

14.1

8.0

0.0

9.0

10.0

2,4

2.0

8;4

1.7

Table O. Desilp_Activity E/fort

4.2.2. Code & Unit Test Effort

The code & unit test activities in the prototype,

however, represent a departure from the older projects

(Tah(e I09. In most developments, about 7o0 of the coding is completed during design (although it varied from

0°:o to 22°:0 in the 13 other projects). Implementation

often begins as some components become completely

specified. However, with FDAS, due to itsgreater uncero

26TN ANNUAL TECHNICAL SYMPOSIUM

WASHINGTON 0.C. CHAPTER OF ACM

Gaithersburg, M0,June 11, 1987 12

_==

5207

2-7
talnty, no coding occurred until the development team

really understood the deslg•, i.e., until the coding phase

began. For most projects, 70% of the total code and

unlt test effort ]s [n the coding phase, but In the prototype almost 96% of the effort was during coding. Coding

often extends through acceptance testing, but with

FDA$'s relatively light acceptance test, few critics] errors

were found $o [|ttle effort was spent ]n trending during

test. Coding and testing need to be carried out on the

full system for every change or modification of the

design, hut |n the prototype it was not necessary to code

the new design.

CODE & TEST ACTIVITY EFFORT IN EACH PHASE

(]3 Proieets vs Fmtotyve F!D/_S}

PROJECT

1

2

2

4

5

6

7

$

2

10

it

12

12

Aversfe

FDAS

DESIGN CODE

PZ.t,.sr_%) Pz..Z,-_EI°_)

1,4 78.$ "

n.O 72.8

22.2 58.2

15.4 $8.8

21 P. 68.7

0.$ 77.5

1-$ 73.0

14.7 54.7

3.2 91.1

0.0 75.0

0.3 74.8

4.S 8&8

s.9 7.0.3

0.0 959

_G. ACC.TST.

TEST(%} j P_S_%}

11.$ 9,1

18.T T.S

11.8 9.8

_IS.I 0.I

10.1 0,0

t|.Z t0.]

t5.8 g.2

21.0 0.7

5.1 0,6

22.5 4.$

20,1 7.2

8.3 1O.O

_.9 4.9

15.9 6_9

4_1 0,0

T_le 10. Oode& Unit Tat Activity F.Jort

4.2.3. Integration Tat Effort

Integration test effort k distributed through all

phases 1• the collected projects with more effort (43%)

durlng the code _ unit phase tl3a• 1• either the i•tegrstion ph_e (26%) or the acceptance test phase (26%)

(Table 11). In genera], almost 50% of all |ntegration testing occurs during design and coding phases. In FDAS,

this effort wu delayed with about two-thlrds of all

integration activities in the integration phase. This wu

due to delaying the i•teKratlo• until more pieces or the

system were completed.

4.2.4. Other Activity Effort

The Other category couslsts of activit|es such u

travel, compJetlon of the data collection forms, meetJnp,

or training. While these activities are often Ignored i•

most life cycle studies, the costs are significant. Typically, about 29%-of act]vitles are in thls category and of

the 13 met, ured projects, "other" consumed m_re-:than

one-third of the effort o• 6 of them (Table 7). FDAS

used a comparable 32% "other'. As see• l• Table 12,

the prototype devoted more effort to the design phase,

mainly for meeting, traveling, and tra]n|ng due to the

extensive unknown quality of the design at the beginning

5207

INTECRATION ACTIVITY EFFORT IN EACH PHASE

PRO JECT

NUM

1

S

5

4

$

6

7

$

1'o

11

12

12

Aversle

FD,_

DESIGN CODEk_IT INTEG.

PHASE(_) PI-L_) TES.TC% }

0.0 17.8 17.4

0.0 45.2 _0.1

$.1 53.2 21.1

21.0 30.3 393

H.4 71.0 0.O

I.O 40.9 IT,6

0.5 54.1 _.3

2,9 33.8 19.2

0.0 00.4 29.2

0D 23.1 41.$

0.O 3A 4 35.I

0.1 32.7 2'2.4

1,5 49.6 '/S.8

4.T 434 _ 1

0.0 34.5 e2.7-

Table II. _telrmtia8 T_ Activity F__ort

ACC,TST.

PHASE{%}

54.7

24.T

18.9

0.0

0.0

40.5

19.2

44A

4.4

35.5

=8.$

44.8

20.2

25.8

2.8

of the task. The acceptance test activity is low for the

slm[lar t'eason _ th_at _e p_rototype system had few users of

short duration Lndthereforc no detailed tests. On the 13

collected projects, the Other activities are distributed

more uniformly during all phases, including the acceptance test where there is • need to test before _ctua]ly

turning the system to the user.

OTHER AOTrVITIES EFFORT IN EACH PHASE

PROJECT

1

2

3

4

$

S

7

8

g

10

11

12

IS

(13 Pr_iccts

DESIGN

2&3

0,0

_!.7

45.2

U.O

18.2

14.4

2_.5

I3.g

12.4

21_4

4T .5

42.5

Average 23,1

FDAS 451

vs Prototvve F'DAS)

G'ODE_TST E_TEG.

PRAS._%) T_ST(%)

32.2 18.1

0,1 26.4

47.8 Id.8

30.2 23.8

S7.7 21._

44.2 g.0

51,6 14.5

47,7 11.4

_,_,5 tS.T

_.2 35.9

32. ') I8.g

46.8 4.6

30.0 12.7

41.2 17.8

38.S 153

r'

AC_,TST,

PHASE(_)

_e.5

_4.6

133

00

0.0

283

19,5

14.4

0.0

21.5

27.8

1.$

14.2

17.9

0,3

Table 12, Other Activitie_ Egort

&. Conclualoml i: : :- - :- -

In this paper we have collected data on many

software projects developed at NASA/GSFC and compared them with a new prototype development. By using

data from the SEL dstahue, it appears clear that the

software development process does not follow the waterfall life cycle. It also appears that the prototype develop13

2_TH ANNU&t. TECHNtC&_. SYMPO_dUM

WASHIN_ITON D.C. CHaPTEn OF ACM

Gaithersbur_, MO.June 11, 1_7

2-8

W

me

w

W_

n

W

'qm

i

W
ment follows a similar life cycle pacte'rn as ot_er software

projects. Although a single data point (the prototype)

does not give definitive answers, it does give some trends

that are of interest.

Both approaches have similar software life cycles,

but the effort distributed over each ph_ differs. The

coding |n the prototype was more ad hoe, therefore testIng became more involved. Integration testing was

harder in the prototype because of the false assumption

that reliability was not a central issue. The production

developments devote more effort in coding than in testing

(Table 7).

While not inexpensive, the prototype appears to he

successful. Several design decisions turned out to be

partially faulty when the prototype was tested. The

humma computer interface has been redesigned.

In fact, after completion of the prototype, several

screen simulation systems were used to model a user

interface, mad a more hierarchical menu model was

developed. Without the FDAS experience, NASA might

have implemented a system where users had no real

experience until the large Implementation would be too

far along to change adequately.

The underlying execution model of FDAS became

better understood. As a source code control system, the

separation of the FDAS code and the user's flight dynamics application code became clearer. Most user programs

would be FORTRAN (at least initially); however, other

languages (e.g., Pascal, Ada) would be used in the future,

while it would not matter to the user In what language

FDAS wu itself written.

FDAS included a prototype preprocessor to add

abstract data types to FORTRAN. Thls preprocessor

was initially tied directly to the FDAS implementation.

It is now somewhat |ndependent to allow for other

preprocessors later. The FORTRAN preprocessor, call

OPAL, for Object Programmlng Applications Language

[CSC 86], is a more rffit_onal extension of FORTRAN

with data structures useful for flightdyaamlcs appliesalong, such as vectors, matrices, and quaternlons. The

decision was also made to move away from FORTRAN,

and the system itself is being implemented in Ada_

although it will initially protein FORTRAN application

code.

A new production FDAS implementation would

avoid many potential pitfallsdiscovered via the prototype. (_urrcntly the production version of FDAS is under

development, and its design has benelqted greatly from

the earlierdevelopment. We willhave to wait for completion before fully evaluating this process. It is quite

clear,however, that FDAS willbe a much better product

that ifthe prototype had not been built.

Prototyping probably increues the cost of the system, but it greatly increases its quality. It gives a flavor

to the end user of what the system can do and how it

can perform the task, especiallyin a nonfamiliar environmeat. It provides the developers a "second system* effect

for perfecting a design.

8. Acknowledgement

This work was partiallysupported by grant NAG$-

368 from NASA Goddard Space Flight Center to the

University of Maryland. Judin Sukri provided most of

the analysis of the data used in thisreport. We alsowish

to icknowledge the help of Frank McGarry of

NASA/GSFC for his aid in collectingthe data used hem

and for their interpretation.

7. References

[BAS7sl

Basill, V. R. and Zelkowitz M. V. "Analyzing

Medlum-Scale Software Development" 3rd International Conference on Software Engineering, Atlanta,

pp. 118-223, (May 1978).

[BAS81]

Basill, V. R. and Freburger, K., "Programming

Measurement and Estlmatlon in the Software

Engineering Laboratory" The Journal o/ S_latem 0

So/aware, Vol. 2, pp. 47-,57, (1981).

[BOE 84]

Boehm B., Gray, T. and T. See Waldt, Prototyping

vs. specifying: a multlproject experience, 7th International Conference on Softwrae Engineering,

orlando, FLA, March 1984, pp. 473-484.

[Bozs61

Boehm B., A spiral model of software development

and enhancement, A CM $o/tware Engineerin¢ Notes

11, 4, August 1986, pp. 22-42.

[BRO 75]

Brooks, F., The _4ythical Man Month Addison WesIcy, 1975.

[csc s6]

Applications Software under the Flight dynamics

analysis system (FDAS), Computer Sclences Corporatlon, CSC/SD-86/6024, November, 1986.

[SEL 81]

McGarry, F. E. and Page, G. and et al.,"Standard

Approach to Software Development", NASA Goddard Space FllKht Center, Greenbelt, MD, (September 1981).

[gEL 82 l

McGarry, F. E. and Church, V. and Carl, D. and et

al., "Guide to Data Collection', NASA Goddard

Space Flight Center, Greenbelt, Md, (August t082).

26TN ANNUALTECHNICALSYMPOSIUM

WASHINGTOND.C. CHAPTEROFACM

Gaithersburg, MDeJune 11, 1987 14

5207

2-9
[WASS3J

Wuserman, A., "Software Engineering Environment", Advance# in Competer, Vol' 22, pp. 110-150,

(1983).

[WASSe] - _....

Shewms3ce, Building reliable interactive information

systems, IEEE Transactions on So/twdre Engineerinf, Vol. $E-12, No. I, pp. 147-156 (January, 1986).

[z_ 7el

Ze]kowitz, M.V., "Perspective on Softw_-e Engineer-

|rig", ACM Computing Surveye, Vo|. I0, NO. 2, pp.

108-216, (June 1078) .......

[zE_,s4]

Zelkowitz, M. V. and Sukrt, J., "Technique for Sxlb-

]ective Evaluation of Prototyp|n$ Des;:gn_, Proceedin# of Ninth Annual Software Enfineering

Workshop, NASA GoddLrd Space Flight Center,

Greenbelt, MD, (December 1984).

M

lp

N

I

J

5207

15

2-10

26TH ANNUAL TECHNICAL SYMPOSIUM

WASNIN(rrON D,C. CNA_EI_ OFACM

Gaitbersburg, MDoJune 11, i987

j

,U

W
Measuring Software Design Complexity

D. N. Card and W. W. Agresti

Computer Sciences Corporation, Silver Spring, Maryland

v

=_.__=

Architectural design complexity derives from two

sources: structural (or interrnodule) complexity and local

(or intramodule) complexity. These complexity attributes

can be defined in terms of functions of the number of I/O

variables and fanout of the modules comprising the

design. A complexity indicator based on these measures showed good agreement with a subjective assessment of design quality but even better agreement with

an objective measure of software error rate. Although

based on a study of only eight medium-scale scientific

projects, the data strongly support the value of the

proposed complexity measure in this context. Furthermore, graphic representations of the software designs

demonstrate structural differences corresponding to the

results of the numerical complexity analysis. The proposed complexity indicator seems likely to be a useful

tool for evaluating design quality before committing the

design to code.

1. INTRODUCTION

Typically, design is the earliest stage of software

development at which the pending software system is

fully specified and in which the system structure is

clearly defined. Design usually proceeds in two steps--

architectural, then detailed design. This study only

considers the former. Throughout the following discussion, "design" will refer to architectural design unless

otherwise indicated. Assessment of the quality of a

software design rates high in the priorities of software

developers and managers. However, the multitude of

potentially conflicting design objectives, methods, and

representations, as well as a lack of appropriate data,

have hindered the development of effective measures of

software design quality.

One quality attribute, complexity, has been studied

extensively. Early investigations [I, 2] focused on the

internal organization of individual programs or subprograms rather than on the structure of software systems

Address correspondence to David ._1.Card. Computer S¢ienc_

Corporation, 8728 Colesville Road, Silver Spring, MD 20910.

"The ,[o_mal of Systems =r_l Software S, 185-197 (1988)

© 1988 E|scviet Science P_blishin$ Co., Inc.

composed of large numbers of subprograms (or modules). More recently, complexity studies have attempted

to consider software systems [3, 4]. Many of these

approaches require extensive analysis (usually special

tools) to compute values of the complexity measures

proposed. Moreover, few of these measures can be

computed at design time. The objective of this study was

to define some "simple" complexity measures that

could easily be derived during early design.

The initial investigation considered many existing

models of software complexity but did not find any of

them suitable for this application because 1) necessary

data were difficult to extract or compute, 2) required

information was not available during architectural design, and/or 3) our data data did not support the model.

For example, all of these reservations apply to software

science ill; see Card and Agresti [28].

This paper explains a new approach to measuring

software design complexity that considers the structure

of the overall system as well as the complexity incorporated in individual components. The measures derive

from a simple model of the software design process.

Analysis of data from eight medium-scale scientific

software projects showed that the complexity measures

defined in this report provide a good estimate of the

overall development error rate, as well as agreeing with

a subjective assessment of design quality. Furthermore,

differences in design complexity indicated by the complexity measures also demonstrated themselves in design

profile graphs.

This analysis relied on data collected by the Software

Engineering Laboratory (SEL) from eight spacecraft

flight dynamics projects. The SEL is a research program

sponsored by the National Aeronautics and SFace

Administration [5]. It is supported by Computer Sciences Corporation and the University of Maryland. The

objectives of the SEL are to measure the process of

software development in the flight dynamics environment at Goddard Space Flight Center, identify technology improvements, and transfer this technology to flight

dynamics software practitioners.

185

0164-1212/88t$3.50

5207

2-11
186

2. NATURE OF DESIGN COMPLEXITY

Architectural design is the process of partitioning the

required functionality and data of a software system into

parts that work together to achieve the full mission of the

system. Thus, architectgral design complexity can be

viewed as having two components: 1) the complexity

contained within each part (or module) defined by the

design, and 2) the complexity of the relationships among

the parts (modules). In the following discussion, we will

refer to design parts as modules, in the sense that a

module is the smallest independendy compliable unit of

code [6]. Each design part will eventually be implemented as a software module. In the FORTRAN environment of the SEL, modules correspond to subroutines.

Many different approaches or methods achieve the

same design result: a high-level architectural design and

an integrated set of individual module designs. The

detailed design (e.g., PDL) developed to implement the

work assigned to a module provides another source of

complexity that is not analyzed here. It is not the intent

of this paper to address whether specific design methods

result in lower-complexity (or better) design products.

Rather, its objective is to demonstrate a complexity

measurement approach that can be applied to a wide

range of such products, regardless of how they were

produced. The authors recognize that correct design

practice is essentia! to achieving good designs. Generally, this report shows that the conditions that result in

lower values of the complexity measures are consistent

with accepted design practices.-

Of course, any Complete design must include nonmodules such as files and COMMON blocks (in FORTRAN). Furthermore, partitioning is not the only design

process. This proposed model only attempts to capture a

subset of all the possible factors in complexity. As

Curtis [7] points out, complexity depends on the

perspective from which an object or system is viewed.

This paper examines software complexity with respect to

the difficulty of producing the designed system (for

example, the difficulty of changing the implemented

system is not considered). The following discussion is

intended to illustrate the line of reasoning followed in

developing the model and measures. It should not be

construed as a mathematical proof that this model is a

necessary and sufficient explanation of complexity.

2.1 A Design Model

One common approach to design is functional decomposition (the basis of structured design [6]). It results in a

hierarchical network of units (or modules), For any

module, workload consists of input and output items

5207

D. N. Card and W. W. Agresti

WORKLOAD

(INPUT_OU'rPUTDATA)

PROCESS

WORKPERFORMEu ,

(LOCAl,.COMPLEXITY) ,._¢¢'_.. ,.

I _Jllll( r.r_A.,_:uum,_L"

CONNECTIONSTOWORKDEFERRED

(STRUCTURALCOMPt.EXn%3

Figure. L Decomposition model of software design.

(data couples) to be processed. At each level of

decomposition, the designer must decide whether to

implement the indicated functionality (perform the

work) in the current module or defer some of it to a

lower level by invoking one or more other modules (via

control couples). Deferring functionality decreases the

local (intramoclule) complexity but increases the structural (intermodule) complexity (see Fig. 1). Similar

decisions also must be made when following other

design approachcs(e.g:.object oriented [8]), ....

The internal design of a module (how the work is

performed) may contribute procedural complexity, but

that is outside the scope of this paper. Of course, many

early studies of software complexity ('e.g., [2]) focused

on process construction. The distinction made here

between local and procedural complexity parallels the

distinction between the specification and the body of an

Ada* package.

Thus, architectural complexity is a function of the

work performed (within modules) as well as the connections among the work parts (modules). Effective design

minimizes work as well as connections. This argument

leads to the following formulation for the total complex'-

ity of a software design:

C- =S- +L- (1)

where

C- -- total design complexity

S- -- structural (intermoclule) complexity

L- = local (intramodule) complexity

* Ada is a registeredtrademark of the U.S. Government (Ada Joint

Program Office).

2-12

V

w

m

w

m

IlI

m

m

=.i

m

m

m

w

m

m

m .
v

-s._.-

Measuring Software Design Complexity

That is, the total complexity of a design of given

complexity C- can be defined as the sum of intermodule plus intramodule complexity. In this simple model,

all complexity resides in one or the other of these two

components; hence, they are additive. These complexity

components correspond to the structured design concepts of module strength,:.(or cohesion) and coupling

defined by Stephens et al. [6].

2.2 Relative Complexity

Because projects iand designs) vary greatly in terms of

magnitude, a measure of relative complexity ultimately

may prove more useful than total complexity. Dividing

by the number of modules defined in the design

normalizes these complexity measures for size so that

designs of different magnitudes may be compared:

C=S+ L (2)

where

C = C-/n (relative design complexity)

S =S-/n

L =L-/n

n = number of modules in system

Although individual modules may vary greatly in size in

terms of lines of source code, the module, as it is used

here, is the unit of design. Hence it is the appropriate

normalization factor. The rest of this discussion will

concern relative complexity.

3. DEFINITION OF COMPLEXITY MEASURES

The next sections define measures for each of the two

components of relative complexity just identified in

Equation 2. The measures incorporate counts in the

design characteristics (calls, variables, and modules)

identified in the model. (Table 1 summarizes some

design measures from the modules studied in this

analysis). The following sections also discuss methods

and consequences of minimizing complexity as defined

by this model.

Table !. Design Measures Summary

Minimum Mean Maximum

Module size I 66 603

Fanin I 1.3 16

Fanoot 0 2, 8 27

I/O variables I 24 237

Level 2 6. I 11

Note: _tsed on 1.142 newly developed module_t.

187

3.1 Structural Complexity

Structural complexity derives from the relationships

among the modules of a system. The most basic

relationship is that a module may call or be called by

another module. The structurally simplest system consists of a single module. For more complex systems,

structural complexity is the sum of the contributions of

the component modules to structural complexity. These

potential contributions are occurrences of fanin and

fanout as noted by Henry and Kafura [9], as well as by

Belady and Evangelisti [3]. (Fanin is the count of calls to

a given module. Fanout is the count of calls from a given

module.)

In the SEL data analyzed (see Table I), multiple fanin

generally confined itself to modules that were simple

mathematical functions reused throughout the system.

Consequently, fanin did not prove to be an important

complexity discriminator. On the other hand, fanout

proved to be highly sensitive, as indicated in a previous

study [101. Counting fanout only also ensures that each

connection is counted exactly once. Note that lower

fanout indicates less coupling in the sense that there are

fewer couples (without regard to their strength [1 1] or

type [61).

According to this model, a module with a fanout of

zero contributes nothing to structural complexity. However, the distribution of fanout within a system also

affects complexity. The interconnection matrix representation of partitioning used by Belady and Evangelisti

[3] suggests that complexity increases as the square of

connections (fanout). All descendents of a given module

are connected to each other by their common parent.

Then, for a fixed total fanout, a system in which

invocations are concentrated in a few modules is more

complex than one in which invocations are more evenly

distributed. These considerations lead to the following

formulation for structural complexity:

z_

S = -- (3)

/7

where

S = structural (intermodule) complexity

j_ = fanout of module "i"

n = number of modules in system

This quantity is the average squared deviation of actual

fanout from the simplest structure (zero fanout). Henry

and Kafura's term "(fanin * fanout) ** 2" [9] reduces to

fanout-squared when fanin is assumed equal to one (the

nominal case). Similarly Belady and Evangelisti's measure of complexity [3] is a function of the number of

nodes (modules) and edges (fanout) in a system or

cluster (partition).

5207

2-13
The fanout count defined here does not include calls to

system or standard utility routines, but does include calls

to modules reused from other application programs. A

reused module must be examined by the designer to

determine its appropriateness--as opposed to standard

utilities that are well understood by deve!opers.

b

3.2 Local Complexity

The internal complexity of a module is a function of

the amount of work it must perform. The workload

consists of data items that are input to or output from

higher or parallel modules. This definition is consistent

with Halstead's concept [1] of the minimal representation of a program as a function (single operator) with an

associated sct of I/O variables (operands). This workload measure parallels the idea of actual data bindings as

used by Hutchens and Basili [11].

Then, to the extent that functionality (-work) is

deferred to lower levels, the internal complexity of a

module is reduced. Averaging the internal complexities

of a systems's component modules produces its local

complexity. Most guidelines for decomposition-sUggest

decomposing into units of equal functionality. Assuming, for simplicity, that the workload of a module is

evenly divided among itself and subordinate modules

leads to the following formulation of Complexity:

U/

L = _ (4)

n

where

L = local (intramodule) complexity

u, = I/O variables in module "i"

.t_ = fanout of module "i"

n = number of new modules in system

The "+ l" term represents the subject module's share

of the workload (incidentally, it prevents the divide-byzero condition from arising when a module has no

fanout). I/O variables include distinct arguments in the

calling sequence (an array counts as one variable) as

well as referenced COMMON variables. An earlier

study [10] indicates that the presence ot" unrefei'enced

COMMON variables does not affect module quality.

Data item complexity is not considered here (only newly

developed modules enter into this computation).

Henry and Kafura [91 Used[the count of source lines of

code to represent intramodule complexity. However, as

used in Henry and Kafura [9], no matter how large the

module, its complexity would be zero if it had no fanout.

Basili et al. [12] showed source lines of code (size) to be

highly correlated (r = 0.79) with the number of I/O

5207

D. N. Card and W. W. Agresti

variables (operands). Another earlier study [I 3] shows

that high-strength modules [6] tend to be small. Consequently, the local complexity measure may be an

indicator of average moGule strength (or cohesion [6]).

3.3 Minimizing Complexity

Design complexity, as defined in the preceding sections,

can be minimized by minimizing its structural and local

components. However, these components are not independent. Both measures include fanout. Minimizing

structural complexity requires minimizing tl'.e fanout

from each module. For a given number of both modules

and total fanout, structural complexity is mimnized

when fanout is evenly distributed across all modules

(except terminal nodes, of course). On the other hand,

local complexity can be minimized by maximizing

fanout or minimizing variable repetition.

Repetition occurs whenever a data item appears in

more than One module as a calling sequence argument or

referenced common variable. Internal uses (including

CALLs to other modules) do not count as repetition. In

general, minimizing local complexity will produce

smaller modules (in terms of executable statements), but

is also may increase structural complexity disproportionately. For a given module with a fixed number of I/O

variables_ th6-'_nbu_il_a/-cOni/-_butes minimum complexity can be determined as follows:

e=f 2+ u/(f+ 1)

where

c = contribution of given module to total complexity

per Equations 2, 3, and 4

then

dc/df = 2f - ul(f + I) i

at minimum

0=2./'- u/(f+ 1) _

then

u = 2/(/+ I) z (5)

Figure 2 shows a plot of Equation 5 as a step function (to

reflect the discrete natures of u and f). It identifies the

fanout that minimizes complexity for possible counts of

I/O variables. For example, in the range from about 100

to 200 I/O variables, complexity is minimized with a

fanout of 3. Since very few modules include as many as

200 I/O variables, the plot indicates that the commonly

accepted range of values for fanout (up to 7 ± 2) is

much too large. Curtis [7] suggests that the popularity of

this bound derives from a misunderstanding of certain

psychological studies. This implication is consistent with

2-14

w

w

i

V

lw

W

W

m

l

W

L

v

m

Ip

D

II

m

W
Measuring Software Design Complexity

4oo-

>2

,,=,

<

<

>

-o

200,

10o

I I I I

2 3 4 5

OPTIMUM FANOUT {F')

an earlier study [10]. Furthermore, Constantine [6]

observes that most programs can be decomposed effectively into a common structure of three parts: input,

process, and output. Larger fanouts may indicate too

rapid decomposition. This result suggests than a fanout

of one is a reasonable value for modules with few I/O

variables.

In addition to the selection of an appropriate fanout,

design complexity can also be minimized by reducing

variable repetition, i.e., by not including variables

where they are not needed. Rigorous application of the

principle of information hiding [14] should reduce

variable repetition and, hence, local complexity.

Figure 3 shows two design segments of equal structural complexity: The number and distribution of fanouts

are identical. Each data couple represents a repetition of

the variable "X". Figure 3a traces this variable through

a design following strict topdown decomposition rules.

"X" appears in the higher level modules (A, B, D)

as well as in the lower level modules (C, E). Figure 3b

shows an alternative design with a horizontal transfer of

data that bypasses the higher level modules (for the case

in which modules A, B, and D do not actually use "X").

The local complexity of the intermediate modules (B, D)

in the strict top-down configuration (Figure 3a) exceeds

Figure 2. Selecting fanout to minimize complexity.

189

their counterparts in the alternative design (Figure 3b)

because their counts of I/O variables are larger.

Parameter transfer between hierarchically adjacent

modules (e.g., from B to A) produces a lower complexity than transfer via a global area when that is as far as

the data item goes. For a triplet connection (e.g., from B

to A to D), the two approaches have the same complexity ("X" counts twice in each). This implication is

consistent with the results of an earlier study [10].

Because this model emphasizes the number of data

couples rather than the nature of the coupling mechanism. it penalizes "tramp data" (data passed through but

not referenced by a module).

Rotenstreich and Howden [15] argue that both horizontal and vertical data flow are essential to good

design. Appropriate use of horizontal transfers prevents

data flows from violating levels of abstraction. COMMON blocks provide the only mechanism for horizontal

data transfers in FORTRAN. Figure 3 shows that

horizontal flow's can reduce the magnitude of the local

complexity measure in some situations.

Of course, a less complex design might also be

5207

2-15
190 D. N. Card and W. W. Agresti

PROC A ( ) [

/ \-/

PROC ClX, ) [

I

PROC E (X, I

(a) STRICT TOP-DOWN STRUCTURED DESIGN

U

u

m

mm

IB

GLOBALX

I PROC A [ ) I

/- \ /

,!

GLO8AL X

{b) LOWER COMPLEXITY WITH LATERAL TRANSFER

m

II

m

lib

m

IIB Z

B

W

Figure 3. Rcducin8 variablere_itit]_onto minimize _ompiexity.

have =fan0u{of-ohe {h_fea_ 6fPl_Oc _B having fanofitOf

two/_us_'_Si_c_rai complexity di-mihis_es_3 i_'ii.......

m i

produced by partitioning the work differently and

restructuring this des_gn._=l:rorexample, PROC C could

be invoked directly by PROC E (if the nature of the

problem permitted)_ This simple r structure would als o

be reflected in lower values of the complexity measures

defined by this model. (PROCs B and C would each

5207

2-16

4. EVALUATION OF COMPLEXITY MEASURES :

The value of the complexity measures defined in the

preceding sections was evaluated in two ways. First the

complexity scores for the eight projects were compared

with a subjective rating Ot'-desq_n-qiaa_hy us_n-g a I

nonparametric statistical technique. Then the complexity

i

g

-- z

i
Measuring Software Design Complexity

scores were compared with objective measures of

developmen t productivity ?rod error rate. This section

presents the results of the two evaluation approaches.

Productivity and error rates were computed using the

developed lines of code (DLOC) measure as defined by Project

Basili and Freburger [16]. A

Data for this analysis were extracted from the source n

code of eight projects by a specially developed analysis c

tool. However, software developers can easily extract at DE

design time the counts of modules, fanout, and I/O F

variables necessary to compute these complexity mea- G

sures. The eight projects studied were ground-based 8

flight dynamics systems for spacecraft in near-earth

orbit. Table 2 summarizes some general characteristics

of these software systems. The most recent project

studied was completed in 1981.

All of these systems were designed and implemented

to run under the Graphics Executive Support System

(GESS), an interactive graphics interface [17]. Consequently, GESS occupies Level 1 of each design hierarchy. GESS manages most external data interfaces for

these systems. It is not included in the complexity

calculations.

4.1 Subjective Quality

The eight projects were subjectively ranked in order

from best to worst, in terms of design quality, by a

senior manager who participated in the development of

all eight projects. Then, the four best-rated designs were

classified as "good' while the other four were classified

as "poor." Table 3 shows the results of that procedure.

The table also includes the computed complexity measures. Note that the four designs subjectively rated as

"good" also demonstrated the lowest relative complexity. The expert was not provided with specific criteria

for "quality," but later reported that perceived "complexity" played a major role in assigning scores.

Table 2. Project Characteristics

Total Percent Size Error

Project Modules Reused' (KDLOC_ Ratec Productivity_

A 158 11 50 8.7 3.5

B 203 34 49 8.0 2.9

C 338 32 106 4.5 4.7

D 2.59 84 37 4.0 4.7

E 327 24 83 4.5 4.8

F 393 47 79 7. I 4. I

G 199 49 57 7.2 2.3

H 245 43 56 6.6 2.4

• Perccm of local modules.

• Thousands of developed lines of code.

¢ EnmN per KDLOC.

• I_veloped lines of code per hour.

Table 3. Design Complexity and Quality

Complexity

Design Quality

S L C" Rating b Class

24.6 8.2 32.8 5 Poor

15.8 9.5 25.3 2 Good

11.8 12.1 23.9 3 Good

18.4 4.9 23.3 I Good

12.6 10.0 22,6 4 Good

22.3 7.3 29.6 6 Poor

18.3 10.8 29. I 8 Poor

19.2 7.3 26.5 7 Poor

• C = $ + L as pr_viomly defined (Equa.on 2).

t, Subjective evaluation (I = best. 8 = worst),

191

Although the correspondence between subjective design rating and numerical design complexity is not onefor-one, if the data are viewed as quality classes, they

provide persuasive evidence for a relationship. ¢If one

uses the Wilcoxon rank sum statistic the probability is

less than 0.02 that the observed good/poor grouping

could occur by chance alone.) The objective complexity

measure appears to capture much of the information that

a human observer includes in a subjective evaluation of

design quality.

4.2 Performance Prediction

The other test of the value of these complexity measures

is their ability to predict software development performance in terms of the productivity and error rate ultimately realized by the development team. A more

complex design will be more difficult to develop into an

acceptable system. However, let us first define a few

relevant quantities:

Developed lines of code--all newly developed source

lines of code plus 20% of reused source lines of code

[16].

Errors--conceptual mistakes in design or implementation. An error may result in one or more faults (code

changes). These were detected during integration and

system testing (after unit testing).

Effort--hours of work by programmers, managers, and

support personnel directly attributable to a project.

Productivity--developed lines of code divided by effort

(in hours).

Error rate--total errors divided by developed lines of

code.

The developed lines of code metric attempts to account

for the lower cost and error rate attributable to reused

code. Table 2 shows the developed lines of code,

5207

2-17
192

REQUIREMENTS

AND

11%

OTHER .--_

LANGL

ENVIRONMENT

6%

D. N. Card and W. W. Agresti

U

m

IB

Figure 4. Source of software errors (from Weiss

and Basili [i9i). Note: Excludes clerical/transcription errors.

m

IP

IB

productivity, and error rate for the eight projects. Note

that together these projects represent more than. 1,000

individual new modules produced by about 50 different

programmers.

Designers and researchers commonly assume that

higher complexity increases the propensity for error.

Potier et al. [18] observe that the imple-rnentatlon

process consists largely of translating design specifications into a programming language. It usually does not

add complexity to a system. Weiss and Basili [19] show

that the bulk (74-82%) of all nonclerical errors reported

in three of these projects were related to design,

although sometimes at very detailed levels. Figure 4

shows the n_ddi/ir_-h'istribution of errors for the l_l;6jects

studied by Weiss and Basili [19]. Very few of these

errors are true programming errors. Of course, many

detailed design and" implementation errors are detected

during code reading and unit testing (not counted here).

In this context, clerical/transcription errors can be

regarded as random.

Figure 5 illustrates the relationship between design

complexity and error rate. It shows that design complexity effectively predicts the total error rate for development projects. Complexity (as measured here) accounts

for fully 60% of the var{ation in error rate. As seen in

Figure 5, all but one of the points lie very close tothe

regression line. In that case, Project B, the implementation team consisted of an unusually large proportion of

junior personnel (although its design team k,_-comparable to those of the other projects). Conseqoentlyl it

seems reasonable to find a higher error rate than would

be indicated by design complexity alone.

Figure 6 illustrates the relationship between design

complexity and productivity. No clear relationship

emerges. However, as noted elsewhere [20], many

important factors external to the development process -

(such as computer use and programmer expertise)

strongly affect productivity. In this case (consistent with

[201), computer-hours-per-thousand-developed-lines of

code correlates strongly with the residuals from the

Figure 6 relationship (r = -0.79). Computer support

was only provided to these projects for detailed design,

coding, and testing, so it does measure a different set of

activities. However.the srnail sampie size (at the project

level) inhibits evaluation of a more complex model

incorporating both complexity and computer use.

In this organization, the design team forms the

nucleus of the implementation and test teams. Additional

personnel join as they are needed. Thus, the complexity

measure provides an early indication of the performance

of the deveiopmenfteam as well as of the quality of the

design. A good design team is likely to be a good

implementation and testing team, although productivity

may be difficult to predict.

5. REPRESENTATION OF DESIGN STRUCTURE

The numerical quantities defining these complexity

measures are the number of modules, fanout, and I/O

variables. Table 4 shows the distribution of these

18

i

!!

W

W

j

mI

5207

2-18

I

I
Measuring Software Design Complexity

I0

¢.3

q

Q

hE

n,-

gJ

O.

tw

O

re"

..=.

8

i7

6

5

4 _

p

3

2

1

"QE

• D

0 C

| i - ! I

OB

I

25

H f

I I !

DESIGN COMPLEXITY

J

IO A

I""

r = 0.83

p(r = OI _; 0.02

193

J

I I I * d I I

30 35

measures by hierarchical level for one project. This

design structure can be represented graphically, as

shown in Figure 7, by plotting the cumulative percentage of these quantities obtained at each level. Kafura and

Henry [21] employed a similar technique to show the

effect of design changes on complexity.

In this and subsequent plots, the design structure (or

profile) is simplified by combining all utility modules,

regardless of where they are invoked, into a single

deepest level of the design. That point is not plotted

(utility refers to new or reused modules that are invoked

from several different points within a design but not to

system or standard utilities). Levels greater than or equal

to 10 also are combined into a single level to facilitate

plotting.

As discussed earlier, the conditions that minimize

structural complexity result in an even distribution of

fanout. This produces an increasing growth rate in the

cumulative percentage of total fanout in the initial levels

of the design, followed by a gradual decrease in growth

rate as subtrees terminate. The percentage of modules is

driven by the fanout at the preceding level (minus calls

to utilities). Uneven use of utilities causes the module

line to fail to track fanout. Equation 5 showed that [/O

Figure 5. Relationship to error rate.

variables should be proportional to fanout in order to

minimize local complexity. Together, these conditions

define the shape of a good (low relative complexity)

design.

Figure 7 illustrates Project E, the design with the

lowest relative complexity. It shows three closely fitted

"S" shaped curves. Figure 8 illustrates Project A, the

design with the highest relative complexity. It shows

three separate and irregular lines. Profiles of the other

six projects fall in-between these two extremes in

correspondence to their measured complexity.

6. CONCLUSIONS

The complexity measures proposed in this report are

supported by substantial empirical evidence. The structural complexity component is similar to measures used

successfully by Belady and Evangelisti [3] and Henry

and Kafura [9] for other languages and application areas.

However, neither of these models, as originally formulated, fit the SEL data very well. The new model

5207

2-19
194

,tw

0

"v"

<

I--

0

Q.

g

5.0 m

4.0 _

3+0"

2.0"

v.-

O C

• 6

B

I I I I I I

25

H

D. N. Card and W. W. Agresti

_-,-_ O A

G

o

I r = - 0.49

| 1 I I ! I I ! I

30 35

DESIGN COMPLEXITY

tim

J

_P

W

l

m

!

IU

m

I

Figure 6, Relationship toproductivity.

demonstrated good agreement with subjective assessments of design quality as well as a numerical measure

of error rate. Moreover, all relevant measures can be

extracted at design time; the Henry and Kafura model

includes a code measure.

Table 4. Detailed Design Structure for Project E

Level

Module Average

Executable

Modules statements Fanout

Many software development methods, e.g., [22],

encourage trying design alternatives. Be:aus¢ software

developers can easily compute values for these complexity m_easures at design time, they seem likely to be useful

for assessing design quality and comparing design

alternatives before committing a design to code. Overall

high-complexity designs, as well as individual highcomplexity modules, can be identified. These measures

could be adapted to support a measures-guided methodology such as that. proposed by Ramamoorthy et at. [23].

Of course, complexity is not the only important

attribute of Software deSigns_ The minimum complexity

that can be achieved depends on the nature of the

Input/output application and the presence of design constraints. variables..................

Furthermore, design is not a deterministic process. The

2 2 91 6.5 45

3 4 37 4.8 9

4 19 59 3.6 29

5 93 67 2.2 26

6 62 59 2.0 24

7 54 59 1.8 20

8 33 37 1.4 14

9 7 19 0.7 8

zl0 2 8 0.0 5

Utilit)" 51 90 2,4 21

same design approach or method applied by different

individuals can result in different designs. These complexity measures help us to answer the question,

"Which is better?" However, it is not enough to

produce a design that shows low complexity scores.

Following a sensible and well-defined design method

ensures that the design problem is responded to while

minimizing complexity. Measures play a supporting role

in the design process.

5207

2-20

m

,j

J

I

g

i +

m

!

m

g

!
Measuring Software Design Complexity 195

8

<

I,,,-

Z

w

U

I.-

<

U

20

I0

/

/

/

/

2 3 4

I

/

/

I

/

I

--'_ FANOUT

I/0 VARIABLES

--_ MODULES

1 I ! ! I 1

5 6 7 8 9 > 10 UT

LEVEL

As Kearney et al. pointed out [24], ill-founded

reliance on complexity measures can degrade the software development process by rewarding poor programming practices. The approach to complexity measurement presented here satisfies the requirements of

Kearney et al. [24] for effective complexity measures by

clearly identifying the attributes measured, deriving

them from a model of the design process, suggesting

how they can be used in practice, and empirically testing

their validity. Nevertheless, more work remains to be

done.

Three aspects of this current complexity measurement

approach require additional research. First, methods of

incorporating external I/O (e.g., files) into the complexity measures must be developed. [n the systems studied,

much of the external I/O is handled by the GESS standard interface. Second, the application of the measures

Figure 7. Design profile of"Project E (lowest complexity).

should be extended to designs using different formalisms

intended for different implementation languages. "Modules" corresponding to FORTRAN subroutines are not a

universal design structure. The SEL has begun to study

the application of these measures to Ada design [25].

Third, the existence of two design complexity components suggests that two different types and distributions

of the design errors (in addition to programming errors)

also exist, as proposed by Basili and Perricone [26].

That needs to be verified empirically.

Finally, Kafura and Reddy [27] showed that similar

complexity measures appeared to related to software

maintainability. This suggests another new area of

investigation.

5207

2-21
196

ul,I

<

lc_

a,.

ul.I

IL

_r.

l-

:!

D

rj

100

9O

8O

7O

50-

40

3O

20

t0

/

/

/

#

/

/

/

/

/

! ! !

2 3 4 5 6

LEVEL

Figure g. Design profile of Project A (highest complexity).

ACKNOWLEDGMENTS

The authors would like to recognize the significant contributions

made to this work by F. E. McGarry (NASA Goddard Space

Flight Center), G. T. Page (Computer Sciences Corporation), and

V. R. Basili (University of Maryland). We would also like to thank

the referees for their useful suggestions for discussion and

clarification.

REFERENCES

! _ M. H. Halstead_ Elements of Softwarc Science, Elsevier

Science Publishing, New York, 1977.

2. T. L McCab¢, A Complexity Measure, IEEE Trans.

Software Engineering 2, 308_:-_3._2_0 (_1976)=....

3. L_ A. Belad)' and C. J. Evangelisti, System pan iiioning

and Its Measure, J. Systems Software 2, 23-39 (1981).

4. D. A. Troy and S. H. gweben, Measuring the Quality of

5207

/

/

/

/

/

/

2-22

D. N. Card and W. W. Agresti

__A FANOUT

lid VARIABLES

-_3 MODULES

I I I I i

7 8 9 z10 UT

Structured Designs, J. Systems Software 2, 113-120

(19gl).

5. D. S. Card, F. E. McGarry, G. T.-page, et al., The

Software Engineering Laboratory, NASA/GSFC, SEL81-104, 1982_

6. W. P. Stevens, G. J. Myers, and L. L. C0nstanti_.

Structured Design, IBM Systems J. 2, 115-139 (1974).

7. B. Curtis, In search of software complexity, in Proceedings, IEEE Workshop on Quantitative Software

Models. Computer Society Press, New York, 19-79, pp.

95-106.

8. G. Booch, Object Oriented Design, IEEE Trans. Software Engineering 12, 211-221 (1986). = _

9, S. M. Henry and D. G. Kafura, Software .$t_cture

Metrics Based on Information Flow, IEEE Trans. Software Engineering 7, 510-518 (1981).

10. D. N. Card, V. E. Church, and W. W. Agresti, An

Empirical Study of Software Design Practices, IEEE

Trans. Software Engineering 12, 264-271 0986).

I1. D. H. Hutchens and V. R. Basili, System Structure

=--

51

I

W

i

i

Z

i

g

M

I

I

m

m

I

Ill

w

m

m

i

im

!11

Ill

i

m

m

:I

m

I
Measuring Software Design Complexity

Analysis: Clustering with Data Bindings. IEEE Trans.

Software Engineering 1I, 749-757 (1985).

12. V. R. Basili, R. W. Selby, and T. Phillips, Metric

Analysis and Data Validation Across FORTRAN Projects, IEEE Trans. on Software Engineering 9, 652-663

(1983).

D. N. Card, G. T. Page:. and F. E. McGarry, Criteria for

software modularization, in Proceedings, IEEE Eighth

International Conference on Software Engineering.

Computer Society Press, New York, 1985, pp. 372-377.

14. D. L. Parnas, On the Criteria to be Used in Decomposing

Systems into Modules," Commun..ACM 15, 1053-1058

(1972).

15. S. Rotenstreich and W. E. Howden, Two-Dimensional

Program Design, IEEE Trans. Software Engineering

12,377-384 (1986).

16. V. R. Basili and K. Freburger, Programming Measurement and .Estimation in the Software Engineering Laboratory, J. Systems Software 2, 47-57 (1981).

17. Computer Sciences Corporation, CSC/SD-75/6057,

Graphics Executive Support System User's Guide,

1975.

18. D. Potier, J. L. Albin, R. Ferreol, and A. Bilodeau,

Experiments with computer software complexity and

reliability, in Proceedings, IEEE Sixth International

Conference on Software Engineering. Computer Society Press, New York, 1982, pp. 94-101.

19. D. M. Weiss and V. R. Basili, Evaluating Software

Development by Analysis of Changes: Some Data from

the Software Engineering Laboratory, IEEE Trans.

Software Engineering l 1, 157-168 (1985).

13.

197

20. D. N. Card, F. E. McGarry, and G. T. Page, Evaluating

Software Engineering Technology. IEEE Trans. Software Engineering, 13. 845-851 (1987).

21. D. G. Kafura and S. M. Henry, Software Quality Metrics

Based on lnterconnectivity, J. Systems Software 3,

121--131 (1982).

22. S. Steppei, T. L. Clark, et al., Digital Systems DevelolM

ment Methodology, Computer Sciences Corporation,

1984.

23. C. V. Ramamoorthy, W. Tsai, T. Yamaura, and A.

Bhide, Metrics guided methodology, in Proceedings,

IEEE Ninth International Conference on Software and

Applications. Computer Society Press, New York, 1985,

pp. 111-120.

24. I. K. Kearney. R. L. Sedlmeyer, W. B. Thompson. et al.,

Software Complexity Measurement, Commun. ACM 29,

1044-1058 (1986).

25. W. W. Agresti, V. E. Ch0rch, et al., Designing with Ada

for satellite simulation: A case study, in Proceedings of

the First International Conference on ADA Applications for the NASA Space Station, 1986, pp. F.I.3.1-

14.

26. V. R. Basili and B. T. Perricone, Software Errors and

Complexity: An Empirical Investigation," Commun.

ACM 27, 42-52 (1984).

27. D. G. Kafura and G. R. Reddy, The Use of Software

Complexity Metrics in Software Maintenance, IEEE

Trans. Software Engineering 13. 335-343 (1987).

28. D. N. Card and W. W. Agresti, Resolving the Software

Science Anomaly, J. Systems Software 7, 29-35 (1987).

5207

2-23
w

QUANTITATIVE ASSESSMENT OF MAINTENANCE:

An Industrial Came Study

r H. Dieter Rombsch and Victor R. Baaill

=:L= _: - - . =::: ::_= : :

Univermlty of MsrylLnd

Dept. of Computer Science

College Park, MD 20742, USA

(3or) 4s4-so:,4

In this paper we discuss a study aiming at the improvemeat of measurement and evaluation procedures used in an

industrial maintenance environment, We used a general

evaluation and improvement methodology for deriving a set

of metrics tailored to the maintenance problems in this particular environment. Some of the required maintenance data

were already collected in this environment, others were suggested to be collected in the future. We discuss the general

measurement, evaluation and improvement methodology

used, the specific maintenance improvement goals important

to this environment, the set of metrics derived for quantifying those goals, the suggested changes to the current data

collection procedures, _and preliminary analysis results based

on a limited set of already available data. It is encouraging

that based on this limited set of data we are already able to

demonstrate benefits of the proposed quantitative approach

to maintenance. Finally, we outline ideas for automating the

discummd approach by a set of measurement and evaluation

tools. This paper emphasizes the steps of introducing such x

quantitativ e maintenance approach into an industrial setting

rather than the environment-specific analysis results: The

analysis results a_re _ntended to demonstrate the practical

applicability and feasibility of the proposed methodology for

evaluating and imProving maintenance aspects in an industrial environment.

In this paper we present results from a study trying to introduce sound measurement and evaluation procedures into an

industrial maintenance environment. The goal of the study

has been to investigate the company's needs for quality

a_essment, and the suitability of the error, change, and

effortdata already collectedin thisenvironment for addressing these qualityassessment needs.

First we describe the actual industrial maintenance

environment which has been the object of thisstudy including the high-levelmaintenance s_sessment and improvement

goals as stated by high-levelmanagement (section2) and the

goal/question/metric paradigm I'L , used in this study for

defining and quantifying the maintenance assessment and

Thht study was |upport¢d by • grtllt from Burrough| CocportJtion to the University o4" Marr|•nd. Computer time wu provided iu plat through facilitim or the

Computer Science Center of the University ca" Ma.'*yls.nd.

improvement goals of interest. The application of this

methodology has resulted in a list of clearly defined maintenance assessment and improvemed_ go_7.sa.nd-clUgntifiable

questions (section 4) ms well an the corresponding data and

metrics (section 5). Until now only a subset of these data

and metrics required to fullyaddress the stated maintenance

goals had been collected(section 6_.Ba.sec]on the needs of

the partfi:ularindustrial environment changes to the data

collectionand validation process have been suggested for the

future (section 7). Preliminary analysis r_ults for a small

subset of the questions an_ g0ah-dr interest(depending on

the type, amount and quality of data availabh at the time)

are presented (section 8). It is encouraging that based on

this limited shbset of data we are already able to demonstrafe benefitsof thisquantitative approach to maintenance.

Finally, we outline ideas for automating the proposed

approach by a set of measurement and evaluation tools(ssctins O). This paper emphasizes the steps of introducing such

a quantitative maintenance approach into an industrial setting rather than the enVir0nment-specific analysis results.

The analysis results are only included to demonstrate that

the proposed approach actually works in this particular

environment.

2, Maintenance Environment

The study was conducted in the maintenance environment of

a major computer company. The maintenance process from

an organizational point of view can be characterized as follows: Customer Support receives maintenance problems

(mainly) from customers, evaluates them and, whenever

appropriate forwards them in the form of change requests to

Product Assurance. Product Assurance evaluates the

change requests s_aln and forwards them, whenever

appropriate, to Znginessring. The eventually changed products are sent-back to the customer(s) through the same

channels (Product Assurance, Customer Support).

Data are currently being collected during all these

differentmaintenance steps. Customer Support collectsdata

for each single problem concerning scheduling (e.g.,time of

incoming calls,time of outgoing calls),type of problem (e.g.,

clarificationof documentation, operation request;for a complete list see table 2), priorities of problems, and effort spent

on handling the problem. Product Assurance collects data

for etch single change request concerning scheduling, type of

change request, effort spent, and final status (e.g., changed,

change postponed, change rejected including the reason for

CH2442-2J87/0000/0 ] 34 S01.00 © 1987 IEEE

134

5207

2-24

g

I

m

W

z

I

W

I

U

W

i

g

I

U

m
v

rejection). Engineering collecm dntn for each change concerning scheduling, change effort, and the type of change

performed, Data collection is mandatory in some groups such

as Product Assurance_ it is done on a voluntary basis in

other groups such as Engineering. Based on this fact the

completeness and validity of collected data varies across the

entire maintenance environment. In general it is true that

Customer Support and Product Assurance stressdata collection more than Engineering does.

Although this is a very simplified description of the

maintenance process it should allow the reader to understand the differentneeds of these three differentmaintenance

roles as far as assessment needs are concerned.

The data were used for filingstatus reports concerning

the handling of maintenance requests but not (except locally

in some groups} for overallquality assessment. The purpose

of this study was to find out whether the already collected

data are su_icient for asseming the environment specific

maintenance problems and, ifnot, to suggest changes of this

data collectionprocess.

The most urgent maintenance assessment and improvement goals were formulated by corporate representativesof

the company as follows:

GI: Examine where the bulk of the company's maintenance

dollars are being spent and how much is being spent on

individual activities.

G2: Identify the best ways of applying the 20/80 rule* to get

the biggestsavings _d return on our maintenance dollars.

G3: Identifyeriteriffi for when k product isready for release.

G4: Identify features of product, documentation or support

that provide a wider customer satisfaction.

Gh: Identify criteriafor when a software product should be

rewritten rather than maintained.

Gf: Identify metrics of customer satisfactionthat can be

developed based upon existingdata.

GT: Develop organizational guidelines for integrating

software quality metrics into the company's framework of

design, development, and support.

It is obvious that these high-level and complex problems can only be assessed by breaking them down into more

and more simple problems. This refinement process, which

finallyisexpected to resultin a set of quantitativemetrics,is

supported by a methodology developed by the authors_'e''.

3. The Goal/Question/Metric P&radism

The approach to quantification of goals is the

goal/question/metric paradigm _ a L , This paradigm does

not provide a specificset of goals but rather s framework for

defining goals and refining them into specificquantifiable

questions about the software process and product that provide a specificationfor the data needed to help answering

the goals.

The paradigm provides a mechanism for tracing the goals of

the collection process, i.e. the reasons the data are being collected, to the actual data. It is important to make clear, at

least in general terms, the organization's needs and concerns,

• Applyln| the 20/80 r_le mesas to identity those ms/ntentaee problenu which cu

be fixed euily (with twenty percent of the efort of what would be requirt<l to B.x

ill malntenLnee problems) but redlee the maintenance overhea_ druticJd|y (by

eighty percent I.

5207

the focus of the current project and what isexpected from it.

The formulation of these expectations can go a long way

towards focusing the work on the project and evaluating

whether the project has met those expectations. The need

for information must be quantified whenever possible and

the quantificationanalyzed a,sto whether or not it satisfies

the needs This quantificationof the goals should then be

mapped into a set of data that can be collectedon the product and the process. The data should then be validated

with respect to how accurate itisand then analyzed and the

resultsinterpreted with respect to the goals.

The actual goal/question/metric paradigm is visualized in

figure I.

Figure 1: Goal/Question/Metric Paradigm.

Here there are n goals shown and each goal generates a set of

questions that attempt to define and quantify the specific

goal which isat the root of itsgoal tree.The goal isonly as

well defined as the questions that it generates. Each question generates a set of metrics (re_i)or distributionsof data

(d_i).Again, the questions can only be answered relativeto

and as completely as the availablemetrics and distributions

allow. As is shown in figure I, the same questions can be

used to define differentgoals (e.g. Question 6) and metrics

and distributionscan be used to answer more than one question (e.g. m_l and m_.2). Thus questions and metrics are

used in several contexts.

Given the above paradigm, the process of quantifying

improvement goals consistsof three steps:

(1) Generate a set of goals baaed upon the needs of

the organisation.

The first step of the process is to determine what it is you

want to improve. This focuses the work to be done and

allows a framework for determining whether or not you

have accomplished what you set out to do. Sample goals

might consistof such issuesas on how to improve the set

of methods and tools to be used in a project with respect

to high quality products, customer satisfaction,productivity,usability,or that the product contains the needed

functionality.

(2) Derive a set of questions of interest or hypotheses

which quantify those goals.

The goals must now be formalized by making them

quantifiable. This isthe most difficultstep in the process

because it often requires the interpretationof fuzzy terms

like quality or productivity within the context of the

development envlronme_t. These questions define the

goals of step I. The aim isto satisfythe intuitivenotion

of the goal as completely and consistentlyms pcesible.

135

2-25
(3) Develop •Nt of data restrict stud dhtributtons

which provide the information needed to answer

the questions of inter_L

In this stepl the actual data needed to answer the questions are identified and associated with each of the questions, However, the identification of the data categories is

not always so euy. Sometimes new metrics or data distributions must he defined. Other times data items can be

defined to answer only pu_-of a question. In this cruse, the

answer to the question mutt be qualified and interpreted

in the context of the misting information. As the data

items are identified, thought should be given to how valid

the data item will be with respect to accuracy and how

well it captures the specific question.

In writing down gosh and questions, we must begin by

stating the purpcoe of the improvement process. This purpose will be in the form of a set of overall goals but they

should follow a p_rticulxr format. The format should cover

the purpose of the process, the perspective,and any important information about the environment. The format (in

terms of a.generic template) might look like:

• Purpose of Study:

To (characterize, analyze, evaluate, predict, motivate) the

(proce,,m, product, model, metric) in order to (understand,

assess, manage, engineer, learn, improve) it.

• Perspective of Study: /

Examine the (coat, effectiveness, correctness, errors,

changes, product metrics, process metrics, reliability, user

satisfaction,etc.) from the point of view of the (developer,

manager, custnmer, corporate perspective,etc_. _

• Environment of Study:

The environment consists of the following:process factors,

people factors, problem factors, methods, tools, constraints,etc.

• Protein Questions:

For each process under study, there are several subgoals

that need to be addressed. These include the quality of

use (characterizethe process quantitativelyand _ how

well the process is performed, the domain of use (characterizethe object of the process and evaluate the knowledge

of object by the performers of the process),effortof use

(characterizethe effortto perform each of the sub activities

of the activitybeing performed), effectof use (characterize

the output of the process and the evaluate the quality of

that output), and feedback from use (characterize the

major problems with the applicationof the process so that

itcan be improved).

Other subgoals involve the interactionof thisprocess with

the other processes and the schedule (from the viewpoint

of validation of the process model). =,__, : ,

• Product Questions

For each product under study there are several subgoals

that need to be addressed. These include the definitionof

the product (characterize the product quantitatively) and

the perspective of the evaluation (e.g. reliabilityor user

satisfaction).The definitionof the product includes physical attributes ( e.g.source lines,number of units,executable lines,control and data complexity, programming Innguage features, time space), cost (e.g. effort, time, phase,

activity,program), changes (e.g.errors, faults,failuresand

modifications by various clazmes), and the context the l_?oduct is supposed to be used in (e.g.customer community,

operational profile).The perspective of the evaluation is

relative to a particular quality (e.g. reliabilityor user

satisfaction).Thus the physical characteristicsneed to be

analyzed relativeto thisquality aspect.

4. Maintenance Gosh and O u_estiona

We applied the methodology described in section 3 to specify

the high-level quality assessment and improvement goak

given to us from a corporate perspective (seesection 2) more

precisely, and to derive quantifiable analysis questions.

Using the template of section 3_roved to be very helpful.

The entire process of specifying goals and deriving the

evaluation questions wu done in very close cooperation with

company representat!ves from Customer Support, Product

Assurance, and Engineering.

The seven goa l- for thil study are formulated ha

terms of the purpose of thk study, the perspective of

this study, and" important information •bout the

company's maintenance environment:

* PURPOSE OF $'IWJDy: Characterize (in the c_ of g0_]s G1 and G4)

and evaluate(G2, G3, and G5) the maintenancemethodologyand

motivst4 (G6 and G7) the use of metrics for the purpo_ of bettar

understanding(GI and G4), management (G2, G3, GS, Gg. and G7) mad

improvement (G,_, O3, G5. G6, and GT)

. PERSPECTIVE Examine thecog (in-theca_ olKoaJsGI, G2, G5, and

GT).problems((_2).errorsand chanKce(Gl and O5),productand proc_ metrics(G3.G4. G5, and G6) and the effectiveness (G71 from the

pointofviewofthemanagerand corporation

* ENVIRONMENT

- Maintenance Process: The customer report_ problems (by phone) to

the Customer Support;it'problemscannotbe resolvedby Customer

SupporttheyaxeforwardedtoProductAssuranceProductawurance

decideswhetherthe reportedproblemshouldbe fixed.It'approvedam

a problem to be fixed it is submitted to engineering {to be fixed), get_

back toProductAmurance (forfix certification), and issentbackto

CustomerSupport : .........

- MaintainedProducts(for which we had access to data). A re_'tevaJ

system(called SYS_I in the followingofthispaper)

and a compiler (called SYS._2 in the t'o|lowinKof this

paper)

For each proceu and product under study, there are

several subgozh (quality of use, domain of use, effort

of u_, effect of use, and feedback of use); each

subgosl will be addressed by • number of analysis

questions (Qi):

=: : .... 7

(A) PROCESS RELATED QUESTIONS:

• QUALITY OF USE (characterise the company's ma|ntesanee

proc_ and how well itis performed)= -

QI What percentof the problems_e handledby Customer Support

withoutforwardingthem toProductA.murance?What tsa distributionoftheirdispo6ition?

W

II

J

W

z

I

W

U

g

m

U

m

II

m

m

m

5207

136

2-26

m

w

B
v

w

Q_I: What I_WCtat of ©hup rsqumts forward*d to Product Amumaes

do not came from th• field? What is a d/atribution by percent of

where they o_m• from (enspnHring, field test, et¢) tad the tea8one they do not come from field7 Whst percent of problem•

aren't r_ly m_utenance problem•?

Q3: For chtage rsqumts rsj*cted by Product Amurance or Englnesring:

What are the dmtribut_om by

z) clonu_ code.

2) orlMmigatioa rmpo_ibl• for rejection, and

8} *¢heduk by closure code by ct'|lmnmtloa _

Q4: What are ch&_cterigic* of the t_t plea pedormed by engmeenng

before reJmme7 How effective i• this _ plan?

More de•ruled: Us th• test suite bmmd upon the new or cbsmfied

final requirements_ Are refirem_on tests performed7 Are the tests

baned upon the importance and complexity of the requirements?

What criteria exist for the selection of test cases and test datn_

QS: What ire test cars and test data for the beta test? To what extent

does it con.qider the future u_le profile _ How e_ective is this

test?

_: For each fix: How Ions *_ter the fix is made is it released to the customer?

(_r: What is the distribution of faults or customer problem• per organiuttiunaJ unit in tot*l and by various products?

qe: What i* th• dktcibut_on of f.nit4 due to previou* changes per

ccganizationsfl unit m toteJ tad by var:oUJ producte?

Qg: Wlmt are the distributions of change requests by various subclaeses

(fanlt/modificttion, reiected/_ot rejected, error subc|ame•,

• chanse subcl*amm)_

* DOMAIN OF USE (characterise the obJecta of the maintenance

proce_ &nd the knowledge of the people Involved in this

msinteo nnce pr6cew)*

QI0: What products are nv_hd:_le to

- customer support personnel,

- p_obtem •vtJuntc¢,

- changer,

- _tage ev,_uator, tad

- the field support?

QII: Whut ts the knowledge of the people involved wet

1) the spplicnCion,

2) the particular product, tad

3) the change methodology?

• EFFORT OF USE (chse_cterice the effort to perform e_eh

maintenance _tlvlty)*

Q12: Wh_ is the cost o(

d*t_ting s problem symptom

underst4mding the problem,

imvltti_, the problem carom%

duigninfi the change,

tmplementing the change,

testing the change, and

reieMing the change

in fermi of computer time, people time, by person category mud

nmchin* att_ory?

QI3: What m the cldendar time for

- detecting n problem symptom.

- understanding the problem from a customer's viewpomt,

- undemtandini the pmbJem from an mgmeering viewpoint,

- i_stini the problem cause%

- designing the change,

- implementing the change,

- teeing the change, and

- rele_nfi the change?

[Give the max, men, average and by various type• of changes*]

* EFFECT OF USE (eharac_rl_e the output of the m*Intensnce

proce_ and the quality of th[* output)s

QI4 How many tad what percent of documeut_ _re produced/modified

*8 t result of the m_intenanee proce_ (patch. user manual, additmn,J technical do_umente, c]o_ure form. patch rele'_e information form. advanced techmcai information form tad user letter)?

QIS: How many and what percent of change requests cause •

modification?

Qlfi How many and what percent of change requesfa axe related to

errors,,environment adapt•none and requirements changes (_

enhancements)7

QI7: How many and what percent of faults &e the result of a previous

change?

Qtfi: Whut m the LverNLe coet of a chtall;e overall tad by type_

Q19 Having cntegoriz_d change• by function, having made s change in

a function How many future requests do we get for the es_e

function_

Q20: What are characteristicsof customer c_dlsover t_me by type of

question'_

Q21 Wh_ customer categories exmt? Do clusters of customer profiles

(types of complaints, faults, etc.) match these catefior_zation

schemes 7

Q22: Is the _eer m_tisfied with function,pedormance, _chedule (by a user

seem;action survey)?

• FEEDBACK FROM USE (characterise the problern_ with the

appllc*.tlon of the m*lntenan_s procem •O that It can be

|mp_ved)*

Q23 What are the problem areas in the ms6nt, enance procure by the following categories:

- distributionof changes by various types,

- distributionof problems that are r_ject_l by "_ario_ types,

- customer typm, tad

- tame distribution (c*lend& time, e@ort) by vtrious ch_e

types, problem types,or mtintenance activities?

(B) PRODUCT RELATED QUESTIONS:

* DEFINITION OF THE PRODUCT (characterise the

product quantitatively)*

Q24: What are the physical attributessuch te

- m_e (source lines, number of units, executable lines of

code),

- complexity (control,date),

- programming l_gu_q[e features,

- time to develop,

- memory •p*ce, tad

* execution frequency? .._

4

Q2fi: What is the cost, e.&, effort (time per ph_.'e, activity)_

Q_fi: Wh.t are distributionz of changes, eg, errors. |•ults, f_ilures.

sdap_tioxm, *ad anhanesment_ by v*rioue tYPeS

137

5207

2-27
x • z • z • • • x __ • z • z

• s *" z s z z • • • • •

• | • z x s • • ..• 1 • s z x z • • • • • • •

....... t l ......

L 1, t l ,

z I • • x z z • • • x z • • • Z • x z •,. • • •

I

J

m

Ig

Table 1: GosJ-Oumtio 9 _tT]X

Q27: What is the product8 context, eL customer community,

opera_onsi profile, life cycle model, e_?

Q28: What Lre the problem Lre_ in the product by the following

cst_gor/es:

- distribution of changes by va,rmus types,

- distribution of problems that a_ rejected by vLrious

types,

- cu_omer typu, sad

- time di_*trtbution (caJendaz time, effort) by venous change

types, problem typee, or maintenance _ctiviU._?

Each individu*l evaluation god is quantifiable via L subset of

these 28 evaluation questions. In table 1 the interrelationship

k visuMized in form of a goal-question matrix.

5. Maintenance Data & Metrics

In this section we discuss the types of maintenance data

which has to be collected in order to answer each of the

evaluation questfons derived in section 4.

The data (Di) axe categorized depending on which

maintenance aspect (Customer Support, Product Assurance,

or Engineering) is mainly affected. For each data it is indicated whether and how it can be retrieved from currently

maintained data bases, i.e., whether it is explicitly available

(+), it is not explicitly available, but can be derived from

other data with reasonable effort (o), a great deal of effort

(oo), or it is not available at all (-).

(1) CUSTOMER SUPPORT ORIENTED MAINTENANCE DATA:

For each problem reported by customers (phone call-):

DI (+): customer ideatificaJ, ion

D2 (so): customer type

D3 (+): customer support center identification

D4 (o): problem description

D$ (+): whether a problem resulted in a change requeet (Y/N)

D8 (oo): connection between customer problem a_d change

reque__numher

DT (+): identification of aBectt_l system/product

D8 (-): aientification of aff_tsd product functions

D9 (+): schedules for each activity *mocistsd with a custom*_ problem

(2) PRODUCT ASSURANCE ORIENTED

MAINTENANCE DATA=

For each prcb]em report4d by a change request:

DIO (+): identification of the o_s.n/r,s_ion that filled out the change

request (c_rtomar support, engineering, field t_t. e_)

DII (+): ideat_c_mu of zryetsm/product a_ec_d

DI2 (+): customer identafic_*aon

D I3 (-): customer t}_t

DI4 (+): ideatiftc_ion o( Product Assurance center in charge

DIS (o): coaeiH problem description

DI6 (o): reformation whether a change r_lut_ was rejected (3(/_

DIT (+): Emd change rsqumt status (-- clomu'e code)

D18 (-): information by whom (Pr0duct-.FtJg_rancd, Engineering) closure code wig _t

DI9 (+): schedulee for each maintenance activity

D20 (+): information whether it ia L fault, adaptation, or enhancBmeat

(3) ENGINEERING ORIENTED MAINTENANCE

DATA:

For each actu_]y pedormed change:

D21 (+): ident+flcatioa of _e engin_erio| group in charge

D2_ {-): information about fault types (for example: control, d*_L,

computation, etc)

D_3 (o)_ information whether a fault wu canesd by a previous change

C7/_)

D24 (o): informLtion which product units (modules) were _ect_ by •

change (in terms of linm.of.cod* or identification of

modulee)

D25 t'): effort in computer time in tot*/or per phase, change activity

D25 (-): effort in people time in tot.] or per phu*, change activity

D2"7 (+): schedule for each change activity (in c_dendar days)

D28 (o): percent of code, documents, forms changed

D29 (o): product s*_

D30 (o): product complexity

D31 (-):memory space

The followingquestion-datamatrix(seetable2)shows which

of the 31 differenttypesof data a_erequired/fitffiminimum

to answereach oi"thepreviouslylisted28 questions:

138

5207

2-28

g

I

J

M

l

g

H

m

V

m

J

II

m

N =

m

B
¢J

qJ

qW

ql

QI4

QII

qI

QII •

QII

qII

QII

QII

rI yl

I

II

1

• xx

i

• t • I

J

, i ,

I i

l

• i

+ . ,

Table 2: Question-Data MatrLY

The questions enclosed in parenthesis have to be answered purely by subjective data.

The complete refinement process from the original goals over

questions to the data/metrics can be traced by combining

tables I and 2.

6. Avail.billtv and Validity of Dat_

In the previous section it was indicated what data are

needed for answering the questions of interest. We also

included the analysis results to which degree those data are

already available inside the company (+,o,-).

Interpreting the question/data matrix together with the

availabilityand validityof the company's data the following

couclusionn can be draw_:

+- Questions Q6, QI3, QI5, QI6, QIT, Q20 are completely

answerable

- Questions _Q4), (Q5), (QlO), (QI1), (Q22) will not be

answered bMed on data collected via regular data collection forms, but by subjective data from interviews.

- Questions Q23 and Q28 require no data, they are answered

by interpreting the results of more basic questions

- All questions related to change effort (Q12, Q18, Q25) can

not be answered because (at least in the case of SYS_I and

SYS_2) these data were listedas optional on the data cob

lectionform and thereforeonly listedon about 10% of all

forms.

- All other questions are (at least partially) answerable

7. Imnrovement of Data Collection

Based on the company's interestsas documented by the

high-level problems (see sectio_g 2) and the refined set of

evaluation questions (see sectic_ 4), and the partial lack of

valid data avaiiabh to analyze those questions, the following

recommendations for changing the data collectionprocess are

being made:

5207

139

2-29
- A uniform data collection method mud data base should he

defined..

Some data items are interpreted differently by different

people. Each organizational unit inside the the maintenance environment has its own data base format. This

fact makes it difficult to assess maintenance problems from

global views. It is for example difficult to analyze engineering data from various sttee¢_r the complete life cycle of

maintenance problems starting at Customer Support

throughout Product A.msurance and Engineering.

* A maintenance task should be viewed as a single entity in

this data hue, and it should be traceable through all its

phases (Customer Support, Product Assurance, Engineering). Due to the "bottom-up" development of individual

data banes, each data base contains only thvse data important to the individual organization.

The only solution seems to be a central data base that

contains all information concerning each maintenance task

starting from the first phone call and ending with it_ final

resoh tion.

- ft is mandatory to collect engineering data (effort in

gal..hours)

Engineering data are crucial for determining maintenance

problems due to product quality problems (e.g., bad strutturn).

- Development data (errors,changes, teSts, etc.) should be

collected.

Collection of development data has to start now. As soon

am the identification of the maintenance problems is completed, the impact of product quality and development

methodolo17 on these problems has to be anaJyzed. [n

order to do this, data characterizing the development proceas are needed.

S. Preliminary Analysis Results

In order _o demonstrat, the benefits of quantitative _sseasmerit of maintenance we used the data collected at the time

to answer some of our maintenance questions listed in section 4. We had data available for two commercial systems

SYS_I and SYS_?. (retrieval system and a compiler). We

had maintenance data available from the first two quarters

of 198o.

In section 8 we outlined the questioul which muld b.

answered baaed on the data available. In the following we

present preliminary analysis results of these questions in the

context of the originally posted high-level corporate maintenance problems (1) to (5) as listed in section 2.

(GI) Examine where the bulk of the company's

maintenance dollars are being spent and how mush

is being spent on individual activities:

This goal area can be addressed by the following analysis

questions (see section 4);

* Question 20: (_Arhat are characteristics of customer ctile

over time by type of question ?) _> Table 3

The avera4ge number of catk per problem is about 4.

The most frequent problems are operation questions,

capability features, and clarification of documentation

(in the case of SYSj) or operation fault (i_ the cue of

SYS 2). The costly problems (in terms of number of

calls) are documentation faults, system software, and

Operation faults (in the ease of SYS._I), and clar_caGon

of documentation, capability features, operation qumtions, and pre-sales requests (in the case of SYS_2).

* QUestion l _What percent of problems are not reported

change request? What is a distribution of their

disp0dition?) --> Table 4

Overall only about two percent of all problems recorded

by Customer Support resulted in change requests (3 out

of 177 for SYSI, 3 out of 152 fo r SYS_2).

The dlspceition of problems not reported am chan_s

requeet_ in terms of "type of call" is as fo]]o_if .....

The bulk of maintenance problems hudled by Customer Support is spent for "operation requests_ and

"operation faults _ in the cue of SYS._; in the cane of

SYS1 we can identify two additional problem soureeJ:

problems due to faults of underlying layers (systems

software and hardware) and problems due to bad documentation (tlm_t 20_ of all problems [)

tin*trot

unkuowo trpt

clarify document

opemtiemquestion

pre-aaJ**requ*st

capability, t_ture

other

decument ftu|t

operation fault

tpplitttioa SW ebonitetequmt

appl[cMJ.ol SW fault

trst_tm S_q ft_tlt

sylt, em SW chaal_e rtque*t

iattl'u_,n limit

HW f*_It

AVERAGE

SYS.

eaR* erobkms

s 20.t_)

l_o _ (io.s%)

_r2 ,e (2e.o_)

7 2 (Ll_)

ss so (16.o%)

_ (o,e_)

so _o(s.e_)

86 t_ (s.s%)

_4 _ (L_)

tdk/erobkm

3.7

3.7

3.5

Z.O

3J

70

5.0

4.0

4,7

3,5

3.9

3.7

SYS.2

tilts "[ _bl*x_ ¢dh/_mbhm

37s- 78 (s_.z_) 41

s4 _ (tx,2_} 4.0

_1 x9(12.5%) 3._

3 1 (o.7_) 3.0

e _ (1.3%) 3.o

4.1

Table 3: All Calls/Problems by Call-Tvua

5207

2-30

u

I

w

B

I

J

W

5

mm

M
ORIG:N,_. PAGE I$

OF POOR QUALITY

cMI-tv_,e

unknown type

clarify document

opera*Joe quNtioa

prt-tldu reqult

c_pability, fsi_,ur*

oti, eT

document fault

operation fro*It

applJeatiop $W limit

totem $W fault

iasLruc_,k_sfault

HW fault

TOTAL

ctJb

5

130

172

T

tit

43

?

4

7

O?

O65

_sj

problerm c'tht/problem

2 (1.1_) 2.6

(io.s_) 3.7

4e (_.o_) s.7

: (Lx_;l s.5

so Oe.o_) s.0

is (7,_) s3

x (o.0_) _.o

zo (s.u'_) 5.0

1 (o.e%) 4.0

xs(8.6_) 5.7

2 (1.x_) s.s

17 f,_'l _t.9

17411rt(el.s _) s.7

SYS,,S

cilia problems cdls/probl_

.

_ (4.eo_) 4.0

3"r8 70(51.3g_) .Ls

o _ (t.3_) 4.s

e4 IT (11._) 40

01 10 (12.s%) s.2

44 2o413._) 2.2

Is 4 (2:e_l _.*

5 2 [1,3_] 3.5

030 1401152 (tB _) 4A

Table 4: Non-forwarded Calls/Problems by CaiI-TY_¢

• Question" 2 (What percent of problems aren't really

maintenance problems?) --> Table 5

Table 5; portion of Real Maintenance Problems

SYS_I SYS_2

Number of total problems 177 152

Number of mLintenance problems 80 116

percentase 45.2 % 76.3 %

Not all of the problems reported to Customer Support

are really maintenance problems There are, for example, lots of requests from different divisions inside the

company. From a global view, all the effort spent in

Customer Support is charged u maintenance effort. In

the c_¢ of SYSI, only about 45% of all problems (80

out of 177), and in the cue of SYS..2, only about 76%

of allproblems (I16 out of 152) are reallymaintenance

problems.

• Question 3 (What is the distribution of rejected change

requests by closure code?) _> TaMe 6

The distribution of rejected change requests by closure

code is as follows:

T_ble 6: Re iected ChLnEe Requests by Closure Code

Systems

Closure Code SYS_I SYS_2

need _dditional information 11 11

not reproducible I

no fix scheduled 3 2

alre_ly fixed 45 25

forwarded to ... 2

works as intended 6 I

works as documented 3

incorrectdocumentation 2

operation problem l l

document required I

not retrofit 2 8

other 2

• Question 12 (What isthe cost of ...... ?)

Because we have no effortdata concerning the Product

Assurance and engineering aspects of the maintenance

process, we only could xnalyze effortas far as Customer

Support wu concerned:

The cost for e_ch individual maintenance problem (as

fax as Customer Support isconcerned) cxn be characterized

eakeowe type

clarify document

o_*r ttiolt qua*iOn

pre*s*Im ?tqu ell

eupability, fetter*

other

document fault

opermtlon r,,ult

I _pplicttioa SW chugs requ.t

*ppliestloa SW fault

system SW fault

system SW chum reqe_t

iUtr uct_on flmlt

HW fruit

AVERAGE

SYS.I

Ume (mins) problems time/problem

&2 2 200

701 35 22.6

1203 4e 20.1

38 2 18.0

73_ 30 24.6

247 13 19,0

43 1 43.0

_0_ 10 30.3

1 _.0

15 3&0

16"/ 3 55.8

13 2 6.8

or.3 (miu_)

sYS_

time (rnins) probleml time/problem

247 7 35.3

3723 78 47.7

211 2 I05,5

747 17 44.0

813 19 42.8

522 _0 28. I

20 I 20.0

o

78 4 19.4

8 2 4.0

i g.+

Table 7: ON-Line Spent Effort by Call-Tune

141

5207

2-31
w

csJl-tYpl

cluify document

[i time (miml)

88S

oplr_iOo quution 7_17

pr*-nJI requ**t 45

ezp,bility, ft*t ure 110$

o_h*r 240

document fLult 117

op_r_ioa rLult 21o

l*pp!_l_ion SW fl*u|t 330

zyer, em SW fault 1125

*ret*m gW chlmlle rqquest I l&

instruction fsuR 20

HW f*ult _.... 780

AVE_G_ I!

SYSI

nroblems tim¢/problem

36 10.8

48 50.4

2 22.5

30 M.8

13 18.5

1 1170

10 21 0

1 330.0

15 75.0

3 38.3

2 lO.O

Z7 45,9

.... I 4o.s (mine)

time (mine) nrobl*rrm t-lmelDroblem

305 7 43.{I

4062 78 52.1

130 2 (15,0

856 17 50.3

1810 tO 95,3

75 20 3.8

700 4 102.3

335 2 l_T.5

06 _ 32,5

Table 8: OFF-LIne Snent Effort by CalI-Tvon

f_.Y (miu)

- by the number of phone callsper problem:

The average number of calls (interactionswith the

customer) per problem isabout 4 (SYS l:3.7,SYS._2:

4.1)according to table 4.

The most crucial problems in $YS I in terms of

number of callsare: documentation faults (7 callsper

problem), operation faults (5 calls per problem), and

system software faults (5.7 callsper problem). In the

case of SYS._2, the most crucial problems axe: documentation clarifications(4.9 callsper problem), operation requests (4.8callsper problem), pre-salesrequests

(4.5 calls per problem), and capability/feature

requests (4.9callsper problem).

- by the _ffort spent on-lln, (time spent tdking to _he

customer on the phone .--> Table 7):

The average effort.per problem spent on-lineis about

30 minutes.

In the case of SYSI, most on-lineeffortisspent for

documentation problems (43 minutes per problem),

application software faults(53 minutes per problem),

and system software faults(56 minutes per problem).

In the case of SYS._2 most on-line effortisspent for

pre-salesrequests (105 minutes per problem)

- by the eSort spent off-line(time spent other than talking to the customer onthe phone ---> Table 8):

The average e_'ortper piob|em spent of-line isabout

45 minutes.

In the case of SYS_I, the most of-lineeffortisspent

for documentation problems (117 minutes per problem) and application software faults(330 minutes). In

the case of SYS._2, the most off-lineeffortisspent for

system software faults(180 minutes per problem).

(G2) Identify the beat ways of &pplyin$ the 20/80

rule to set the biggest sLv_ngs and return on our

maintenance dollars:

Although we have no final results concerning this

matter, a careful interpretationof the resultsrelated

to goal (G1) indicates tha_ for instance better documentation, in the case of SYSI, could save a big percentage of maintenance problems. In a paper not

related to this study an analysis of software m_ntenance changes is reportedm; the authors aim at the

development of metrics for predicting where those

changes might occur. Such metrics might help save

dollmm by concentrating resources on subsystems or

modules which can be expected to require mLny

changes.

(G3) Identify criteria for when a product k ready

for relelum:

This question can only be answered ifwe know more

about the type of problems and effort spent in

engineering before release(question Q4) and about the

type and problems during fieldtest(question Q5).

(G4) Identify features of product, document&tion or

support that provide n wider customer satisfLction:

This question can be addressed by designing a customer questionnaire. Some of the technlca] problems

definitelyhave impact on the customer's satisfaction,

such as the high number of documentation-related

problems (in the case of SYS_I) or not being able to

keep promi_d d,,tas for cLl|ing Customers back.

(GS) Identify criteria for when n software product

should be rewritten rather than maintained:

Unfortunately there axe no data collected indi_:ating

explicitly which parts (modules, subsystems) of a product were affected (question Q26) or whether a problem

is due to a previous change (question Q8).

The only way to address this question by using the

currently available data is to evaluate the actual patch

where the actual lines changed are listed. A paper not

feinted to this study indicates that complexity metrics

characterizing the locMity of changes might be a promising metric for characterizing the suitability of parts of *

software system for maintenance purposes".

(G0) Identify metrics of customer sat_faction that

can be developed_d u_n exh_ting data:

Based upon the results concerning goal G4 we hope to

be able to develop metrics for customer satisfaction.

Although it is too early to expect reliable metrics, candidate metrics might "__ffd|ude-Mpects Such as ability to

keep promised schedules for dealing with maintenance

problems or the frequency of similar (at least from the

customer's point of view) _ m_inteaance problem reports.

(GT) Deveiop organisational guideline* for integrating software quality metrics into the company's

framework of deign, development, and support:

142

5207

2-32

IB

u

g

B

I

h_

B

IB

TB

m

IB

g

m

IB

i

IB

m

m

m

m

m

m

II
This goal represents the second step after having undera,ood the maintenance problems and identified possible

improvements, Procedures for monitoring quality and

productivity have to be established throughout the

development and maintenance of software products; the

prescribed data and metrics should be used for management and' motivation purposes and improved. Before

this problem can be a_Idreesed in a satisfactoryway

many more and differentanalyses have to be performed;

in particular,data concerning the development phase of

products have to be collectedin order to identify the

impact of the particular development process on maintainability. In a paper not related to this study

interestingapproaches for predicting the required customer support for a particular system were presented*.

The prediction approach utilizeddevelopment metrics

among others.

g. Measurement and Evaluation Tools

In order to apply the proposed quantitative assessment

approach practically,data collection and validation procedures as well as evaluation procedures need to be

automated. A tool system was proposed integrating many

tools already availablein this environment. The whole tool

system needs to be implemented in a decentralized fashion

around a central data base. It has to provide differentinterfaces to differentmaintenance groups, limiting each group

only to data relevant to their specifictask, presenting the

data in a helpful way. Independent of thiscompany-specific

project, a research project at the University of Maryland is

aiming at the development of a comprehensive approach to

automating measurement and evMuation in the context of

software projects which includesupport of the generation of

goals and questions and the project-specificinterpretationof

measurement resu[tsz 4.

10. Conclusions

The objective of this study has been to demonstrate the

benefits of _essing the software maintenance process in a

quantitative way for the purpose of improvement. We have

been able to show the applicability of the

goal/question/metric paradigm to this cfmp]ex problem

domain and derive first analysis results based on a very limited subset of availabledata. The long-range benefitscan be

expected to be much more significantprovided the derived

set of data are collectedin the future and interpreted within

the proper context of maintenance questions and goals. In

this paper we have not addressed the psychological problems

involved in trying to introduce quantitativeapproaches into

a traditional maintenance environment. The interested

reader is referred to a book describing Hewlett Packard's

experience (including psychological problems of motiv_.ting

project personnel and higher-levelmanagement) from introducing metrics into their daily software production environment s,

It was even surprising to us, how many characteristics

of the maintenance process could be made visible by ana]yzink the limited set of data available at the time. This visibility of characteristics might be helpful in communicating

problems in • more objective sad convincing way.

The analysis result underline the" importance of viewing

software maintenance not as an isolated activity but as

integrated into the overall software life cycle. We can

improve the effectiveness of maintenance procedures by

purely analyzing the maintenance process. However, we will

never reduce the overalleffort(and money) spent for maintenance below a certain limit if we cannot make sure that

software products fulfillcertain quality requirements at the

time of delivery (startof maintenance}. Low qualityproducts

will always cause maintenance problems. Accepting this fact

will lead us to establishquality criteriafor a product to be

released to customers and, thereby, entering the maintenance

phase. As a consequence, developers could develop guidelines

for how to achieve those criteriaand metrics to evaluate the

degree to which those criteriaare actually met. Altogether

this would allow us to develop better maintainable products

in the firstp[_e or, at least, allow us to predict certain

maintenance problems at the beginning of maintenance.

Additional benefits of collecting maintenance data are to

provide a better basis for judging customer satisfaction,the

company's image, and marketing

If we want to reduce the overall maintenance effortwe

need to apply the assessment and improvement procedures

introduced in this paper to development as well as maintenance of a product. This requires the availabilityof development data (as implicated by the evaluation questions in section 4) in addition to maintenance data As'long as we do

not assess the overallsoftware lifecycle,problems willshift

from design to coding, coding to testing,and development to

maintenance. It is a well known fact that the reallyserious

maintenance problems originate during the prior development of the product; the identificationof these real causes of

maintenance problems willresultinsignificantimprovements

of maintenance.

Ack now led_em ents

This study was supported by a grant from Burroughs Corporation to the University of Maryland. The following people

from Burroughs and System Development Corporation supported thisstudy in various ways: Kenneth Cain, Charles H.

Coulbourn, Joe Dormady, AI Freund, Michael A. Heneghan,

Bob Lesniowski, Mary Mikhail, Frank Star, and Christbpher

Whitener. Jinn-Ke Jan from the University of Maryland

worked on this projectas a graduate research assistant.

12]

References

V. R. Basili, "Quantitative Evaluation of Software

Engineering Methodology," First Pan Pacific Computer

Conference, Melbourne, Australia, September 1085 lalso

available as Technical Report, TR-1510, Dept. of Computer Science, University of Maryland, College Park,

July 1985].

V. R. Basili,H. D. Rom_'_h, "TAME: Tailoring an Ads

Measurement Environment," Proceedings of the Joint

Ads Conference, Arlington, Virginia, March 16-19,

1987, pp. 318-325.

143

5207

2-33
[3] V. R. Basra, H. D. Rombach, "Tailoring the Software

Procem to Project Gosh and Environments," Proceedinsz of the Ninth Internstion -I Conference on Software

Engineering, Monterey, California, March 30 -April 2,

1987, pp. 345-357.

[41 V. R. Basili, H. D. Rombach, "TAME: Integrating

Measurement into Softwace Environments," submitted

for publication to [EE_ Transactions on Software

Engineering.

I5] Victor R. BMili, Richard W. Selby, Jr., "Data Collection and Analysis in Software Research and Management," Proc. of the A_nerican Statistical Association

and Biometric Society Joint Statistical Meetings, Philadelphia, PA, August 13-18, 1984.

[6] V.R. 8asili, D. M. Weiss, "Evaluating Software

Development by Analysis of Changes: The Data from

the Software Engineering Laboratory," Technical

Report TR-1236, Dept. of Computer Science, University

of Maryland, College Park, December 1982.

[7] V.R. BMili, D. M. Weiss, "A Methodology for Collecting Valid Software Engineering Data," IEEE Transactions on Software Engineering, Vol. SF.,-10,No.3,

November Ig84, pp.728-738.

[8] J. Chspin, G. Fddell, "Predicting Software Customer

Support," Proc. Conference on Software Maintenance,

Washington D.C., 1985, pp. 128-134.

[9] Robert B. Grady, Deborah L. Caswell, "Software Meaeurea; Establishing s Company-Wide Program," to be

published as s book by Addison Wesley, 1987.

[I01 D. h. =Cusiafso_, A. Meiton, sad C. S 1%ieh, "An

Analysis of Software Changes During Maintenance sad

Enhancement," Proc. Conference on Software Maintenance, Washington D.C., 1985, pp. 92-95.

[II] H. Dieter Rombach, "A Controlled Experiment on the

Impact of Software Structure on Maintainability,"

IEEE Transactions on Software Engineering, Vol. SF:

13. No. 3,March 1987, pp.344-354.

IW

I

m

am

g

a

I

J

U

mmm

g

m

U

II

III

5207

144

2-34
Resource Utilization during Software Development

Marvin V. Zelkowitz

Department of Computer Science, University of Maryland, College Park, Maryland

Thispaper ciscussesresourceutilizationove" the lifecycle of

softwa'e develocxr_ntand discusses_ ro4ethat the current

'_atedal" model plays in the actual software ire cycle.

Softwarepcoduction inthe NASA environmentwasanalyzedto

measure_ clifferermes.The datafrom 13 differentprojects

were oo_lectedby the Software Engineering Labotatocyat

NASA GoddardSpace Fight Center and analyzedfor similetlties and differences.The resultsindcate that the water_

model is not very rea_stic in practice, and that a6 technology

intreducos _ pertts'bal_ortso thismode/withcoctcol0_rdm

executable spec.ifcatkx_, rapid prototyping,and wide-soeclnm_languages, we need tomodifyourmodeloftt_sprocess.

1 INTRODUCTION

As technology impacts on the way industry builds

software, there is increasing interest in understanding

the sol,rare development model and in measuring both

the process and the product. New workstation technology (e.g., PCs, CASE tools), new languages (e.g., Ada,

requirements and specification languages, wide-spectram languages), and techniques (e.g., prototyping,

object-oriented design, pseudocode) are affecting the

way software is built, which further affects how management needs to address these concerns in controlling

and monitoring a software development.

Most commercial software follows a development

cycle often referred to as the waterfall cycle. While

there is widespread dissatisfaction with this as a model

of development, there have been few quantitative studies

investigating its properties. This paper addresses this

problem and whether the waterfall chart is an appropriate vehicle to describe software development. Other

models, such as the spiral model and value chaining,

have been described, and techniques like rapid prototy W

ing have been proposed that do not fit well with the

waterfall chart [1, 2]. This paper presents data collected

from 13 large projects developed for NASA Goddard

Addr¢_ correspondence to Professor Marvin V. Zelkowitz,

Deportment of Computer Science, University of Maryland, Cob

lege Park, MD 20742.

TI_ Jo_mad of Systemt and Sot_vate 8, 331-336 (19S8]

© 1988 Bb_,_,t _ Publiddn s Co, I_c

Space Right Center that shed some light on this model of

development.

Data about software costs, productivity, reliability,

modularity, and other factors are collected by the

Software Engineering Laboratory (SELL a joint research project of NASA/GSFC, Computer Sciences

Corporation, and the University of Maryland, to improve both the software product and the process for

building such software [3]. It was established in 1976 to

investigate the effectiveness of software engineering

techniques for developing ground support software for

NASA [4].

The software development process at NASA, as well

as in most commercial development environments, is

typically product-drive and can be divided into six major

life-cycle activities, each associated with a specific "end

product" [5, 6]; requirements, design, code and unit

test, system integration and testing, acceptance test, and

operation and maintenance. In order to present consistent data across a large number of projects, this paper

focuses on the interval between design and acceptance

test and involves the actual implementation of the system

by the developer.

In this paper, we will use the term "activity" to refer

to the work required to complete a specific task. For

example, coding activity refers to all work performed in

generating the source code for a project, the design

activity refers to building the program design, etc. On

the other hand, the term "phase" will refer to that

period of time when a certain work product is supposed

to occur. For example, coding phase will refer to that

period of time during software development when

coding activities are supposed to occur. It is closely

related to management-defined milestone dates between

the critical design review (CDR) and the code review.

But during this period other activities may also occur.

For example, during the coding phase, design activity is

still happening for some of the later modules that are

def'med for the system and some testing activity is

already occurring with some of the modules that were

coded into the source program fairly early in the

process.

331

0164.- 1212/U/$3.50

5207

2-35
_w

332

In the NASA/GSFC environment that we studied, the

software life cycle follows this fairly standard set of

activities [7]:

1. The requirements activity involves translating the

functional specification consisting of physical attributes of the spacecraft to be launched into requiremeats for a software system that is to be built. A

functional requirements document is written for this

system.

2. A design activity can be divided into tWO subactiv_Z

des: preliminary design activity and detailed design

activity. During preliminary design, the major

subsystems are specified, and input-output interfaces

and implementation strategies are developed.[)udng

detailed design, the system architecture is extended

to the subroutine and procedure level. Data structures

and formal models of the system are defined. These

models include procedural descriptions of the system; data flow descriptions; complete description of

all user input, system output, input-output fdes, and

operational procedures; functional and procedural

descriptions of each module; and complete description of all internal interfaces between modules. At

this time a system test plan is developed that will be

used later. The design phase _pically terminates

with the CDR.

3. The coding and unit test activity involves the

translation of the detailed design into a source

program in some appropriate programming language

(usually Fortran, although there is some movement _0

Ada). Each programmer will unit test each module

for apparent correctness. When satisfied, the programmer releases the module t0 the system iibraian

for configuration centre!.

4. The system integration and test activity validates

that the completed system produced by the coding

and unit test activity meets its specifications. Each

module, as it is completed, in integrated into the

growing system, and an integration test is performed

to make sure that the entire package performs as

expected. Functional testing of end-to-end system

capabilities is performed according to the system test

plan developed as part of preliminary design.

5. In the acceptance test activity, a separate acceptance

test team develops tests based on functionai specifications for the system. The development team provides

assistance to the acceptance test team.

6. Operation and maintenance activities begin

after acceptance testing when the system becomes

operational. For flight dynamics software at

NASA, these activities are not significant with

respect to the overall cost, Most software that is

produced is higidy reliable. In addition, the flight

M. V. Zelkowitz

dynamics software is usually not "mission critical," in that a failure of the software dos not mean

spacecraft failure but simply that the program has

to be rerun. In addition, many of these programs

(i.e., spacecraft) have limited lifetimes of 6

months to about 3 years, so the software is not

given the opportunity to age.

The waterfall model makes the assumptions that all

activity of a certain type occurs during the phase of that

same name and that phases do not _ T_us

requirements for a project occur during' the requirements

phase; all design activity occurs during the design phase.

Once a project has a design review and enters the coding

phase, then all activity is coding. Sincemany companies

keep resource data based on hours worked by calendar

date, this model is very easy to track. However, as

Figure 1 shows, activities overlap and do not occur in

separate phases, We will give more c_ia on this later_

2. THE WATERFALL CHART IS ALL WET

Table I summarizes the raw data on the 13 projects

analyzed in this paper. They are all fairly large flight

dynamics programs ranging in size from 15,500 lines of

Fo_ran code to 89,513 lines of Fortran, with an average

size of 57,890 lines. The average work on these projects

was 8.90 staff-months; thus, all represent significant

effort.

In most organizations, weekly _ sheets are col'

I_ as _ of cost _couni|ng procedures so that phase

data are the usual reporting mechanism. However, in the

SEL, weekly activity data are also collected. The'data

consist of nine possible activities for each component

Table I, Project Size and Staff-Month Effort

Project Size (lines Totaleffort Staffnumber of code) hours' months

1 i5,500 " 17,715 116.5

2 50,911 12,588 82.8

3 61,178 17,039 112.1

4 26,844 10,946 72.0

5 25.731 1,514 10.0

6 67,325 19,475 128.4

7 66,260 17,997 118.4

8 _ __ _b __

9 55,237 i5,262 100.4

10 75,420 5,792 38.1

II 89,513 15,122 99.5

12 75,393 14,508 95.4

13 85,369 14,309 94.1

Average 57.890 13,522 89.0

' All technical effort, iml_lial prolplumer zad mlp_me_ _me.

b Raw data not avtilable in dart brae,

I

m

W

U

g

m

= =

lit

J

ii

5207

2-36

m
Resource Utilization 333

Figure 1. Typical life cycle.

REQUmEMENTS

I I

DESIGN

I

CODE

I I

INTEGRATION

I I

ACCEPTANCE TEST

I I

OPERATION

I

Life cycle CLlendsr Time >

(e.g., source program module). In this paper, these will

be grouped as design activities, coding activities (including unit test), integration activities, acceptance testing

activities and other. Specific meetings, such as design

reviews, will be grouped with their respective activity

(e.g., a design review is a design activity, a code

walkthrough is a coding activity, etc.)

Table 2 classifies the data presented in this paper.

Each column represents a type of work product (design,

code, test). The "by phase" part represents the effort

during that specific time period, while the "by activity"

pan represents the actual amount of such activity.

"Other" does not enter into the "by phase" table, since

these activities occur during all phases. At NASA, 22%

of a project's effort occurs during the design phase,

while 49% is during coding. Integration testing takes

16% while all acceptance activities take almost 13%.

(Remember that requirements data are not being collected here. We are simply reporting the percentage of

design, coding, and testing activities. A significant

requirements activity does occur.)

By looking at all design effort across all phases of the

projects, we see that design activity is actually 26% of

the total effort rather than the 22% listed above. The

coding activity is a more comparable 30% rather than

the 49% listed by phase data, which means that the

coding phase includes many other tasks. "Other"

increased from 12% to 29% and includes many timeconsuming tasks that are not accounted for by the usual

life-cycle accounting mechanism. Here, "other" includes acceptance testing as well as activities that take a

significant effort but are usually not separately identifiable using the standard model. These include corporate

(not technical) meetings, training, travel, documentation, and various other tasks assigned to the personnel.

The usual model of development does not include an

"other," and this is significant since almost one-third of

a project's costs are not effective at completing it. More

on this later.

The situation is actually more complex, since the

distribution of activities across the project is not refleeted in Table 2. These data are presented in Tables 3-

5. Only 49% of all design work actually occurs during

the design phase (Table 3), and one-third of the total

design activity occurs during the coding period. Over

one-sixth (10.3% + 6.4%) of all design occurs during

5207

2-37
w

i

334

Table 2. Development Effort

Project Design Code lmegrafion Accept. test

number (%) (%) act. (%) i_d other (%)

M. V. Zclkowitz

Table 3. Design Activity During Life-Cycle Phases

Project Design Coding Integration Accept. test

number phase (%) phase (%) test (%) phase (%)

m

i

By Phase

I 20.6 38.6 [6.5 24.3

2 16.2 48.4 19.3 16.2

3 21.8 47.9 17.4 12.9

4 35.9 39.5 24.5 0.1

5 18.2 68.8 13.0 0.0

6 16.3 48.6 10.9 24.3

7 19.0 50,4 14.9 . 15.7

8 22.9 48.4 13.0 15.8

9 22,6 68.3 8.1 1.1

10 24.4 44.6 20.2 10.8

I 1 22.7 39,4 21.4 16.5

12 16.9 53.1 10.9 19.l

13 28.2 43,5 20,1 82

Average 22.0 49.2 16.2 12.7

By Activity

I 17.4 16.4 9.9 56,3

2 30.1 39.4 20.8 9,7

3 " 26.3 20.3 19.3 34.2

4 27.3 28.7 6.0 38.0

5 31.0 35.5 9,4 24.1

6 14.9 21.8 24.0 39.2

7 20.2 25.9 14.3 39.6

8 I 1,0 13.9 9.3 65.8

9 31,3 43.5 18.9 6.4

10 38.2 37.3 6.1 18.4

11 29.3 31.0 17.2 22.5

12 23.7 46.5 24.0 5.9

13 32.6 36,3 15.6 15.6

Average 25.6 30,5 15.0 28.9

testing when the system is "supposed" to be finished. In

almost one-third of the projects (4 out of 13), about 10%

or more of the design work occurred during the final

acceptancetesting period.

As to coding effort, Table 4 shows that while a major

part (70%) does occur during the coding phase, almost

one-quarter (16% + 7%) occurs during the testing

periods. As expected, only a small amount of coding

(7%) occurs during the design phase; however, the table

indicates that some coding does being on parts of the

system while other parts are still under design. These

data have the widest variability as a range from 0%

(project 10) to over 22% (project 3).

Similarly, Table 5 shows that significant integration

testingactivities (almost one-halO occur before the

integrationtestingperiod.Once modules have been unit

tested,programmers begin to piecethem togetherto

buildlargersubsystems,with almosthalf(43%) of the

integrationactivitiesoccurringduringthecodingphase.

Due tothewide variabilityofthe"other" categoryin

Table 2, Table 6 presentsthe same data as relative

percentagesfordesign,coding,and integrationtesting

I 41.8 33.9 10,0 14.3

2 53.6 31.2 9.2 6.0

3 33.3 37.1 19.7 9.9

4 45.3 32.6 22.0 0.1

5 17.4 69.1 13.5 0.0

6 58.9 30.7 4.3 6.2

7 63.9 15.3 6.8 14.1

8 28. I 56.9 7. I 8.0

9 61.8 38.2 0.0 0.0

10 57.8 27.2 7,0 8.0

I I 58.7 13.7 16.67 10.9

12 58.9 32.8 5.9 2.4

13 60.5 24.7 11.9 2.9

Average 49.2 34. I 10.3 6.4

with the other category removed. As can be seen, design

took about one-third of the development effort and

varied between a low of 25% and a high of 47%--a

factor of almost 2. On the other hand, coding took an

average of 42% of the relative effort and varied between

36% and 49%--a factor of only 1.36. Testing ranged

from a low of 7.5% to a high of 39.5%, with an average

of 22 %, for a relative factor of over 5.

From Table 2, the "other" category was 29% of the"

effort on these projects, and of the 13 measured projects,

other activities consumed more than one-third of the

effort on six of them. The other category consists of

activities such as travel, completion of the data collection forms, meetings, and training. While these activities

are often ignored in life-cycle studies, the costs are

significant. Table 7 presents the distribution of other

Table 4, Coding and Testing Activity During Life-Cycle

Phases

Project Design Coding Integr/_onAccept.test

number phase(%) phase(%) test(%) phase(%)

I

2

3

4

5

6

7

8

9

1o

I1

12

13

Average

1.4 78.3 11.3 9. I

0.0 72.8 19.7 7.5

22.2 56.2 I 1.8 9.8

16.4 58.5 25. I O. 1

21.2 68.7 10.1 0.0 ,_:

0.5 77._ ..... 1113 10.9

1.3 73.9 15.6 9.2

14.7 54.7 21.0 9.7

5.2 91.1 3.1 0.6

0.0 73.0 _ 22.5 4.5

2.2 70.5 20.1 7.2

0.3 74.8 8.3 16.6

4,6 63.6 26.9 4.9

6.9 70.3 15.9 6.9

iI

m

tp

B

i

lira

5207

2-38
Resource Utilization

Table 5. Integration Activity During Life-Cycle Phases

Coding

Project Design and unit IntegrationAccept.test

number phase(%) phase(%) test(%) phase(%)

1 0.0 _ 17.8 27.4 54.7

2 0.0 45.2 30.1 . 24.7

3 6.1 53.9 21.1 18.9

4 21.0 39.3 39.7 0.0

5 28.4 71.0 0.6 0.0

6 1.0 40.9 17.6 40.5

7 0.5 54.I 26.3 19.2

8 2.9 33.8 19.2 44.1

9 0.0 66.4 29.2 4.4

10 0.0 23.1 41.5 35.5

II 0.0 36.4 35. I 28.5

12 0.1 32.7 22.4 44.8

13 1.5 49.5 28.8 20.2

Average 4.7 43.4 26.I 25.8

335

Table 7. Other Activities Effort In Etch Phase

Coding

Project Design and testing Integration Ac¢¢_, test

number phase(%) phase(%) test(%) phase(%)

I 23,3 32.2 18.I 26.5

2 0.0 9.I 26.4 64.6

3 21.7 47.8 16.8 13.7

4 46.2 30.2 23.6 0.0

5 11.0 67.7 21_3 0.0

6 18.2 4.4.2 9.0 28.7

7 14.4 51.6 14.5 19.5

8 26.5 47.7 I 1.4 14.4

9 15.9 65.5 18.7 0.0

10 12.4 30.2 35..9 21.5

11 21.4 32.2 18.9 27.6

12 47.3 46.6 4.6 1.5

13 42.5 30.0 12.7 14.9

Average 23.1 41.2 17.8 17.9

activities across all phases. While such effort varies

widely from project to project, no general trends can be

observed, except that it does take a significant effort as a .

percent of total costs.

3. CONCLUSIONS

Using data from the SEL database, it seems that the

software development process does not follow the

waterfall life cycle but appears to be more a series of

rapids as one process flows into the next. Significant

activities cross phase boundaries and do not follow

somewhat arbitrary milestone dates. The classical product-driven model has many shortcomings.

In the SEL environment, as well as elsewhere, other

classes of activities take a significant part of a project's

resources, At almost one-third of the total effort, it

Table 6. Relative Activity

Integration

act. ('_)

Coding

Project Design and unit

number act. (%) act. (%)

1 39.9 37.5 22.6

2 33.3 43.7 23.0

3 39.9 30.8 29.3

4 - 44.0 46.3 9.7

5 40.8 46.8 12.3

6 24.6 35.9 39.5

7 33.5 42.8 23.6

8 32.2 40.7 27.I

10 46-8 45.7 7.5

II 37.8 40.1 22.1

12 25.2 49.4 25.5

13 38.6 43.0 18.4

Average 36.2 42.2 21.6

might be part of an explanation of why software is

typically over budget, Estimating procedures often use a

work breakdown structure where the system is divided

into small pieces and estimates for each piece are

summed up. Inclusion of a significant "other*" usually

does not occur.

Newer technology is affecting thistraditionalmodel

even more. In one NASA experiment, a prototype of a

project was developed as partof the requirements phase

[8].In thiscase, 33,000 linesof executable Fortran were

developed at a cost of 93. I staff-months--already a

significant project in this SEL environment. When

viewed as a separate development, the prototype had a

life cycle typical of the data presented here, but if

viewed as only a requirements activity it puts a severe

strain on existing models.

Current models do not handle executable products as"

part of requirements. Other questions arise: Are Ada

package specifications design or code? Are executable

specification languages specification or design? When

does testing start?

It is clear that our current product-driven models need

to be updated. Other models, such as the spiral model,

which is an iterative sequence of risk-assessment decisions, or value chaining, which addresses value added

by each phase, are alternative approaches that need to

enter our vocabulary and be further studied for effectiveness.

AO(NOWt.EDGEMENT

Thls week web padldy suppoled by grant NSG-5123 from NASA

_ S_ Fr_ Caner to U'_eUr_ of U_. Jud_ Sulct

iw0_m meet of _e anaym of _e dat. used b ¢/s r_oa. We mo

wish to acN-K_edge _e helg of Fra'_ _ of NAS/VGSI_ _

oo_-uno and i_amre_ _ c_a used _re.

2-39

5207
336

REFERENCES

I. B. Boehm, A Spiral Model of Software Development and

Enhancement, ACM Software Eng. Notes 11(4) 22-42,

1986.

2. B. Boehm,Improving Software Productivity, Computer

20(9) 43-57, 1987.

3. F. E. McGarry, et al., Guide to Data Collection, NASA

Goddard Space Flight Center, Code 552, Greenbelt, MD,

August 1982.

4. V. R. Basili and M. V. Zelkowitz, Analyzing MediumScale Software Development, 3rd International Conference on Software Engineering, Atlanta, pp. 116-223,

1978.

5.

6.

7.

M. V. Zelkowitz

A. Wasserman, Software Engineering Environment,

Adv. Comput., 22, 110-159, 1983.

M. W. Zelkowitz, Perspective on Software Engineering,

ACM Comput. Sum., 10(2), 198-216, 1978.

F. E. McGarry, G. Page, et al., Standard Approach to

Software Development, NASA Goddard Space Flight

Center, Code 552, Greenbelt, MD, September 1981.

M. V. Zelkowitz, The Effectiveness of Software in

Prototyping: A Case Study, ACM Washington Chapter

26th Tech. Symposium, Galthersburg, MD, pp. 7-15,

1987.

m

IlW

m

Ill

g

w

uF

u

w

il

m

w

li

HMi

m

U

i

I

R

l

5207

2-40 IIg

rl

U '
SECTION 3 - MEASUREMENT ENVIRONMENT

STUDIES
IWiwWWM

:z

Wl wI

_m

imr

iill
v

SECTION 3 - MEASUREMENT ENVIRONMENT STUDIES

The technical papers included in this section were originally

prepared as indicated below.

• "Generating Customized Software Engineering Information Bases from Software Process and Product Specifications," L. Mark and H. D. Rombach, Proceedinq$

of the 22nd Annual Hawaii International Conference

on System Science, s, January 1989

• "Software Process and Product Specifications: A

Basis for Generating Customized SE Information

Bases," H. D. Rombach and L. Mark, Proceedinq_ 0(

the 22nd Ann_al Hawaii International Conferen¢_ On

System Sciences, January 1989

• "The TAME Project: Towards Improvement-Oriented

Software Environments," V. R. Basili and

H. D. Rombach, IEEE Transactions on Software

Enaineering, June 1988

• "Validating the TAME Resource Data Model, ''

D. R. Jeffery and V. R. Basili, Proceedinas of the

10th International Conference on Software

Enuineering, April 1988

5207

3-1
Generating Customized Software Engineering Information Bases

from Software Process and Product Speclficatlonn

Leo Mark and H. Dieter Rombaeh

Department of Computer Science

University of Maryland

College Park, MD 20742

J

U

w

m

Aim•rant

Software engineering is a challenging new application area for

information bases. The new challenges are twofold: how

ooftwaJ'e engineering processesand products can be properly

modeled; and, how such processes and products can be mirrored naturally within an information bw. Meeting these

challenges requires software engineering and information bun

research. Our "Mean Information Base for Software Engineering • project at the University of Maryland represents such a

joint research effort. The idea or our approach is to genert_

customized software engineering information bases from formal

specifications of software engineering proce_scs and producte.

The three central research topics are: (i) develop a software

process and product specification language which permits all

the information necessary to understand, control and improve

any given software engineering process; (ii) develop t sets

information base schema which automatically generates u

information base structure given t software process ted product specification; and (iii) develop a mapping between the

software engineering oriented and information base oriented

models The generator approach acknowledges the fact that

soft.are engineering changes not only from environment to

environment, but also from project to project, if an information base is expected to truly mirror and support a given

software engineering project, it needs to be tailorable to the

changing characteristics of the software project itself. The generator ba_d approach suggested by our project seems to be the

natural approach to satisfy this import•at need.

This i_•per I_'esents the information base oriented part of our

joint project . it discusses how to represent a set of software

process and product type specifications in • database and how

to use these to automatically generate database support for

process executions and product instances.

Introduction

When we began our research on a Met• Information Base for

Soft.are Engineering one of the first future research topics we

identified was object-oriented database Systems. However, u

the reader may •]ready have noticed, the words object-oriented

were not mentioned in the title or abstract of this paper. While

a number of ohject-orienled databa.s_ systems have been proposed in the past few years tDittrich 86], there seems to be

• We hart tho tut, mi_ted • ptF, r dlseu_in| the eof_wtre engintering oriented pitt mr

our proj*et roe th, *¢_o_.w_, ha|inn•ring Pro, ce_l: Model* sad Aald_l_l* gra_| al

this lime mar, tel*re _tombl_b Im_.

3-2

little consensus as to what such a system should be. Although

our rese_rc_h-will eventually le_ o.r venion of an objectoriented dattbue system, we are currently using and extending

existing relational database technology, trying to find out how

far it will take us. Others, following the same approach, have

extended the relational model with more semantics [Codd TO;,

provided better support for complex objects ]Dadam g6:, aqd

extended the data definition capabilities with support for type

inheritance IBorgida $8',. The common goal of these efforts,

best described in [Carey 881, is to use and extend existing relational technology, but to retain<: a powerful non-procedural

query language.

Our joint project is based on the following framework for a

Software Engineering Environment [Rombach 88;:

USER INTERFACE

PLANNING EXECUTION

INFORMATION BASE INTERFACE

INFORMATION BASE

Framework for SEE

This paper concentrates on the following two informalion base

issue:

the represen(ion of t formal specification of • set of

software engi.eering process and product type descriptions using an extended relational data model, and

g

m

W.

m

i

g

u

_I

U

I

Ii

Ia
=

- the automatic generation of information base support for

software process executions tad product instances based

o• their type descriptions.

As • basis for addressing the llnt issue we shall, in section 2,

briefly summarize the set of requirements for • software process

and product specification language (as described in our companion paper IRombsch 881). In section 3, we introduce a

graphical formalism for the extended relational model in section 4, we •how the representationof formal specifications.

The notion of u Self-DescribingDatabase System IMark 85},

brieflydescribed in section5, is the basisfor the generator

approach discumed in section 6.

Requirements for a Software Process and Product

Specification Language

We distinguish between very general requirements which acknowledge the basic nature of software processes and more

specific requirements [Rombach gS]. '

In this section we shall restrict ourselves to listing the speeig¢

requirement, for a software process and product specification

language from s planning perspective and from am execution perspective.

Since we want formal specifications in this language

represented in our software engineering information base, the

specific requirements, from a planning perspective, have direct

bearing on the schema design of the information base. Similarly, since we want to automatically generate information base

support for software process executions and product instances

based on the formal specifications, the specific requirements,

from execution perspective, also have direct bearing on the

schema design.

From • planning perspective, the specific requirements for

the specif, cation language include the ability to specify:

1. process, product, and constraint types

2. produce (output) and consume (input) relationships

between product and processtypes

3L controlflow relationshipsbetween processtypes(sequence,

alternation, iteration, and parallelism)

4. structural relationships between product types (sequence,

alternation and iteration)

5. dependency relationships between process types (Process

PI is dependent of processP2 if every executionof P2

triggers a simultaneous execution of PI. Typically, measu'rement processes are dependent on the construction

processes which they are supposed to monitor.)

6. pre-conditions and post-condition relationships between

constraint and process/product types (A pre-condition of

a process is t constraint imposed upon initiation of this

process; • post-condition of a process is a constraint

imposed upon termination of this process; a condition of a

product is a constraint imposed upon this product.)

7. aggregation and decomposition of process and product

types

ft. generalization and specialization of process and product

types

9. constructive as well as analytic (measurement--oriented)

product and proc_ types

3-3

10 different roles (Different roles are performed in n software

project such as design role, test role, quality assurance

role, or manMement role. Roles define views or perspectives of (a subset of) the processes _d products relevant

to t particular project. Type tad number of roles may

change from project to project.)

II. time (relative and absolute) & space (software structure,

versions, configurations) dimensions

12. dialogues between processes (including human beings)

in section 4 we design the schema for the meta information

base to meet most of these requirements.

The specific requirement, from an execution perspective

for t software process and product specification language

include the ability to handle

!. the instatiation (creation of objects) of process, product

and constraint types

2. long-term, nested transactions (Many softwar_ engineering processes such as designing may stretch over weeks or

months; in addition, the)' may contain nested activities.)

3. varying degrees of persistence (Some information needs to

be kept forever, some only for the duration of the project,

and othersonly untila new instance(eg. product version)has been created.)

4. tolerance of inconsistency (Because of the long-term

nature of software engineering processes, it might be

necessary to store intermediate informs•ann tha* does not

yet conform with the desired consistency criteria)

5. dynamic types (type hierarchies) (an object of type product (e.g.,a compiler developed during one project)may

be used u an objectof type processduring • futureproject.)

6. non--determinismdue to user interaction

7 dynamic changes of process speciEcationtypes (It is

impossible to plan for all possible (non--deterministic)

resultsproduced by human beings in advance However,

we would liketo reactto thosesituationsby dynamically

re-planningduring execution Although it isnot • problem to change a specification during the planning stage, it

might be a problem to change the specifical.ions during

execution while preserving the current execution state.)

8. back-tracking due to execution failures

0. the organization of historical sequences of product objects

and process executions

I0. the enormous amounts of interaction between parallel

activities

!!. the role-specific interpretation of facts (The same process

and product facts mighl require different interpretation in

the contexsof differentroles.)

12.the triggeringof actions(based on pre-conditionsand

post-conditions}

The list of execution-point-of-view requirements is heavily

influenced by the results of a working group during the 4th

International Workshop on Process Specification (More-

.tonhampslead, I.'K, May 1988), chaired by Tom Cheatham

[IW.qPS 88 I, Some of these requirements _ill be meet by our

automatk.ally created information base, hoaever many of them

define topics for future research on information bases.
Graphical Formalism for an

Extended Relational Model

To create t schema for a met, information base that completely and precisely mirrors the fundamental software

engineering concept, we need a powerful data mode] A data

model consists of t language for defining data structures, •

language for defining constraints, and a language for data

manipulation and query processing. We shall primtri]y concentrate on the data structure language in this paper. This

language is an extended version of the relations] mode] with t

number of concepts borrowed from semantic data models and

object orienl, ecl data models.

The ]anffuage supports two kinds of uniquely named domains:

i_icgl and non-lexiegl

." _.-md ".

". , , , ."

Non-lexic,l domains (full circles) model object-sets and lexical

domains (broken circles) model object-name-sets. We shall

aimoet entirely be using non-iexical domains in the

specification. The reason is that we concentrate on modeling

the fundamental software engineeringconcepts and theirrelationships,and postponing the aspectsof how the conceptsarc

lexicallydescribed,represented,and referencedIn an implementation the non-lexicaldomains willbe representedby surrogates [Hall 76 I, which are system generated, internal, unique

identifiers for object&

Since surrogate values •re internal to the system and invisible

to the user we arc primarily modeling the invhtible part of the

met, information base, and ignoring the vhtible part. Several

important observations are related to the use of surrogates:

1. Surrogates allow us to mode] aggregate objects fairly

e_.sily while preserving normalized relation representations. Non-procedural query languages, like relational

calculus, can be used for query processing without change.

If a nested relation representatnon_homa.s if' i was used,

allowing attributes with set values, we would rio]ate first

normal form representations and we would be forced to

use a powerset calculus.

2. Surrogates allow us to model generalization in a straight

for*ard manner [Codd TO,, however a slight generalization of relational calculus is needed if we want to utilize

inheritance in queries.

3, As far as a database system is concerned, anything stored

as an instance of s lex'ical object type is primitive, and all

the database system can do is insert, delete, or retrieve it,

Surrogates are ideal for modeling the structure of new

user defined object types, providing s means for extenstbility. However, the complete structure of an object

must be explicitly represented if the u_er wants to use the

relational calculus to manipulate and answer questions

about the structure of the object.

4. Breaking down everything to obtain an explicit representation of the internal structure of objects may result in.

inefficiencyfrom t system point-of-view However,

current research on view cache and incremental computation models show very promising results [Roussopouloe

87]. Inefficiency from a user point-of-view can basically

be ignored because relational views can be used to define a

higher level query interface when needed.

An arrow between two domains represent an h_-a relation

type. In the example below, the object type O has subtypes O l

nmd 0 2. An is-a relation type represent t total function from

the subtype to the supertype. The _et of is-a relation types

define a directed acyclic graph on the set of domains. Var,ous

rules for inheritance may be adopted, however, inheritance

from multiple supertypes is hard to define properly IBorgida

SSi.

Relation types are uniquely na_md.,d_and are re;resented by the

notation below. Attribute, model the roles of the

corresponding domains in relation, Attribute names may' be

omitted, in which case the correspondinHdomain name is used

However, attribute names must be unique within relations

Identifier constraints (double headed trro_ under an attribute

combination) model partial functions from an attribute combination to each of the other attributes in the relation

KS#4

A.TTR_.'TZ AT'_q

Rather than using relational normalization, we aim at identifying atomic facts. Multiple atomic facts ma> later be combined

into larger relations while preserving at least Boyce-C<_d Normal Form (BCNT) As is customary in object-role data models

we shall model all concepts in terms of domains The role of

the relations is therefore reduced to capture the aggregates

that form the concepts and to relate the concepts An important advantage of our specification language over the traditional relational data definition language is that it clearly *nd*-

cares that only attributes over the same domain can be used as

a basis for entity joins between relations The relational model

traditionally only supports domains of primitive types and does

not support a strong typing concept.

Although some types of aggregate objects, e g abstract syntax

trees, could be conveniently represented by recursively defined

relation types, whatever that is, we have not considered such

an extension of Our model because databases have a hard time

managing instances that are not all of the same structure and

size.

Our approach clearly allows us to use the relational cairn]u|

for data manipulation and query processing.

A significant advantage of this is that a powerful constraint

definlt]on capability may be based on the relational calculus.

3-4

I

1t

I

lib

J

g

lIB

m

m

!

lip

I

g

J

n
Although important, we shall postpone further discussion of

the query language and the constraint capability to a later

paper.

Representation of Proce_*I and Product

Specifications

Before we start, let it be perfectly clear that we are dealing with

tAree levels of ,nformation. What we are aboul to design in

gh_ section tt 4 schema - or rather a mean-schema - that

describes all proce_ and product descriptions that can be

defined in the apecufication language introduced in /Rombach

as/

The data stored under LAinschema are, in olher words, process

and product descriptions and can in turn be interpreted 4J the

schema for process ezecutions and product in.stances under

thr_e descriptions. This issue is discl_ssed I'n section_ 5 and 6

The two fundamental concepts inthe specificationlanguage are

proceal descriptionn and product descriptions

Process descriptions and product descriptions are modeled by

the two domains shown below.

@ ®

Instances of process descriptions and product descriptions are

tied to their type through the insert operation Therefore, a

"member" relationshipneed not be modeled explicitly.

We use the concept proceu reeurmively in two wayn.

First, a process description may be an aggregate of a set of

component process descriptions In an aggregation we form a

concept from existing concepts. The phenomena that are

members of the new concept's extension are composed of

phenomena from the extensions of the existing concepts.

Second,• processdescriptionmay be • generalizationof • more

specific process description, in a generalization we form a new

concept by emphasizing common aspects of existing concepts,

but out special aspects. The phenomena that are members of

the existing concepts are all members of the new concept, and

they therefore inherit all the attributes of the members of the

new concept Aggregation and generalization are classical

themes in object oriented databases [Smith 77].

The aggregate process descriptions ,re modeled below. A

process description may be reused in many aggregate process

descriptions Aggregate process descriptions may have multiple

levels, but cannot be defined recursively, (i.e. • process

description cannot contain itself as a component at any level).

This constraint is not modeled below.

As modeled by the second relation type below, some but not all

process descriptions may have names. We have modeled these

names to be universallyunique.Other models are of course

p0ssibiZe.

Within aggregate process descriptions, the component process

descriptions may be _quentiaJ, alternative, pLrallel, or

lt_rat,ed Only process descriptions that are parts of an aggregate process description can be used in any of these ordering

schemes Since process descriptions may be reused in many

:aggregate process descriptions, the ordering must be aggregate

process description specific. Our approach is to model the restrictions imposed by the ordering schemes Since parallelism is

not a restriction we need not model it. Sequence is, for convenience, assumed to be represented Ln t relation where the

tuples are ordered on the aggregate process descriptions and

subsequently on the component process descriptions. The order

of the component elements will, of course, depend on the lexic,,] representation of their names since it makes no sense to

order on the non-lexical surrogate values Iteration will simply

be modeled M t "goto'.

The generalized process descriptions are modeled below

Notice that a process description may be in more tha_ one generalization, (i.e., we model a generalization net rather than •

generalization hierarchy). However, the generalization net cannot contain cycles: this constraint is not modeled below This

model will provide the information needed to support any

inheritance scheme we may want to adopt.

To complete the two recursive definitions, we must model the

fact thaI an aggregate process description and a generalized

process description are themselves process descriptions.

3-5
This model willprovidethe informationneeded to support any

inheritancescheme we may want to adopt.

We use the concept product reeursivel¥ ha two waya.

First, a product description may be Ln aggregate of a set of

component product descriptionsSecond, a product description

may be a generldizatioof more specializedproduct descriptions.

As modeled by the second relationtype below,some but not all

product descriptionsmay have names We have modeled these

names to be universallyunique. Other models are of course

poisibile.

L._

We model the generalised product descriptions below As

with generalized process descriptions, a product description

may be reused in more that one generalization, (i.e., we model

a generalization net rather than a generalization hierarchy)•

However, the generalizationnet cannot containcycles;thisconstraintis not modeled below

This model will provide the information needed to support any

inheritance scheme we may want to adopt:

To complete the two recursive definitions, we must model the

fact that an aggregate product description and a generalized

product description are themselves product descriptions.

To summarize, we have now modeled how aggregate and generalized process i.nd product descriptions can be defined from

other process and product descriptions Since process and product description instances are tied to their respective type by

insertion,we can summarize our complete model (the dashed

arrows indicate "member" relationships that are maintained

through insertion).

All the non-lexical domains are represented by surrogates

Any information about the objects modeled by these surrogates, including their lexical representation, will be connected

to the surrogates.

The fundamental relationship between pr_ess executions and

product instsncps is that a proem execution uma set of

product instance_ u input and produces a set of product instanceQ u output To model this a_ the process and

product description level, we need the following relation. The

i/o domain consistsof th6 vk|ues_i:o, in).

__li_ilim [/e

Some software methodologies require detailed io information

for each elemenl in a document rather than for the document

as s whole: This requirement is supported by our model

through the use of the recursive definition of process and product descriptions.

The concept of mapping is introduced to allow process and

product descriptions in a project .using one soft.are methodology _o be compared to process and product des(riptions in a

project using a different _f_are methodology. We must provide data structures that help the soft.are e_,gineer define

mappings between proce._s and product descriptions in different

soft.are methodologies. We model a rudimenlary mappi_g

definition capability below.

3-6

1

m

m

i

l

L_

i

J

J

w

=.._.

I

_m

m
±

ORIG_'_\!ALPACE IS

OF POOR QUALITY

Before z mapping can be defined, we may have to use the

recursive process _d product definition capability in order to

bring the concepts we want to compare to the same level of

abstraction. Once this is done we can use the mapping

defnition capability.

The notion of user views is very important. User views are

needed for managers, designers, programmers, etc, In general, a

user view is defined u • consistent collection of product and

process descriptions together with a collection of product

instances and data •bout process executions that conform to

the descriptions and are relevant to a particular project.

The notion of s proce_ pre--constraint and postconstraint on • database is as important as the notion of •

control mechanism in software engineering Since different

pre-constr•ints and post-constraints may apply to awe same

process decription used in different aggregate process des_.riptions, we have to tie the relationship between process description and constraint, to a nartieuhj" ,g_:regate process description. A simple mfdel ,s l-]ll_strateO I:>e|Og'.

Like static constraints in a database, we think •bout the

notion of product constraint as something independent from

the processes that use and produce the product. We therefore

model product constraints as follows:

3-7

We have introduced • large number of databue constraints

between the model of process sad product descriptions and the

• instances of these descriptions The most natural way of maintaining consistency between the surrogates in •n aggregation

and generalization hierarchy is through the use of a well

defined set of operations for insertion s_nd deletion

Maintaining eonslatency between the ]exicaJ repre_Rnta-

• ions is s much more eompiic•ted problem Fortunately,

part of this problem hua very elegant solution

To control the consistency of lexicLI representations we

only store the lexical representations of the stomin process

and product descriptions, •n object is atomic if it is not defined

as •n aggregate or • generalization Lexical representations of

aggregate and generalized process and product descriptions

should merely refer to the other aggregate and generahzed

process and product descriptions and to the atomic process

and product descriptions directly used in their descriptions. To

avoid storing multiple almost identical copies of atomic proce*s

and product descriptions, we shall investigate incremental file

representation techniques where • new file which is •n almost

identical copy of an existing file is represented by • pointer to

the existing file plus • file differential Techniques of this

nature are discussed in [Roussopouloe g7 i.

The lexic•l representation of non-atomic objects can be

materialized through the use of relational views.

Based on the above discussion we can now model the storing

of lexiea] representations of atomic process and product de'*criptlona. What these lexical representations look

like, will of course depend on which language we choose for

their representation.

Currently available database management systems do not

directly support the storing of large, variable size, unstructured

lexical objects A possible but not very desirable solution is to

develop • program that stores these objects on files under

operating system control and stores addresses of the files under

database control.

We model the lexic•l representation of atomic objects as folIOV/S

_la_e d_.mpT

A version normally refers to an object that is almost identical

to another object. In our model, the concepts of process

description and product description can be used to model the

notion of version, and we shall not introduce versions _ a

separate concept,

A configuration normally refers to • collection of versions.

Again, the concept of configuration will not be introduced as •

separate concept because it can be modeled by the concepts

already defined.
ORIGINAL PAGE I$

OF POOR QUALITY

The concept of me-4uremen_ has recently been the subject

of considerableattention in software engineering.Measuremeat ca.ube perceivedas a productinstanceor t processexecution. A measurement can be part of s product instanceor a

product instancein itsown right,or measurement can be part

of a processexecutionor a processexecutionin itsown right A

measurement can thereforebe describedby or as part of a product description,or itcan be describedby or as part of • process description.Therefore,we shallnot introduce measuremeat as a new concept.

Proce_ executionsand product instanceshave severaltime

attributesassociatedwith them. Examples are the actualstart

and end. times of process executionsand the actual time of

creationof product instances Examples of time attributesfor

processand product descriptionsare time of creationand last

time executed and .instantiatedOther time attributesare

.definedon a relativetime scale,(e.g.,one processexecution

must proceedanotherone}.

Time attributesare,however, examples of measurements, and

we shallthereforenot introducethe time concept explicitlyst

this stage.

The purpose of this section has been to provide a formal

schema definitionthat completelyand correct])'mirrorsfundsmental concepts in our process and product specification

language independently of their lexica] representation.

The next step isto definethe lexicalobject-name-setsthat will

allo_ us to referenceand represent the concepts.It is very

important to understand that the information base is completely blind with respect to the internalstructure of the

object-names; it cannot see_ use, or_/naintain any iatert/al

structure of object-names, (eg _ object-name-set may consistof a setof Ads programs, hut they alllook liketextstrings

to the information base) This implies that the maintenance of

any structure of or constraints between object-names is the

sole responsibilityof the usersand softwaretoolsaccessingthe

informationbase.

Self-Describlng Database Systems

A Self-Describing Database System is unique in that it provides an a_tive and integrated daf.a dictionary as part of

the database management system Such a data dictionary system is essential in our system.

The architect ure of a Self-Describing Database System is illustrated _below, iMark 85'v This architecture has recently been

adopted by the ANql; SPARC [Burns S6' as the basis for a new

Reference Model for dataha._e management systems, and it is

the basis for current work in the ISO.

_"-_,........ I

L.................. J

- i , 6,,, ..... .*

C I "b'="I

" i J

_

! I- ]

Architecture of s Self-Describing Database System

The core DBMS supports the well-known point---of-view

dimension of data descriptionwhich consistsof internal,conceptual,and externalschemata. In addition,it supports and

enforces the in_naion--ertension dimension of data description The intension-extensioadimension has four levelsof data

description Application data are stored as data The

application schemata, describing and c0ntrolhng the use of

the applicatldn data., _re stored in the data dictionary The

rule* for defining, managing, and controlling the u_ of

the application schemata are stored in the data dictionary schema A fundamental set of rules for defining sch_

mats, (i.e a description of the data models supported by the

Self-DescribingDatabase System), is defined in the metalebema The set of rules in the mean--schema will allot the

management strategies represented in the data dictmnary

schema to evolve in accordanqe with changing data management policies Each level of data description in the anions,onextension dimension is the extension of the level above it, and

the intrusion forthe !evel below it The m_ta-schema is selfdescribing. (i e. it iS one of the schemata it describes)

The core DBMS can be thought of as a DB.MS stripped to the

bones It supports the Data Language. DL, which is the ont_

language used to retrieve and change data and data descriptions at an)' level in the intension-extension dimension The

DL provides a set of primitive operations on an) data element

or data description element at an)" level in the ,nTensJonextension dimension of data description An) compound operations needed must be implemented as a tool in the Data

Management Tool Box using the primitive operations of the

DL Data Management Tools are plug-compatible with the

core DBMS through theDL. "

The basic idea behind our generator approach is to make the

schema designed in section 4 part of the data dictionary

schema above. By doing this, the process and product description instances created through this schema will be Stored as

data in the data dictionary These data may in turn be interpreted as an application schema controlling process execuhons

and product instances in a specific software engineering project.

The data describing these process execut,ons and product

instances will therefore be stored as part of the application

data.

To make this work, the semantics of insert operations used

through the data dictionary Schema must guarantee that I)

process and product descriptions are inserted t• the data dictionary, and 2) data structures are created at the application

data level to hold protean execution and product instances conforming to these descriptions.

The Generator Approach

To understand the philosophy behind the generator approach

we will consider the data dictionary schema (catalogi of t selfdescribing database system.

One of the most important things contained in the data dictionary schema is a relation of relations Simplified, it looks

somH hang like this:

As can be seen,the firstfew tuplesin the relationof relations

contain a definition of that relation itself(its is self-describing)

and other relations de_,ribing the relational data model. The

next set of tuples define the first two relations we defined in

section 4, namely • aggregate process_dent rapt" and

• process_descript n tree'.

3-8

I

J

" ml

I

g

R

J

gg

gll

I

g

m

I

It

J
ORIGINAL P:_GE IS

OF pOOR Q_AL|T¥

i

w

I

w

l

l

I

I

• ° • • .

! I

• . • - . •

J I

I I

I I

I I

I I

I diIiIi

I I

b"_ u

I

Whenever, a set of tuplesisinsertedinto thisrelationof relations,the semantics of the insertoperationfurthertriggerthe

creationof an empty structureto hold the extension(data)of

the defined relation•This means that the insertionof the

tuples defining • aggregate_process_deseript" and

• process_dcscript_name" in the above example will result in

the creation of an empty structure in the data dictionary to

hold the extensionof theserelations.

Let us now turn our attention to these empty structures.

When we insert tuples in them we are inserting data that in

turn cu be interpreted as defining an application schema.

• m ".

Mn

plI

pill

p14

pIII

pal

p|

pm

pl

pI

All

pII

pll I

plI i

pII i_

pJ4

pill N_

pII If

3-9

In the illustrationabove we have insertedt set of tuplesthal

constitute an aggregate process description The aggregate protess description defines the development (dec) process to consist of analysis(anal),design (des),specnfication(_pee),and

implementation (impl),and it definesthe design to consistof

high-leveldesign (hi_des}and low-leveldesign (IIdes) The

p-valuesare surrogatesproduced by the system.

These aggregate process description will result in the creation

of two empty structures at the application data level, one for

the aggregate development process and one for the aggregate

design process Into these empty structures we can _tore data

about specifice_ecutionsof the defineddevelopment and design

proem.

We could continuethe example by I) insertinginto the relatzon

"aggregate_ process_ descript_ seq" tuples delining the

sequence of the proteges in the development process 2) inserting into the relation "aggregate product_ descript" tuples

defining the products relevant to the development process and

3) insertinginto the relation"process_ product_ i,o" tuples

defining which processes use and produce which products.

However, the example we have Ipven is hopefullysufficientto

illustratethe idea.

Conclusions and Future Research

Ideally, the information base ror software engineering described

in this paper will provide support for the automatic generation

of an information base from t formal specification of a set of

process and product descriptions In order to further develop

this idealized information base, more research in the areas of

soft.are engineering an_d databases is required Although we

only list the major database research issues, we strongly beheve

that success in this research area will depend on the tight

cooperation between the two areas (The soft_are engineering

researchissues are listedin iRomb_h 88]).

Future Database Research Issues

There is currently no data model, let alone a database management system, capable of supporting a met• information base

for soft.are engineering One of the goals of our research is to

develop the concepts and tools that are .mi_ing For now,

we •re taking • very conservative approach, trying to

use and extend existing relational database technology

to see how far it will take us. There are especially two

things from existing relat*onal technology that _e would like to

preserve s non-procedural calculus query language,and a constraint definition capability based on this calculus. V.'e see no

conflict between preserving these and at the same time providing a more object oriented data manipulation interf=ce between

the soft.are engineering oriented model and the database

model on _hich _e have concentrated in this paper.

Providing an object oriented data manipulation

interface between - the software engineering

oriented model and the database oriented model

will be our next major research topic.

We plan to use the insert, delete, and update operations

provided in the relational calculus to program transactions that will allow us to create, aggregate, decompose,

generalize, specialize, and delete procex's and product

descriptions in a consistent way.
Aainformationb_eforsoftwareengineering must ideally be

adaptable to meet the needs for continuously tailoring software

engineering process_ and products to changing project needs

and characteristics of the project environment tad the organius•ins.

AJa import•at reRateh hmue ht therefore the hzmdling of data when its eorreaponding schema

ehadages. The a_lf-de_crlbing database system provide• am idead framework for lave-tigatinl thht

t.-ue,

Given • formal specification of a programming language, s

document form, etc., it is theoretically possible to automatically produce the Jcbema needed to explicitly represent the

interns/structure of all object6 produced according to the forma/ism, is it practical?

A mador research quest|on la where the *invialble"

pm-t of the databue ends ud the °vhtible" part.

begins. Our approach to this quution is to try to

push the ex_tlng database technology am far u

immibhe.

However, we will eventually have to face the problem of complex lexical object types.

A ma_or reNarch problem ia therefore the support

of extensibillty which Lllowa for truer defined lexieLI object ty_.

Two possible solutions, representing the main streams in object

oriented database _•rch, are to provide tool access to complex lexical objects through _he query language or to store user

defined operations on complex iexical object in the database

The difference between the solutions is minor.

A long list of additional research problem can be derived from

the [is_ Of SpecJ_'_=e_cut]on requlrements pr_nted°_tion

2. Many of these research problems are discussed in [Bernstein

87] tad ace not repeated here.

Refereneu

[i_rusteln ST]

P. A. Bernstein, "Database System Support for software

Engineering," Proceedings of the Ninth International

Conl'erenc; an Software Engineering, Monterey, CA,

March 30 -April 2, 1987, pp. 166-178.

ICodd 7'o]

C,odd, E.F., "Extending the Database Relational Model to

Capture More Meaning," ACM TODS 4, No. 4, December

1079.

[Halltel =_............ _ .

Hall, P, Owlets, J., Todd, SJP, "Re]ations and Ent/-

ties," in G.M. Nij,,sen (ed.), "Modeling in Data Base

Management Systems," North-Holland 1976.

Mark, L., "Self-Descrlbing Databases - Formalization

and Realizat/on, ° TR +1494 Department of Computer Science, University of Maryland, April 1085.

Roussopouloe, N., "Incremental Computation Models,"

Department of Computer Science, University of Maryland, 1087

[Rom bach 881

H.D Rombach, L. Mark, "Software Processand Product

Speci6ctti6ns A B_ts rot Generating C.ostumized Information Bucs," Submitted for H]CSS-22 1088.

[Dis•rich 86] =+

K. Dittrich, =Object-Oriented Database Systems: The

Notion and the Issues," Proceedmgs International

Workshop on Object-Oriented Database Systems, Pacific

Grove, CA, Sept. 1086.

[D,dm sol

P. Dadam et al., "A DBMS Prototype to Support

Extended NT 2 Relations: An Integrated View of Flat

Tables and Hierarchies," Proceedings SIGMOD Conference, Washington, DC, 1086.

IBorgida 88]

Alexgnder Borgida, "Modeling Class Hierarchies with

Contradictions," Proceedings SIGMOD. Conference, Chiel.go+ 1988r

[Carey 88]

M+ Ctrey, D. DeWitt, S Vtnderberg. "A Data Model and

Query Language for EXODUS," Proceedings SIG.MOD

Conference, Chicago, 1988

[Thoma_ 86_

S.J Thom_, P.C. Fiscber, "Nested Relational Structures," The Theory of Databases, P C Kannellakis ed.,

JAi Press, 1986.

3-10

U

W

u

I

g

i

J

IIW

n

D

111

g

=__

llw

U

Im
w

SOFTWARE PROCESS & PRODUCT SPECIFICATIONS:

A Baals for Generating Cuftomlsed SE Information Bs_-s

H. Dieter Rombsch and Leo Mark

Department of Computer Science

and

Instltute for Advanced Computer Studies (UMIACS)

Un|vers|ty of Maryland

College Park, MD 20742

Ab_r.t_

Software Engineering is a challenging new application area for

information bases. The new challenges are twofold: software

engineering specific (how can we model software engineering

processes and products properly?) and information base specific

(how can we mirror such processes naturally within an information

base?). Meeting these challenges requires joint software

engineenng/information base research. The Meta Information Base

project at the University of Maryland represents such a joint

research effort. This project aims at generating customized software

engineering information bases from formal specifications of software engineering processes and products. The three central

research topics are to develop (i)a software processspecification

language which allows us to capture all the information necessary

to understand, controland improve any given software engineering

process,(ii)an object oriented information base schema language

which allows us to model the mirroringinformation base structure

for any such software engineering process, and (iii)a mapping

between the software engineering oriented and information base

orientedmodels. Ifan informationbase istruly expected to mirror

a given software engineeringprocess,it needs to be tailorableto

the changing characteristicsof the software process itself.The

generator-basedapproach suggested in our projectseems to be the

naturalapproach to satisfythisimportant need. Software process

and product specificationsare expected to have not only an impact

on generating customized software engineering environment components (such as information bases). Systematic improvement of

software processes and products - learning about software engineering approaches and reusing software engineering related experience

- can not be achieved without having a specificationof the objects

we want to improve. This paper discussesgener_drequirements for

software processspecificationlanguages, presentsa firstprototype

software process specification language, demonstrates the application of this language and derives software engineering related

requirements for a supporting information base. The actual efforts

aimed at implementing these information base requirements are

briefly mentioned in the conclusions.

1. Introduction

Lessons learned from having monitored the software development

and maintenance process over a decade [1, Ill suggesta high-level

improvement oriented software engineering model consisting of

planning, execution, and learning & feedback stages {4]:

* Planning the software engineering process is aimed at defining

plans for developing quality a priori. It includes choosing the

appropriate overall process model as we]] as the specific methods

and tools supporting this process model. It involves tailoring

each of them forthe projectspecificgoals and the characteristics

of the project environment and the organization. Process

models, methods and toolsneed to be planned for constructionLs

_'ellas learningand feedback. The effectivenessof thisplanning

processdepends on the precisionin the specificationof the proeess models, methods and tools (formalis better than heuristic)

and the experienceconcerning their effects.The entireplanning

processas wellas the tailoringprocessneed to be formalized

• Execution of the software engineering processes follows the

plans derived during planning; the existence of construction

guidelineshelps in assuring that process models, methods and

toolsare being used as intended. Itshould he noted that execution includes the construction of the traditional project documents (e.g. requirements, design, code) and all other kinds of

information prescribed by the planning process (e.g., test results,

schedule,effortdata), as well as the analysisof the consLruction

processesand resultingproducts from various (during planning

prescribed)perspectives.

• Learning and feedback followsthe plans definedduring planning. Learning isin part based on the analysisresultsderived

during execution of processes(e.g.,regarding the use of process

models, methods and tools)as well as products.We compare the

actual resultswith the desired results,and feed the lessons

learned hack into the ongoing project (which might result in

iteratingthe projectplans} or into the planning of future projects. Feedback is important to engineers and managers. An

effectivefeedback mechanism isespeciallycrucialfor supporting

the complex management decisionprocess.

Software engineeringprocesses need to possessthe attributes tailorable and tractable. Tailorability is required in order to plan the

software engineering process for the project specific goals and project environment characteristics. Tractability is required in order to

specify processesin an understandable way, construct products

according to these plans, and monitor the construction for the purpose of feedback and learning. The TAME (Tailoring A Measurement Environment} project at the University of Maryland aims at

the development or a measurement, feedback and planning

environment for soft_are engineering [4I. Part of this project is to

develop a software engineering information base. The development

of a process and product specification language (although neeess4u7) is not part of the current scope of the TA,\_; project.

Our Meta Information Base project project at the University of

Maryland represents a joint software engineering/information base

research effort. The basic idea of this approach is to generate customized software engineering information bases from formal

specifications of software engineering processes. The three central

research topics are to develop (i)a software processspecification

language which allows us to capture all the information necessary

to understand, control and improve any given software engineering

process, (ii) an object oriented information base schema language

5207

3-ii
which allows us to model the mirroring information base structure

for any such software engineering pr_ess, and (iii) a mapping

between the software engineering oriented and informatmn base

oriented models. The generator appro_'h acknowledges the factthat softwac¢ engineering processes change from environment to

environment, but .Iso from project to project. If an information

base is truly expected to mirror.,,. A given software engineering procuss, it needs to be tallorahle to the changing characteristics of the

software process itself, The generator-based approach suggested by

our project seems to be the n_tural approach to satisfy this import.ant need. Generating customised software information bases is

not the sole application of software process specifications. We are

also investigating the benefits or software specifications for the purpose of better understanding, planning and improvement of software engineering related aspects. We believe that learning about

software engineering tad reusing software tngineerin[i related

experience cU not be doric in a systcmatic way wlthouf-specWylng

the objects of learning and reuse - the software processes o themselves. In order to do s good job of learning and reuse, measuring

and analyzing the software processes and their effects seems to be t

very helpful mechanism We therefore suggest not only to model

the construction oriented software engineering aspects, but also the

analysis oriented ones.

Based on our improvement oriented TAME software process model,

we anticipate the following framework for supporting software

engineering processes (see figure I):

USER INTERFACE

F • r

! PLA2qNING EXECUTION

II_TORMAT!ON BASE INTERFACE

INFORMATION BASE

Figure 1: Framework for SE Proem Support

Each software engineering project consists of a planning and execution stage. During the p]annlng phase plans (specifications) of all

project relevant processes and products get developed; the execution stage consists of conducting the project according to these

plans. The underlying information base stores all process and product plans as well as the information derived during execution of

these plans.'The plans themselves provide the basis for structuring

the execution-derived information. Storing such information tcro_

projects results in historical information bases. Improvement can

then be achieved by structuring this information appropriately

(based on process plans), and reusing it during the planning and

execution phase of future projects after tailoring it to the specific

characteristics of these future projects. Figure ! suggests'that We

need to specify software processes and products for different perposes: to support the planning actlvltles at the user interface, to

allow the internal representation of plans, and to support the

storage and retrieval of plans and information derived during exe5207

eution according to plans. In our project,we expect to use three

different (but compatible) specification languages in order to sat*sfy

the differentneeds of each pe_eetive.

This paper p.resentsthe software engineeringorientedpart of our

jointproject , ItdiscussesKeneradrequirements for software pro-

¢ess specificationlanguages, presents first prototype software

specificationlanguages (one to support the planning activitiesat

the user interface,one to represent,plans internally),demonstrates

the applicationof these prototype languages,and derivessoftware

engineeringrelatedrequirementsfora supporting informationbase.

The informationbase relatedwork of our project,aimed at implementing these software engineering oriented information base

requirements,isnot partof thispaper.

2. Reaulr.emente for SoAwsre Process & Product Sveclflcation

We distinguish between very general requirements which acknowledge the basic nature of software processes/and more eo_ete

requirementswhose relative importance depends on the purpose of

software processand product specifications.

General requir_enta for a software process specification |snguage include the abillty-to- _

I. specify all aspects that seem to be important within a given software project (and not to be Limited to a specificset of aspects):

This requirement acknowledges the fact,that thereexistno commonly acceptedsoftwareprocess models today_--±z= _:_ ......

2. specify w{tE Varying degrees of detail and to refine initial

specifications in the future am we learn: This requirement acknowledges the fact that our understanding of some processesis

insufficient, of others is pretty precis#_

3. deal with creative and mechanical aspects of software processes

in different ways (e.g., behavioral specifications for creative

aspects and algorithmic specifications for mechanical aspects):

This requirement acknowledges the fact that software processes

includeboth creativeand mechanical aspects,and that we must

deal with both in a natural wlt_ _ "

4. easily modify prc_ess specifications:This requirement acknowledges the constant need for tailoringprocessspecifications

to changing project or environment needs. _:=

Spec|fle requirements (from a planning perspective) for a

software process and product specification language include the

ability to specify

1- process, product, and c0nstrainCtyp_ _ _

2. use (input}an_d-p_ocTu_e(output) relationshipsbetween pr_esS

and product types

3. (pre-and post-)condition relationshipsbetween constraintand

process/product types (A pre-conditionof a processis a constraint imposed upon initiation of tl'fi*sproce_;_a'_t-cond|/.ioo

of a process is a constraint imposed upon termination of this protess; a condition of a product is a constraint imposed upon this

product.)

4. control fiow relationships between process types (sequence, alternation,iteration, and parallelism]

5. structural relationshipsbetween product types (sequence,alternation and iteration)

8. dependency relationship between process types (Process PI is

dependent on process P2, if ever5" execution of P2 triggers simultaneous execution of Pl. Typically, measurement processes are

dependent on the constructionprocesses they are supposed to

monitor.)

7. aggregation and decomposition of process and product types

* We prtstnt *,u_htt patti ditc_sslnS tat iafocmttlo_ %_m orhet*d ptr_. of oar

proitct during the 'Duttbut Formalisms, So_twt/e a. Srtt_ms" session _ th*u

ssme eonferenet [lO].

3_12

U

m

R

I

m

E

g

m

m

I

I

mm

m

l

!

g

I

I

i

===_

W

m
8. generalization and specialization of process and product types

g. constructive as well as analytic (measurement oriented) product

and process types

10. different roles {Different roles are performed in s softwace project such as design role, teat role, quality assurance role, or

management role. Roles define views or perspectives of (a subset

of) the processes and products-relevant to a particular project.

Type and number of roles maj,_hange from project to project.)

11. time (relative and absolute) & space (software structure, versions, configurations) dimensions

12. non-determinism due to user interaction

SpeeWc requirements (from an execution perspective) for a

software proce_ and product specification language include the

ability to handle

I. the instantiation (creation of objects) of process, product sad

constraint types

2. long-term, nested transactions {Many software engineering

processes such as designing may stretch over weeks or months; in

addition, they may contain nested activities.)

3. varying degrees of persistence (Some information needs to kept

forever, some only for the duration of the project, and others

only until a new instance (e.g., product version) has been

created.)

4. tolerance of inconsistency (Because of the long-term nature of

software engineering processes, it might be necessary to store

intermediate information that does not yet conform with the

desired consistency criteria.)

5. dynamic types (type hierarchies) (an object of type product (e.g.,

a compiler developed during one project) may be used as an

object of type process during a future project.)

6. dialogues between processes (including human beings)

7. dynamic changes of process specification types (It is impossible

co plan for all Ixzsible (non-deterministic) results produced by

human beings in advance. However, we would like to react to

those situations by dynamically re-planning during execution.

AJthough, it is no problem co change a specification during the

planning stage, it might be a problem to do it during execution

and preserve the current execution state.)

S back-tracking due to execution failures

g. the organization of historical sequences of product objects and

process executions

10. the enormous amounts of interaction between parallel activities

11. the role-specific interpretation of facts (The same process and

product facts might require different interpretation in the context

of different roles.)

12. the triggering of actions (based on pre- lad post-conditions)

The list of executlon-point-obview requirements is heavily

influenced by the results of a working group during the 4th International Workshop on Process Specification (Moretonhampstead,

UK, May 1988), chaired by Tom Cheatham [12].

$, Prototype Process & Product Specification Lan agggg_

Several research projects are working towards improving the software development process from various perspectives: Arcadia [13],

TAME [2, 3, 4], GEN_S1S [15], and others [12]. No consensus

seems to be reached as to what an appropriate specification language should look like in order to be both capable of describing the

important process and product aspects and acceptable co the

intended user.

We believe that no single specification language will satisfy the

needs of software engineers as well as the designers of the information base. Based on our SEE model in figure 1, we believe that

there is a need for at least three different language representations:

* the application level language, which is used to support the

task of specifying the relevant process and product aspects during the planning stage (at the user interface "of our SE process

model in figure 1). This type of specification language should

accommodate the needs of its potential users (e.g., software

engineers, managers).

• the intermediate level language, which is used to represent"

the results of the planning stage_ This type of specification language should emphasize completeness, consistency, and preciseness. Complete in this context means executable, independent of

whether this execution requires user interaction or not.

• the information base level language, which is used to formulate the storage and retrieval needs of software processes and

products. These needs encompass the process and product

specifications themselves as developed during the planning stage.

as well as the information accumulated during the execution of

those plans during the execution stage. This kind of language is

usually referred co as schema language.

In addition, we need to provide for transformations between adjacent language levels. The application level language representation

of s particular software engineering process or product (e.g the

design process) eventually needs to be transformed into the

appropriate information base level language representauon

(schema). This transformation must preserve consistency. The

intermediatelevel language representationcan be looked at as a

reference representation acceptable to both the soft-are engineering and information base perspective. The separation provides

independence of application and information ba_e representations

and it _lows us co co separate the entire research area into two

clearly distinguished but connected (via the intermediate level)

areas. Ideally,these transformations should be automaxed; this

would allow us to completely hide the information base view from

the software engineerand vise-versa.

In the followingtwo subsections,we introduce firstprototype languag--sfor the applicationand intermediatelevel.

3.1. A Prototype Application Level SDeclfication Laneuaae

Our prototype process and product specification language for the

application level is graphically oriented. At this point it provides

graphical elements satisfying the first eight specific planning

oriented requirements listed in section 2:

1. Three kinds of object types: process types (represented

u boxes), product types (represented u circles), and constra[nt types (represented u rhombs).

Figure $.l(a): Object Typm

The concept process is used for all kinds of software engineering

activities. It comprises the elements of our high-level software

engineering model (planning, construction, learning and feedback), overall software process models such ar the "water fall"

[7, iS], "iterative enhancement" [5]or "spiral" [8i model, complex methodologies such as the "C]eanroom" [91 methodology.

particular methods and tools such ss "top-down design" or

"Jackson design", and even individual statements of an

automated tool.

The concept product is used for all kinds of software engineering

information. It comprises the plans for construction and learning

and feedback produced by the planning process of our high-level

_ftware engineering model, deliverable products produced by

5207

3-13
ORIGINAL PAGE IS

OF POOR QUALITY

the construction process such as requirements, design, code, but

ale0 test data, schedule, resources, *nd all kinds of measurement

data.

The concept conaraint is used to represent -ll kinds of software

engineering conditions (pre-conditions for the execution of a proeess and post-conditions whick.are e]teclte_ at process termini*

tion time}. Constraints may _r_ be imposed on products.Constra_nts are used to model schedules, completeness criteria or any

other kind of quality or productivity characteristic. Constraints

are basically expressed as boolean expressions.

2. Two kLnds of relations l_tween process and product

tylp_J: the use relation (repreannted u • anlid Lrrow connetting • product and a proceu type) and the produce

relation (represented ms a solid arrow connecting a procese and s product type)

®

Flzur' $.l(b): Use/Produce Rel*tio_

In figure 3.1(b), process of type PI uses products of type Hal and

Ha2 and produces products of type OPI, OP2, and OP3.

The relations use and produce are used to explicitly express all

kinds of information needed for executing a process and resulting

from itsexecution Used information can range from experience

(for example, in the form of historicaldata), to products produced during the same project by other processes, products produced during prior projects, and characteristics of the project

and project environment. Produced information can range from

deliverable products {e.g. design or code documents} to measurement data or even new process and pro4uct descriptions based

on learning.

$. Three kinds of relationships between constraint types

and protege or product types: prt_condltion, portcondition, condlt;on (represented u solid double _rrows).

<

Figure $.l(e): Constraint Relations

In figure 3.1{c), constraint of type ¢1 is • pre-condition for a pro*

cess of type PI; constraintof type c2 isa post-conditionfor •

process of type PI; constraint of type c3 is a condition of a product of type P2.

The conJfraint relationships are used to explicitly express all

conditions that need to be fulfillec_bei'ore :sta_ r or dter-tet;m_ation of a process, but cannot be expressed via use/produce relationships or explicit contro] flow rel&tionships between processes.

5207

3-14

Examples are schedule, and all kinds of quality and performance

requirements. In addition,constraint relationshipsare used to

express expected characteristics or a p_duct; e.g., maximum

complexity.

4. Four kinds of control flow relations between process

types: t_e sequence, _erhd£idn, Wter-_,_;jK-_-d paisa'

relations (represented an solid arrows between procem

types; parallel control flow is indicated through the augmentation of the corresponding arrows with "11").

The semantics of sequential control flow is obvious. The semantics of alternate control flow is to execute exactly one of the

alternatives. The selection criterion can be expressed in terms of

a pre-condition on each of the alternative processes. AJternation

is completely deterministic if each of the alternate processes

possesses a pre-condition and all pre-conditions are mutually

exclusive. It is possible to have nondeterministic alteration (no

constraints} or incomplete alternation (no alternative applies

under certain circumstances), The semantics of iterative control

flow is to execute some process repeatedly. The negated termination criterion is provided in form of a pre-condition to the

iterated process. It is possible to Specify indefimte iteration (no

termination constraint) The semantics of parallel control flow is

to execute allparallel processes independent of each other However, all of them must be completed in order to satisfy the parallel c0ntro] _OW relation_

Figure $.l(d): Control Flow Relatioxm

In figure 3A(d), process of type P1 is in sequence with process of

type P2, processes of type P5 and P6 are alternatively executed

after P4, process of type P3 is iteratively executed, and processes

of type PB and P9 are executed in parallel (independently}. The

decision whether to execute P5 or P6 can be based on two

mutually exclusive pre*conditions C5 and C6.

Note: The graphical symbols for data and control flow are distinguished by their context..Arrows representing data flow connect processes and products, whereas arrows representing control

flow connect just processes.

6. Three kinds of structural relations between product

typee:'the sequence, alternation, and ;teration relations

(represented in the same way as control flow between

process types).

The relation 'sequence' indicates the sequential composition of

two products; the relation 'alternation' indicates the alternate

inclusion of either of two products, and the relation 'iteration'

indicates the repeate<[occur_ehce of a product COormore times)i

We use the same relation names to express the control flow composition of process types and the structural composition of product types to minimize the number of concepts_

6. A dependency relationship between processes

(represented u dotted double arrows between two

processes).

m

m

m

..mm

m

u

I

Im

U

m.,

m

mm

EE

m_m

lie

mm

mE

B

lib

I
w ORIGT[_,_ALPAGE IS

Of: POOR QUALITy

"' ]

IE

I " I

r

Figure $.1(e): Dependency Relation

In figure 3.1(e), P1 is dependent on P2.

The dependmaey' relationship is used to express • very tight

form of parallelism between processes. The relation is directed

and defines • master-slave relationship in the sense that whenever the master process is in execution, the slave process gets

executed too. This means more than just to start end terminate

at the same time; it means absolutely synchronised execution.

This concept allows us to model the measurement of software

processes. For example, if we have a design process and we

would like to collect all the effort spent on designing, we model

the design process as the master process and the effort measuresent process as the slave process.

7. A _elation between process or product types allowing for

decomposit|on and asgregatlon: the is_part..of relation

{represented &Is dashed arrows lul_ented with the relation i_,,se)

,_ _r, @,T$-

._.. ®.=-.®

Figure -q.l(f): Decomposltion/Aggresatlon Relations

In figure 3.1(f), process type PI is decomposed into (and completely substituted by) process types Pll to Pln. Product type

P2 is similarly decomposed into product types P21 to P2m

We need to allow for decompoa_Non and agfref,,tion of process

and product types. The decomposition is necessary to describe

the refining of some process or product into more precise (less

abstract) processes or products.

Note: Decompositions are level complete. This means, if a protess type PI is decomposed in process'types PII, PI2, PI3, and

PI4 (see (6)), then these four processes together make up the

entire functionality of PI (they entirely substitute PI)!

For example, the overall process "development" might be refined

into "requirements analysis', "design', "coding', etc.; similarly,

we can refine the product "deliverable•" into products "requiremeats document', "design document", "source code documents',

etc.

Decomposition is also necessary in order to reflect the hierarchy

of product structure. For example, "system" might be recursively

decomposed into "subsystems", "components" and "modules'.

We use the concept process recursively in two ways. Each process type can be decomposed into lower-level process types or can

be included into the aggregaNon of higher-level process types.

This use of the term process can reduce the difference between

an informal method and s concrete automated tool supporting

this method to a difference in the degree of formalism in the

specification. Whereas the method might be described in inferreal English, the tool might be the complete algorithmic formMization of the same process. The second possibility of using protess types recunively is _pecioluation and feneralization. In the

case that one method can be automated by a variety of tools

alternatively, we can view the tools as specializations of the

method, or the method as a generalization of those specific tools.

We use the concept product recursively in the same two ways as

processes.

The relations lef_eacc, _dternaf_on, iteration and paralleliarn (see

4.)are used in the context of decomposing and aggregatingprotessor product types.

The semanticsof these relationsin the contextof a processtype

decomposition isas follows:Each decomposed processtype either

(a) inherits the entire set of use and produce relations of the

aggregated process types, (b) inherits parts of the use and produce relationsof the aggregated process types,(c) uses product

types produced by a differentdecomposed processtype and produces product types to be used by a different decomposed process

type, or ill possible combinations of (a), (b), and (c). According

to (2), each decomposed process type requires at least one produet type for use and production. The functionality of the aggregated process type is identical to the functionality achieved by

alldecomposed processtypes ifexecuted accordingto theircontrolflow relationships.

8. A relation between process or product types allowing for

specialization and generalization: the is i relation

(represented u duhed &trows augmented with the relation nine)

.:v p.

i •

Figure $-I(s): Speciallaation/GeneraIisation Relations

In figure 3.1(g), each of the process types PII to Pin is a specializationof processtype PI, and each of the product types P21 to

P2m isa specializationof product type P2. P1 isa generalizationofeach of the Pll to Pln and P2 isa generalizationof P21

to P2m

We need to allow for apcc_eHzaHon and gcneraHzoHon of process

" and product types. Generalization of s set of process and product types allows to group them according to some common

aspect.

For example, we can generalize compilers for all kinds of languages to • general compiler process that translates am aigorithmic source code document into object code. Another example

is viewing all tools supporting a specific method alternatively as

specializations of that method.

In addition we satisfy the specific planning oriented requirements 9

and I0 as follows:

9. We encourage the awareness of constructive and analytic process and product aspects. Again, the control flow

and structural relations defined for the graphical notation allow

for representing all kinds of decompositions and aggregations.

The success of software projects depends on a sound integration

of constructive and analytic aspects as indicated by our highlevel software engineering model. This fact does not mean that

we should not view them as different aspects.

The constrlctit, c aspects are concerned with generating products,

while the analytic aspects are concerned with secondary informa5207

3-15
tion derived from monitoring and Lnaiysing constructive

processes and products.

10. We allow for the deflnltlon of different roles. Roles ace

defined _s projections onto the set of process and product types

defined for some project. They define specific views or perspectives. Different views may include the same process or product

type. For example, the desisrr_bte and the quality assurance role

may both be interested in the design product, but from very

different pempectives. Whereas the design role is interested in

how he can build the design product best, the quaJity assurance

role is emphasizing the adherence of the design product tc stated

qusJity requirements. One role may be performed by sevend

people, or one person may execute several roles. The number of

roles is not predefined, but rather project specific. Roles ace

defined explicitly In practice, different roles will very often be

specified by people with different project experience.

We believe that the concepts kud principles presented in this section provide a promising basis for building process and product

specification languages. The objective is to be able to specify all

aspects of a nor%ware proceSS or product (completely), according to

a set of unifying principles (consistently}, and to the [eve[ of detail

possible due to the nature of the problem and our understanding

(precisely).

3.2. A Prototype Intermediate Level Svee' LanEusae

The intermediate level specification language is specified in BNFstyle. Appendix (A) contains the syntax rules necessary to specify

proceSS types. The necessary context rules are not included in

Appendix (A).

This language allows us to specify a given process type (or product

type) at any desirable and possible level of detail. Each process

type specification consists of a procc,e_hesding and a process_body.

The process headlng describes the unique processtype_name,

wheream the processbody contains the actual specification. The

process_body consists of a proeeisjpecification_part, a

role..#pccQ_e_tlom p_rt, and a re#o_eee_suqnmcnt part. The

process_specification_par_, contains in intcr/ace._port, a

rcfincmcnt..part, and an _mplcmcntaffon_part. The interfaee_pa_

characterizes the used and produced product types and the

attached constraint types. The refinement_part describes the

r_finement of this process type into lower level processes (includes

dso the refinement or the related products and constraints) and

defines their connections st this lower level. The implementation

part contains the final algorithmic implementation of * process

type. Refinement and implementation pacts exclude each other;

either a process type sets refined further or it is at its final level of

derail. Refinement and implementation parts are optinnal. The

role_specificatinn_part defines all roles. Roles elm be viewed as

'super' processes. The resource_assignment_part amaignsresources

to processes and/or roles. The resources are specified like product

types. This includes the ability to refine them. [r we have several

organizations of people involved in executing a certain process, we

can model each organization m a resource consisting of people

resources. The pe0duct 6ody of product" type specifications consists

only of a refinement_par/and i,nplcmentaffon_part.

This prototype language allows us to satisfy the planning oriented

specific requirements llsted in section 2. The current languqe

definition is by no means final. We plan on using it ss an experi*

mental vehicle allowing us to validate whether tl_e Chosen concepts

are sztisfactory for speclfying all kinds of process and product

related software engineering aspects.

/. ADvlication of the Prototyve Sveclflcstion Lanfuafes

The validity and usefulness of our software engineering process

model depends on whether we are able to (a) generate specifications

for all kinds of process Lnd product types using our languages, (b)

make project personnel use the specification languages during planning as well as the generated specific models during execution and

learning and feedback, and (c) generate an information base supporting the planning of process and product types (store and reuse)

and the execution of instantiations of process and product types

(e.g., instantiation itself, storing information accumulated during

execution) ........

So far we have been able to specify a number of process and product types using our graphical notation. The specified process

types include a variety of existing proiect models (eg. l17_j) _ well

as specific development methods: The completely automated version of a process type is a too[. We would be able to represent any

structured implementation of a tool using our control flow relations.

The answer to part (b) requires more work. h seems that our process model and languages will be useful during planning for

describing aspects of constructionand learning and feedback sm

well as the consumed and produced products completely, precisely

and as formal as possible It should also help execution and learnink and feedback in that itshould be ea_, to followthese kinds or

complete, consistent and precise plans. The degree to which execution can be supported will depend on the degree to which we will

be able to satisfythe specific,execution oriented requirements

listedin section2.

Our initial answer to part {c) is presented in ilOi. -.

In this section we will apply our two prototype specification languages to a small example. W'e will introduce the example in section 4.1, demonstrate the use or the graphical prototype application

[eve]language in section42, and show how the fin"]plans c_n be

represented using our prototype intermediate level language in section 4.3.

The example we have chosen to demonstrate the applicability or

the two prototype languages is a subset of the design related

aspects out of the context of a larger project

The examp/e can be characterized as follows;

Specify a process type for the design phase (named 'design') that

consumes a requirements product type ('r') and produced a design

product type ('d').The design process type consistsof two sequential design sub processes for high-leveldesign ('hldesl_n')and

low-level design ('U_design') We want to use methods for highlevel design ('yourdon') and low-level design ('pdl'). The design

process will start on date t_l, and has to be completed by dace t_3

t1_3 High-level dtdign should be completed by date t_2 =ffi

t_1-_1. In addition,the artuM effortspent for high -leveldesign

('hleff') and low-level design ('lleff'). the number of low-level design

errors ('llerr'), and McCabe's complexity of the low-level design

products ('v') must be measured for qu*]ity assurance purposes. A

low-level design product will not be accepted if its complexity

v_ue exceeds 20. The design process will be performed by five

people. One person is assigned to perform the high-level design.

Three people, including the person who performed the high-leveldesign, arc assigned to perform the low-level design. A fourth person is assigned to peer?rathe quality assurance activities; a fifth

person is assigned to mznage the project.

_2. Specification of the Exam_l_e__J_d_

We apply our graphicalnotation to specifyallaspectsof the exam*

pie describedinsection4.1. except the sesignment or people. The

sequence of specification steps is not predefined We have chosen to

i

J

i

mm

Ell

im

m

mm

m

!

J

m

i

i

!

mm

5207

3-16

m

I

I
ORIG,,..A,.. P_,_ IS

oF. POORQUALITY

!

specify the example according to the three identifiable roles

(designer, quality assurance, manager):

I. DESIGN ROLE:

1.1. Specification of the use and produce relationships associated

with process type 'design':

Figure 4.2(a): Specification of design process and producta

Figure 4.2(a) describes our initial specification of the example

described in section 4.1.

1.2. Decomposition of process type 'design' into 'hldesign' and

'H_design' (with sequential control flow) and decomposition of

product J,ype 'd' into 'hid' and 'lid' (with sequential structure):

," '_ h 'lmrt':al

_j,J •

Figure 4.2(b): Deeomlxmition of 'design' and 'd'

Figure 4.2(h) describes the decomposition of process type

'design' into process types 'h]..design' and ']ldesign'. The

control flow between 'hi_design' and 'll._design' is sequential;

the aggregation of product types 'hid' and 'l]d' into.'d' is

sequential.

1.3. Decomposition of 'hi_design' into 'yourdon' and 'lid' into

'pcU':

b___d

' _................. '® ':'

Figure 4.2(e): Decomposition of 'hi_deslgn' and 'll design'

Figure 4.2(c) describes the decomposition of process type

'hi. design' into 'yourdon' and product type 'lid' into 'pdl'. The

decomposition relation is used to describe this refinement; in

addition, we could also use the specialization relation to indicate that 'yourdon' is a specific instance of 'hl design' and

'pdl' of _]d'.

2. QUALITY ASSURANCE ROLE:

" 2.1. Specification of measurement 0rien_d process and product

types:

II II, I

Figure 4.2(d): Spec_cat_on of meuurement processes

Figure 4.2(d) describes the measurement of 'hlerr' via process

type 'counterrors', 'hhlT' via process type 'count_hi_eft', 'Heft'

via process type 'count_ll. eft', and the McCabe complexity 'v _

via process type 'compute..v'. The process types 'count_errors',

'count_hi_effort' and !count_ll._efl'ort' are dependent on process

types 'yourdon', 'yourdon' and ']l_design', respectively.

2.2. Specification of constraints:

r--, _ s_,tw_ i m.

Figure 4.2(e): Specification of process and product constraints

Figure 4.2(e) describes how the constraint types e_l, c2, and

c_3 (which use the boolean expressions 'calendar_time = t1',

'calendar_time <-- t2', and 'calendar_time <-, t3') are

assigned as pre-condition co 'yourdon', post-condition to 'yourdon', and post_condition to 'II design' respectively• The constraint type c4 which uses the boolean expression 'v (pdl) >

20' is assigned as a pre-condition to 'll._design' to indicate

another iteration.

3. MANAGEMENT ROLE:

4.1. SpeeiaIisatlon of 'hi_design' and 'lld':

• _- --_ ........... ,

Figure 4.2(I): Specialization of 'hi design'

Figure 4.2(0 describes how the specific design method 'yourdon' can be categorized as a specialization of the process

%I_design'. There exist other possible specialiZationsl e.g., the

object oriented design method 'ood'.

4.$. Sveelfieatlon of the Example (Intermediate Level)

In this section we give _ example as to how the specification information produced using ,he application level language in section 4.2

is represented internally using the intermediate level specification

language. Each of the objects (process and product types) mentioned in section 4.2 is represented by a separate intermediate level

specification. However, each specification will combine all the information that relates to a specific object completely, independent of

5207

3-17
the sequence in which it ha_l been created.

As an example, see give the specification of the process type

'design'. This specification includes the refinement of 'design' into

"eldesign' and 'll_design _ (step 1.2 in section 4.2.), and all related

quality umuranee aspects (see steps 2.1. sad 2.2. in section 4.2.).

The intermediate specification _of this scenario is contained in

Appendix (C).

The interlace_part contains product types 'r' and 'd' as well as

constraint types 'c._l' and "c..3". The next refinement level is

described in terms of decomposed types (see decomposition_ptrQ,

imported proccml, prodsct, and con, traint I),pc spcc/fications (see

use_.pu."Q, and rsla:ions _etlv_en all tAose types (see

connection.part). The '*' is used in the decomposition_part to

indicate that a non-determined number of vrocesses Of type

'11 design' needS to be instantiated (for each module one). Each of

these instantiations will produce a product of type 'lid'. The

rolespeclfication,part identifies _11 roles recording to the way

information was provided at the user interface level (see section

4.2.). In the resource_a_signmeht_oart, people resosrees (p_l, ..-,

P_5) are assigned to execute certain roles ('quality assurance_role',

'msaagementGole') and/or process types ('hi_design', 'll..design').

/_da S_eiflcatlon of the Examole (Information Bue Level]

The example in APPENDIX (C) is only one of the specifications to

be stored in a supporting software engineering information base. A

complete I_t of specification objects according to our example is

contained in Appendix (B). Remember, these objects comprise

only the planning part of what needs to be stored in an information base. In addition, the information base must be capable of

storing all the information derived during execution of these proee_m type specifications.

_Informatlon Base Reouiremeuta!

"['he role of software engineering information bases is to mirror the

software processes and products rehvant to a project or entire

environment. Assuming our improvement oriented software proce_t model (consisting of planning and execution stages for each

project), a supporting information base needs to be capable of storing the process plans as well as the execution derived information.

In our case, plans are the intermediate process specifications introduced in section 3.2 and demonstrated in section 4.3. These plans

could also provide the necessary information for organizing the execution derived information. Obviously, in the case of our example

in section 4, we would like to see ,11 the plans listed in Appendix

(B) stored in an information b_se.

A list of important requirements for designing an information base

interface are identical with the requirements (genera] and specific)

listed in section 2. Additional requirements can be found in [6, 14].

The specific planning oriented requirements that are expected to

allow us to specify all aspects of software processes and products

seem not to be the problem as far as the information base is concerned. It is not clear at this point, whether all the execution

oriented specific requirements can be easily satisfied with state-ofthe-art database technology. It is not even clear, whether all these

execution-oriented requirements should be dealt with inside a persistent database at all. Our first approach to generating a software

engineering information bast from process and product

specifications is described in [10],

5207

0. (_urrent Status and Future Work

The specification research goal of our project is to develop a formal

language for specifying all aspects of software processes and products in u complete, consistent and precise way We do not believe

that all aspects cam be formalized in an algorithmic manner. How--

ever, we believe that even those creative aspect_ can be described

as integrated into the overall software development and mmntenonce process; this integration would make them accessible to concrol to a certai n degree. We have developed first prototype langnage definitions and have them manually applied to specify small

but realistic software engineering scenarios. This limited experience seems to indicate that the concepts chosen for our languages.

are promising. We need to further experiment with these languages

and refine them. We be!ieve that feedback from a variety of people is essential in order to improve the m incrementally. It is however, not realistic to expect other people to apply our languages

manually. Therefore, the mc_t important next step is to prototype

both languages. Out of the list of twelve planning oriented specific

requirements, we are least satisfied with our solution to representink the relationship between time and space dimensions Our

current specification approach seems to be too static. [t isnot pos-

*ibis to convey to a user the fact that, e.g., in the case of our

example in section 4, we have to instsatiate the low-level design

proce_ for eaehm_ul_.._at has been identified during high-level

design (or even for each person and module?). Other important

research aspects are related to the execution-related specific

requirements listed in section 2. Most of all, we have to come up

with a good mechanism for instsatiating process and product

types.

The information base research goal of our project is to develop an

(eventually) object oriented information base interface supporting

the planning sad execution stages of software projects_ The design

of this information b,,,e interface is inspired by the software

engineering oriented requirements. Eventually, we would like to

generate customized information bases from process and product

specifications. We have developed a first approach for mapping

process sad product specifications into a information base schema

I10]. We have implemented a first prototype information base

(based on relational database technology). This prototype will be

used as a vehicle for validating and improving our approach. For

the future, it is planned to integrate this prototype into the prototype of the measurement and evaluation system TA,N/_ I2, 3, 4].

The major future research issues besides refining and automating

our prototype specification languages are to effectively support the

reuse of process specifications, their tailoring to new project needs,

the different roles of a single process specification (role specific

interpretation of facts), sad all the execution oriented specific

requirements listed in section 2.

L_f,_o_az!aliam

We are aware of the huge dilemma between the need for specifying

software processes & products and the unsatisfactory degree of

knowledge how to do it properly_ Understanding software processes

better is necessary for making progress in software engineering.

Being able to specify a process is the fundamental basis for sound

understanding, training, execution, control and improvement as

well as generating appropriate automated support.

Our two prototype specification languages reflect our current

understanding of how to capture the important process and product related aspects. We believe strongly that the only way of

improving our current understanding is experience from practical

application. This requires us to have some initial language notation. This statement should clarify the fact that we do no_ view

3-18

m

I

mm

i

m

mmm I

!

mm

m

m

m

I

I

m

w

U

I

N

m

I

m

m

m

R

!

!
DRIGINAL _,_ _- i-:-, .:r_. !S

OF POOR Q_ALIT_

these initial language definitions as being final. They represent a

vehicle for furLher learning The initial applications (one of which

is described in this paper) have already helped us in understanding

important process specification issues as well u in giving us a sense

of the potenti -I and limitations of our approach.

We will continue refining our languages based on experience. We

are espeei*lly interested in using.such process specifications as.

basis for generating customized environment components, e& soft.

ware engineering information bases If01. We hope that this paper

will inspire other groups involved in process specification research

as well as result ia feedback from those groups regarding our initial

approach.

8. Aeknowledzements

The authors would like to thank John Marsh and Bradford T.

Ulery for their reviews of an earlier version of this paper; Gregory

A. Hansen and Marc I. Kellner for organizing a mini-track on software engineering processes; and all the reviewers for their many

helpful comments,

[I] V.R. Basil*, "Can We Measure Software Technology: Lessons

Learned from 8 Years of Trying," Proc. Tenth Annual Software Engineering Workshop, NASA Goddard Space F]ight

Center, D¢¢. 1985.

[2] V.R. Basil*, H. D. Rombach, "TAME: Tailoring an Ada

Measurement Environment,* Proc. Joint Ada Conference,

Arlington, VA, pp. 318-325, March 1987.

[3] V.R. BMili, H. D. Rombach, "Tailoring the Software Process

to Project Goals and Environments," Prec. Ninth International Conference on Software Engineering, Monterey, California, pp. 345-357, March 1987

14i V.R. Basili, H. D. Rombach, "The TAME Project: Towards

Improvement- Oriented Software En,;ironments," [EEE Transactions on Software Engineering, vol. SE-14, no.8, pp. 758-

773, June 1988.

[51 V.R. Basili, A. J. Turner, *lterative Enhancement: A Practical Technique for Software Development,* [EEE Transactions

on Software Engineering, vol. SF_,-I, no. 4, Dee. i975.

!61 P. A. Bernstein, "Database System Support for Software

Engineering," Pro¢. Ninth International Conference on Software Engineering, Monterey, CA, pp. 166-178, March 1987.

[71 B W. Boehm, "Software Engineering," IEEE Transactions on

Computers, vol. C-25, no. 12, pp. 1226-1241, Dee. 1976.

t8] 13. W. Boehm, "A Spiral Model of Software Development and

Enhancement," ACM Software Engineering Notes, vol. II,

no. 4, pp. 22-42, Aug. 1986.

[9] M_ Dyer, "Cleanroom Software Development Method," IBM

Federal Systems Division, Bethesda, Maryland, Oct. 1982.

[10] Leo Mark & H. Dieter Rombach, "Generating Customi,ed

Software Engineering Information Bases from Software Process and Product Specifications," Pro¢. HICSS-22, January

1988.

[II] F. E. McGarry, "Recent SEL Studies," Pro¢. Tenth Annual

Software Engineering Workshop, NASA Goddard Space

Flight Center, Dec. 1085.

[12] Pro¢. Fourth International Workshop on Software Process

Specification, Moretonhampstead, UK, May 1988 It° be published in ACM Software Engineering Notes].

[13 i L. Osterweil, "Software Processes are Software Too,* Proc

Ninth International Conference on Software En_neermg.

Monterey, CAi pp. 2-13, March 1987.

[14] M. H. Penedo _: E. D. Stuckle, *PMDB - A Project Master

Database for Software Engineering Environments," Pro¢.

Eighth International Conference on Software Engineering,

London, U'K, pp. 150-157, Aug. 1985.

[15] C. V. Ramamoorthy, Y. Usuda, W. Tsai, and A. Prakash,

"GENESIS: An Integrated Environment for Supporting

Development and Evolution of Software," Proc. COMPSAC,

1985.

[16] W.W. Royce, *Managing the Development of Large Software

Systems: Concepts and Techniques,* Prec. WESCON, Aug.

1970.

[171 W.W. Royce, "Managing the Development of Large Software

Systems," Proc. Ninth hternationa] Conference on Software

Engineering, Monterey, CA, pp 328-338, March 1987.

APPENDIX (A): Intermediate Level Language Definition:

_) START 'L.4NnuAoW" OPL_k41bAAR':

SR_I: _.4flm> _:-- <pc_..pSH,> I <prsduet .*In>

--) START 'PROCESS PLaN GRAMMAR':

SR_9_ <@_,esw pin> ::-- <pr_,s,_ba,dlal> _¢,_m.bILb.>

" _> START 'PROgrESS.PLAN HEADING O_AMMAA':

SR_J; <4m_emm_baodUql > ::_ <pr_u¢_,?y,¢_same> : PRO<:ESS PLAN _t_mmml >

_ START 'PROC1ESS_PLANJI_DY CRAMk4AR':

<;re**two_liked*cited.pitt > _m_r¢_ m_m_msjm_>

_> ST,_RT 'PRO_S$_PLAN_$P£_r ICA_ON_PA_T GKAMMAR':

_" START ?R_._S II_:G"I_'I_A_'ION Rrri_qEM_'?¢T_PART GRAMWIAR'_

SR_I#: <l_ecm___h_emes¢ J_w_> ::. REfINEMENT_PAR.T:

<d_¢ompomki*m.p_ >

SRII_ _ ___brt_ r:m L'SE_PART= <q_¢ t_e__et bedy >

SR_{_: _J___a__pm bed_) ::. <gbrvT._y1_> 1,0_brsry_ty,pe_. ,_s,p41_ _e.,pl,'q_bedy)

l <,,"at>

<:pre_ dec* ripe lit ;e_ ), <pr sce_ _d_ elp4pe_ea .pa65 )

SR I1_: _4_rm d_wmpetitlell> :!_ _._¢_¢e_ t71_.l_sm > D[_Ot4POSll.S_lN,ro

SR_I_: <ff'e4h__dl_-_ mp_wt_>*" ::-- <_'*d__tyl)_ _, > D[OOI,(POSES IN TO

SR__: <_-*d_tt ¢_> ,-.. <:$1_I_LAN_I >

<e o_,t r sire derempoms_m >, _¢_e_e_mt deee mp4*;_iom.psa5 >

< ,,_._ _*_t> x=rdl_LAN_l>

5207

3-19
ORIGINAL PAGE IS

OF POOR QUALITY

APPENDEK (B): Process ,nd Product SpecU%.mion 7_pe,

(Ex.mple of *ectio. 4.1.):

¢I;

_mlm; imlm *PlsmPl -

. : ¢_,

b,l_4*.,_; _ M de,,t

- - ; c__+

_rde_ _wN_ll_+lm; ¢.q;

p.L

Imiell: p I:

APPENDIX (C): Proce_.. Sp, eciflcatlon of p,oce, 'des;+

(Example of section 4.1. _:

|llltl ): P ROC'I_ PL,AJ_

OOMMENT: **.'"'"""

I;ROCE3_ SPECIFICATION.PART:

COMMENT: .*.---------;

_q_ERFACE_PART:

COMMENT: *****eeoeee

CONSUM r_: r:

PRODUCES: d;

CONSTR_TS: c_t. ¢..I;

REFINEMENT PART:

COMMENT: .e.e._._

¢OWtI _t_ cqmmt bi _ t-ram4 II _ ml_4 PROCESS pLaN

_k_y_ k L-_. ]Id[, v: PRODUC_'_P[.AN;

¢_t, ¢_4(_1)! CONSTRAINT

DECOM POSe'ION_PART:

d_ip DECOMPOSES_INTO Mo4m_+ I_

d DECOMPOSESJNTO bid, IM ;

CONN£CT3ON_PART:

kl_d_m U5£3 _,

b_'[_;l_ PRODUCI%S bid.

ll_d_¢a PRODUCWS lid.

rmmt_*e_ PRODUCE.S bJ_.

_t b; _i*n PRODUCES bldl.

e_l i el_.t PRODUC_S

_omlmte _ USrS I_.

cempu_ = PRODUCIPS _.

M+d*.q. 5E_ (P*,RXLL (H__')),

_m_l _ DI_PrND$ ON hi dm_sL

¢_t kl ,Ibrt DEPENDS_ON _J__*_m,

c_t_I__llert D_Pr_Os_oN II_dlq_.

ITER (lll _sip,¢ l||,

c l IS PRECONDITION_FOR bl d_qpk

¢_I IS POST_CONDI_ON POX fl__mK

¢J IS_POST_CONDITION.FOR bl__,

c4 I$_PRE CONOI_ON_OR ll._m_;

tM PLEM ENTATION _PARI_

COM MENT_ *'+''"+'+"

+ ±

_OL_.SP EI_'_rlCATION .PART:

COMMENT: **"'""""

_TERrACE: r. kid+ Id. c_l, e_, ¢JI, c.t

INT_RPAC_: ¢.I, ¢.+, ¢I. 14, _, _. M, +

bl_dmiln, l_dmql, Id

ACTIONS ¢+_ml._+ere, cmmt J_J_ef[_t, cNt_,_de_,

_mmpu__+

IN_RPAC=E+

ACTIONS: .

RESOU R C__AS$1G N M EN T_PART:

CX:)MM EHT_ **+.n.u.

use _p_utl_.

p_l, p_l. p_l, p_4, p_l: R_U_

OONN r C'TION PART:

p__! IS.._SSIGNIrD_TO IN.4e_IL

pjI ISJ*SSIGNED.TO II d_qlk

p_ IS._SSJGNED_'ro I_d_

p_ IS__SSIGNED TO l__

p¢ IS__SSIGNED.TO _p,=lh? M_rice__

lS_SIG__T_ Iron.lemming,

i

i

=_

mm

1111

II

m

lm

= =

mm

t

il

U

u

m

i

5207

3-20
758

The TAME

[EEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 14. NO 6. JUNE 1988

Project: Towards Improvement-Oriented

Software Environments

VICTOR R. BASILI, SENIOR MEMBER, IEEE, AND H. DIETER ROMBACH

Abstract--Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software

engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis

into the construction process.

In the TAME (Tailoring A Measurement Environment) project at

the University of Maryland we have developed such an improvementoriented software engineering process model that uses the goal/question/metric paradigm to integrate the constructive andanalytic aspects

of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper

and more systematic way about the software process and product, and

feeding the appropriate experience back into the current and future

projects.

The TAME system is an instantiation of the TAME software engineering process model as an 1SEE (Integrated Software Engineering

Envi(onment). The first in a series of TAME system prototypes has

been developed. An assessment of experience with this firstlimited prototype is presented including a reassessment of its initial architecture.

The long-term goal of this building effort isto develop a better understanding of appropriate 1SEE architectures that optimally support the

improvement-oriented TAME software engineering process model.

Index Terms--Characterization, execution, experience, feedback,

formalizing, goal/question/metric paradigm, Improvement paradigm,

integrated software engineering environments, integrationof construction andanalysis, learning, measurement, planning, quantitative analysis, software engineering process models, tailoring, TAME project,

TAME system.

I. INTRODUCTION

XPERIENCE from a dozen years of analyzing software engineering processes and products is summarized as a set of ten software engineering and fourteen

measurement principles. These principles imply the need

for software engineering process models that integrate

sound planning and analysis into the construction process.

Software processes based upon such improvement-oriented software engineering process models need to be tailorable and tractable. The tailorability of a process is the

characteristic that allows it to be altered or adapted to suit

ManuscriptreceivedJanuary15. 1988. This workwas supportedin pan

b.yNASA underGrantNSG-5123. the Air Force O1_c¢of Scientific ResearchunderGrantF49620-87-0130, andthe Office of NavalResearchundo4"GrantNOOOI4-85-K-0633to the University of Maryland.Computer

time was providedin pan throughthe facilities of the Computer Science

Center of theUniversity of Maryland.

The authors are with the Departmentof Computer Science andthe Institutefor AdvancedComputer Studies. University of Maryland,College

Park,MD 20742.

IEEE Log Number8820962.

a set of special needs or purposes [64]. The software engineering process requires tailorability because the overall project execution model (life cycle model), methods

and tools need to be altered or adapted for the specific

project environment and the overall organization. The

tractability of a process is the characteristic that allows it

to be easily planned, taught, managed, executed, or controlled [64]. Each software engineering process requires

tractability because it needs to be planned, the various

planned activities of the process need to be communicated

to the entire project personnel, and the process needs to

be managed, executed, and controlled according to these

plans. Sound tailoring and tracking require top-down

measurement (measurement based upon operationally defined goals). The goal of a software engineering environment (SEE) should be to support such tailorable and tractable software engineering process models by automating

as much of them as possible.

In the TAME (Tailoring A Measurement Environment)

project at the University of Maryland we have developed

an improvement-oriented software engineering process

model. The TAME system is an instantiation of this TAME

software engineering process model as an ISEE (Integrated SEE).

It seems appropriate at this point to clarify some of the

important terms that will be used in this paper. The term

engineering comprises both development and maintenance. A software engineering project is embedded in

some project environment (characterized by personnel,

type of application, etc.) and within some organization

(e.g., NASA, IBM). Software engineering within such a

project environment or organization is conducted according to an overall software engineering process model (one

of which will be introduced in Section II-B-3). Each individual software project in the context of such a software

engineering process model is exeucted according to some

execution model (e.g., waterfall model [28], [58], iterative enhancement model [24], spiral model [30]) supplemented by techniques (methods, tools). Each specific instance of (a part of) an execution model together with its

supplementing methods and tools is referred to as execution process (including the.e,construction as well as the

analysis process). In addition, the term process is frequently used as a generic term for various kinds of activities. We distinguish between constructive and analytic

methods and tools. Whereas constructive methods and

tools are concerned with building products, analytic

0098-5589/8810600-0758501.00 © 1988 IEEE

5207

3-21
BASILI AND ROMBACH: THE TAME PROJECT

method and tools are concerned with analyzing the constructive process and the resulting products. The body of

experience accumulated within a project environment or

organization is referred to as experience base. There exist

at least three levels of formalism of such experience bases:

database (data being individual products or processes),

.... t-- .

mformatton base (mformatmn being data vtewed through

some superimposed structure), and knowledge base

(knowledge implying the ability to derive new insights via

deduction rules). The project personnel are categorized as

either engineers (e.g., designers, coders, testers) or managers. -

This paper is structured into a presentation and discussion of the improvement-oriented software engineering

process model underlying the TAME project (Section IlL

its automated support by the TAME system (Section III),

and the first TAME system prototype (Section IV). In the

first part of this paper we list the empirically derived lessons learned (Section II-A) in the form of software engineering principles (Section II-A-I), measurement principles (Section II-A-2), and motivate the TAME project by

stating several implications derived from those principles

(Section II-A-3). The TAME project (Section II-B) is presented in terms of the improvement paradigm (Section

II-B-1), the goal/question/metric paradigm as a mechanism for formalizing the improvement paradigm (Section

II-B-2), and the TAME project model as an instantiation

of both paradigms (Section II-B-3). In the second part of

thifp/iper we int_e-TAME system _is aSria-pp-roa-c_

to automatically supporting the TAME software engineering process model (Section llI). The TAME system

is presented in terms of its requirements (Section III-A)

and architecture (Section HI-B). In the third part otVf_s

paper, we introduce the first TAME prototype (Section

IV) with respect to its functionality and our first experiences with it.

II. SOFTWARE ENGINEERING PROCESS

Our experience from measuring and evaluating software engineering processes and products in a variety of

project environments has been summarized in the form of

lessons learned (Section II-A). Based upon this experience the TAME project has produced an improvementoriented process model (Section II-B).

A_ _Eessbns Eearned frbm lrasi Experience

We have formulated our experience as a set of software

engineering principles (Section II-A-I) and measurement

principles (Section II-A-2). Based upon these principles a

number of implications for sound software engineering

process models have been derived (Section II-A-3).

1) Software Engineering Principles: The first five

software engineering principles address the nee_ for developing quality a priori by introducing engineering discipline into the field of software engineering:

(PI) We need to clearly distinguish between the role of

constructive and analytic activities. Only improved construction processes will result in higher quality software.

Quality cannot be tested or inspected into software. An759

alytic processes (e.g., quality assurance) cannot serve as

a substitute for constructive processes but will provide

control of the constructive processes [27], [37], [61].

(P2) We need to formalize the planning of the construction process in order to develop quality a priori [3],

[16], [19], [25]. Without such plans the trial and error

approach can hardly be avoided.

(P3) We need to formalize the analysis and improvement of con%truction processes and products in order to

guarantee an organized approach to software engineering

[31, [251.

(P4) Engineering methods require analysis to determine whether they are being performed appropriately, if

at all. This is especially important because most of these

methods are heuristic rather than formal [421, [491. [661.

(P5) Software engineers and managers n_ed real-time

feedback in order to improve the construction processes

and products of the ongoing project. The organization

needs post-mortem feedback in order to imp-rove the construction processes and products for future projects [66].

The remaining five software engineering principles ad_

dress the need for tailoring of planning and analysis processes due to changing needs form project to project and

environment to environment;

(P6) All project environments and products are different in some way [21, [66]. These differences must be made

explicit and taken into account in the software execution

processes and in the product quality goals [31, [161, [19],

[251.

(P7) There are many execution models for software engineering. Each execution model needs to be tailored to

the organization and project needs and characteristics [21,

(P8) We need to formalize the tailoring of processes

toward the quality and productivity goals of the project

and the characteristics of the project environment and the

organization [16]. It is not easy to apply abstractly defined

methods to specific environments.

(P9) This need for tailoring does not mean starting from

scratch each time. We need to reuse experience, but only:

after tailrrifig _t t0the projeci [ i l, [2][ i6h 17ii [i 8ii [321.

(PlO) Because of the constant need for tailoring, management control is crucial and must be flexible. Management needs must be supported in this software engineering procesL

A more detailed discussion of these software engineering principles is contained in [17[.

2) Software Measureme,t Principles. The first four

measurement principles address the purpose of the measurement process, i.e., why should we measure, what

should we measure, for whom should we measure:

(MI) Measurement is an ideal mechanism tbr characterizing, evaluating, predicting, and providing motivation

for the various aspects of software construction processes

and products [3], [41, [9], [161, [21], [251, [481, [561.

[57]. It is a common mechanism forrelating these multiple aspects.

(M2) Measurements must be taken on both the soft5207

3-22

w

m

m

I

g

I

_-i

m

=

m

B

I

m

=_

J

u

m

i

H

M
w

m

760 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL 14, NO 6, JUNE 198g

ware processes and the various software products [ 11, [5],

[14], [29], [38], [40], [42]-[44], [47], [541-[56], [65],

[66]. Improving a product requires understanding both the

product and its construction processes.

(M3) There are a variety of uses for measurement. The

purpose of measurement should be clearly stated. We can

use measurement to examine coy effectiveness, reliability, correctness, maintainability, efficiency, user friendliness, etc. [8]-[10]. [13], [14], [16]. [20], [23], [25], [41],

1531, [571, [61].

(M4) Measurement needs to be viewed from the appropriate perspective. The corporation, the manager, the developer, the customer's organization and the use_" each

view the product and the process from different perspectives. Thus they may want to know different things about

the project and to different levels of detail [3], 116], [19]_,

[25], I66].

The remaining ten measuremeht principles address metrics and the overall measurement process. The first two

principles address characteristics of metrics (i.e., what

kinds of metrics, how many are needed), while the latter

eight address characteristics of the measurement process

(i.e., what should the measurement process look like, how

do we support characterization, planning, construction,

and learning and feedback):

(M5) Subjective as well as objective metrics are required. Many process, product and environment aspects

can be characterized by objective metrics (e.g., product

complexity, number of defects or effort related to processes). Other aspects cannot be characterized objectively

yet (e.g., experience of personnel, type of application,

understandability of processes and products); but they can

at least be categorized on a quantitative (nominal) scale

to a reasonable degree of accuracy [4], [5], [16], [48],

[561.

(M6) Most aspects of software processes and products

are too complicated to be captured by a single metric. For

both definition and interpretation purposes, a set of mettics (a metric vector) that frame the purpose for measurement needs to be defined [9].

(M7) The development and maintenance environments

must be prepared for measurement and analysis. Planning

is required and needs to be carefully integrated into the

overall software engineering process model. This planning process must take into account the experimental design appropriate for the situation [3], [14], [19]. [22],

[66].

(M8) We cannot just use models and metrics from other

environments as defined. Because of the differences

among execution models (principle P7), the models and

metrics must be tailored for the environment in which they

will be applied and checked for validity in that environment [2], [6]-[8], [121, [23], [31], [40], [47], [501, [51],

[62].

(M9) The measurement process must be top-down

rather than bottom-up in order to define a set of operational goals, specify the appropriate metrics, permit valid

contextual interpretation and analysis, and provide feedback for tailorability and tractability [3], [16], [19], [25].

(MIO) For each environment there exists a characteristic set of metrics that provides the needed information

for definition and interpretation purposes [21].

(MI 1) Multiple mechanisms are needed for data collection and validation. The nature of the data to be collected (principle M5) determines the appropriate mechanisms [41, [25], [48], e.g., manually via forms or

interviews, or automatically via analyzers.

(M12) In order to evaluate and compare projects and

to develop models we need a historical experience base.

This experience base should characterize the local environment [4], [13], [251, [34], [44], [48].

(M 13) Metrics must be associated with interpretations,

but these interpretations must be given in context [3], [16],

II91, [251, [34], [561.

(MI4) The experience base should evolve from a database into a knowledge base (supported by an expert system) to formalize the reuse of experience [11], [14].

A more detailed discussion of these measurement principles is contained in [17].

3) Implications: Clearly this set of principles is not

complete. However, these principles provide empirically

derived insight into the limitations of traditional process

models. We will give some of the implications of these

principles with respect to the components that need to be

included in software process models, essential characteristics of these components, the interaction of these components, and the needed automated support. Although

there is a relationship between almost all principles and

the derived implications, we have referenced for each implication only those principles that are related most directly.

Based upon our set of principles it is clear that we need

to better understand the software construction process and

product ('e.g., principles PI, P4, P6, M2, M5, M6, MS,

M9, M10, MI2). Such an understanding will allow us to

plan what we need to do and improve over our current

practices (e.g., principles P1, P2, P3, P7, P8, M3, M4,

M7, M9, MI4). To make those plans operational, we

need to specify how we are going to affect the construction processes and their analysis ('e.g., principles PI, P2,

P3, P4, P7, PS, M7, M8, M9, MI4). The execution of

these prescribed plans involves the construction of products and the analysis of the constructive processes and

resulting products (e.g., principles P1, PT).

All these implications need to be integrated in such a

way that they allow for sound learning and feedback so

that we can improve the software execution processes and

products (e.g., principles.,]_l, P3, P4, P5, P9, PI0, M3,

M4, M9, MI2, MI3, MI4"). This interaction requires the

integration of the constructive and analytic aspects of the

software engineering process model (e.g., principles P2,

M7, M9).

The compofients and their interactions need to be formalized so they can be supported properly by an ISEE

5207

3-23
BA$1LI AND ROMBACH; THE TAME PROJECT

(e.g., principles P2, P3, PS, P9, M9). This formalization

must include a structuring of the body of experience so

that characterization, planning, learning, feedback, and

improvement can take place (e.g., principles P2, P3, P8,

!'9, M9). An ideal mechanism for supporting all of these

components and their interactions is quantitative analysis

(e.g., principles P3, P4, MI, M2, M5, M6, MS, M9,

MI0, MII, MI3). "-

B. A Process Model: The TAME Project

The TAME (Tailoring A Measurement Environment)

project at the University of Maryland has produced a software engineering process model (Section II-B-3) based

upon our empirically derived lessons learned. This software engineering process model is based upon the improvement (Section II-B-1) and goal/question/metric paradigms (Section II-B-2).

1) Improvement Paradigm: The improvement paradigm for software engineering processes reflects the implications stated in Section II-A-3. It consists of six major

steps [3]:

(I i) Characterize the current project environment.

(I2) Set up goals and refine them into quantifiable questions and. metrics for successful prdject performance and

improvement over previous project performances.

(I3) Choose the appropriate software project execution

model for this project and supporting methods and tools.

(I4) Execute the chosen processes and construct the

products, collect the prescribed data, validate it, and provide feedback in real-time.

(I5) Analyze the data to evaluate the current practices,

determine problems, record the findings, and make recommendations for improvement.

(I6) Proceed to Step l l to start the next project, armed

with the experience gained from this and previous projects.

This paradigm is aimed at providing a basis for corporate learning and improvement. Improvement is only possible if we a) understand what the current status of our

environment is (step IlL b) state precise improvement

goals for the particular project and quantify them for the

purpose of control (step I2), c) choose the appropriate

process execution models, methods, and tools in order to

achieve these improvement goals (step I3), execute and

monitor the project performance thoroughly (step [4), and

assess it (step 15). Based upon the assessment results we

can provide feedback into the ongoing project or into the

planning step of future projects (steps I5 and I6).

2) GoalQuestion/Metric Paradigm: The goal/question/metric (GQM) paradigm is intended as a mechanism

for formalizing the characterization, planning, construction, analysis, learning and feedback tasks. It represents

a systematic approach for setting project goals (tailored

to the specific needs of an organization) and defining them

in an operational and tractable way. Goals are refined into

a set of quantifiable questions that specify metrics. This

paradigm also supports the analysis and integration of

761

metrics in the context of the questions and the original

goal. Feedback and learning are then performed in the

context of the GQM paradigm.

The process of setting goals and refining them into

quantifiable questions is complex and requires experience. In order to support this process, a set of templates

for setting goals, and a set of guidelines for deriving q_estions and metrics has been developed. These templates

and guidelines reflect our experience from having applied

the GQM paradigm in a variety of environments (e.g.,

NASA [4], [17], [48], IBM [60], AT&T, Burroughs [56],

and Motorola). We received additional feedback from

Hewlett Packard where the GQM paradigm has been used

without Our direct assistance-J39], it n_/eds to be Stressed

that we do not claim that these templates and guidelines

are complete; they will most likely change over time as

our experience grows. Goals are defined in terms of purpose, perspective and environment. Different sets of

guidelines exist for defining product-related and processrelated questions. Product-related questions are formulated for the purpose of defining the product (e.g., physical attributes, cost, changes, and defects, context), defining the quality perspective of interest (e.g., reliability,

user friendliness), and providing feedback from the particular quality perspective. Process-related questions are

formulated for the pU-rlx,ge-ofdeflning]He process (quality

of use, domain of Use), defining The quality perspective

of interest (e.g., reduction of defects, cost effectiveness

of use), and providing feedback from the particular quality perspective. _ :...... : ..... _ ....

• Templates/Guidelines for Goal Definition:

Purpose: To (characterize, evaluate, predict, motivate, etc.) the (process, product, model, metric, etc.) in

order to (uncle/stand, assess, manage, "engineer, learn,

improve, etc.) it.

Example: To evaluate the system testing methodology

in order to improve it. -

Perspective: Examine the (cost, effectiveness, corre'ctness, defects, changes, product metrics, reliability,

etc.) from the point of view of the (developer, manager,

customer, corporate perspective, etc.)

Example- Examine the effectiveness from the developer's point of view.

Environment: The environment consists of the following: process factors, people factors, problem factors,

methods, tools, constraints, etc.

Example: The product is an operating system that must

fit on a PC, etc.

• Guidelines for Product-Related Questions:

For each product under study there are three major

subgoals that need to be addressed: 1) definition of the

product, 2) definition of the quality perspectives of interest, and 3) feedback related to the quality perspectives of

interest.

Defini-tio, @the product includes questions related to

physical attributes (a quantitative characterization of the

product in terms of physical attributes such as size, cornw

J

t

U

t

g

i

W

d

i

ilw

m

r

r

ibm

5207

3-24

r
762

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 14, NO. 6, JUNE 1988

plexity, etc.), cost (a quantitative characterization of the

resources expended related to this product in terms of effort. computer time, etc.), changes arid defects (a quantitative characterization of the errors, faults, failures, adaptations, and enhancements related to this product), and

context (a quantitative characterization of the customer

community using this product and their operational profiles).

Quality perspectives of interest includes, for each

quality perspective of interest (e.g., reliability_ user friendliness), questions related to the major model(s) used (a

quantitative specification of the quality perspective of interest), the validity of the model for the particular environment (an analysis of the appropriateness of the model

for the particular project environment), the validity of the

data collected (an analysis of the quality of data), the

modM effectiveness (a quantitative characterization of the

quality of the results produced according to this model),

and a substantiation of the model (a discussion of whether

the results are reasonable from various perspectives).

Feedback includes questions related to improving the

product relative to the quality perspective of interest (a

quantitative characterization of the product quality, major

problems regarding the quality perspective of interest, and

suggestions for improvement during the ongoing project

as well as during future projects).

• Guidelines for Process-Related Questions

For each process under study, there are three major

subgoals that need to be addressed: 1) definition of the

process, 2) definition of the quality perspectives of interest, and 3) feedback from using this process relative to

the quality perspective of interest.

Definition of the process includes questions related to

the quality of use (a quantitat.ive characterization of the

process and an assessment of how well it is performed),

and the domain of use (a quantitative characterization of

the object to which the process is applied and an analysis

of the process performer's knowledge concering this object).

Quality perspectives of interest follows a pattern similar to the corresponding product-oriented subgoal including, for each quality perspective of interest (e.g., reduction of defects, cost effectiveness), questions related to

the major model(s) used, and validity of the model for the

particular environment, the validity of the data collected,

the model effectiveness and the substantiation of the

model).

Feedback follows a pattern similar to the corresponding product-oriented subgoal.

• Guidelines for Metrics, Data Collection, and

Interpretation:

-The choice of metrics is determined by the quantifiable

questions. The guidelines for questions acknowledge the

need for generally more than one metric (principle M6),

for objective and subjective metrics (principle M5), and

for associating interpretations with metrics (principle

MI3). The actual GQM models generated from these ternplates and guidelines will differ from project to project

and organization to organization (principle M6). This reflects their being tailored for the different needs in different projects and organizations (principle M4). Depending

on the type of each metric, we choose the appropriate mechansims for data collection and validation (principle

M11). As goals, questions and metrics provide for tractability of the (top-down) definitional quantification process, they also provide for the interpretation context (bottom-up). This integration of definition with interpretation

allows for the interpretation process to be tailored to the

specific needs of an environment (principle M8).

3) Improvement-Oriented Process Model: The

TAME software engineering process model is an instantiation of the improvement paradigm. The GQM paradigm provides the necessary integration of the individual

components of this model. The TAME software engineering process model explicitly includes components for

(C 1) the characterization of the current status of a project

environment, (C2) the planning for improvement integrated into the execution of projects, (C3) the execution

of the construction and analysis of projects according to

the project plans, and (C4) the recording of experience

into an experience base. The learning and feedback mechanism (C5) is distributed throughout the model within and

across the components as information flows frOm one

component to another. Each of these tasks must be dealt

with from a constructive and analytic perspective. Fig. 1

contains a graphical representation of the improvementoriented TAME process model. The relationships (arcs)

among process model components in Fig. i represent information flow.

(C1) Characterization of the current environment is required to understand the various factors that influence the

current project environment. This task is important in order to define a starting point for improverrient. Without

knowing where we are, we will not be able to judge

whether we are improving in our present project. We distinguish between the constructive and analytic aspects of

the characterization task to emphasize that we not only

state the environmental factors but analyze them to the degree possible based upon data and other forms of information from prior projects. This characterization task

needs to be formalized.

(C2) Planning is required to understand the project

goals, execution needs, and project focus for learning and

feedback. This task is essential for disciplined software

project execution (i.e., executing projects according to

precise specifications of processes and products). It provides the basis for improvement relative to the current status determined during cha._.,acterization. In the planning

task, we distingtlish betwee'h the constructive and analytic

as well as the "what" and '!how" aspects of planning.

Based upon the GQM paradigm all these aspects are highly

interdependent and performed as a single task. The development of quantitatively analyzable goals is an iterative process. However, we formulate the four planning as5207

3-25
ORIGINAL PAGE IS

OF POOR QUALITY

BASIL! AND ROMBACH: THE TAME PROJECT 763

¢oDrttuetire

lytl,=

I cl_r_c_rIae I

eavtro_elt

C2=

lumin

(;2.1: _hEt C2,2: Bow

+, c;=.=.t

m eoaaltructlon F

Le.61¥_

: cs.=._

CS_

l=lcutl, I

Q$.I

eoctetr tier

CII.=

l+: ....... 1

Fig. i. The imprnvcment-orienled TAME _,)l'tware process rn+_ieL

pects as four separate components to emphasize the

differences between creating plans for development and

making those plans analyzable, as well as between stating

what it is you want to accomplish and stating how you

plan to tailor the processes and metrics to do it.

(C2. I) "'What" Planning deals with choosing, assigning priorities, and operationally defining, to the degree possible, the project goals from the constructive and

analytic perspectives, The actual goal setting is an instantiation of the front-end of the GQM paradigm (th_ templates/guidelines for goal definition), The constructive

perspective addresses the definition of project goals such

as on-time delivery, the appropriate functionality to satisfy the user, and the analysis of the execution processes

we are applying. Some of these goals might be stated as

improvement goals over the current state-of-the-practice

as characterized in component C I. These goals should be

prioritized and operationally defined to the extent possible

without having chosen the particular construction models,

methods and tools, yet. The analytic perspective addresses

analysis procedures for monitoring and controlling

whether the goals are met. This analytic goal pers_ctlve

should prescribe the necessary learning and feedback

paths. It should be operationally defined to the extent allowed by the degree of precision of the constructive goal

perspective.

(C2.2) "How" Planning is based upon the results

from the "what" planning !providing ["or the purpose and

perspective of a goal definition according to the GQM

paradigm front-end) and the characterization of the environment (providing for the environment part. of a goal definition according to the GQM paradigm front-end). The

"how" planning involves the choice of an appropriately

tailored execution model, methods and tools that permit

the building of the system in such a way that we can analyze whether we are achieving our stated goals. The particular choice of construction processes, methods and tools

(component C2.2.1) goes hand in hand with fine-tuning

the analysis procedures derived durln-g the analytic perspective of the "what" planning (component C2.2.2).

(C2,2. I) Planning for construction includes choosing the appropriate execution model, methods and tools

to fulfill the project goals.-It should be clear that effective

planning for construction depends on well-defined project

goals from both the constructive and analytic perspective

(component C2.17.

(C2222):Planning for analysis addresses the finetuning of the operational definition of the analytic goal

perspective (derived as part of component C2.1) towards

the specific choices made during planning for construction (C2.2.1). The actual planning for analysis is an instantiation of the back-end of the GQM paradigm; details

need to be filled in (e.g., quantifiable questions, metrics)

based upon the specific methods and tools chosen.

(C3) Executirn must integrate the construction (component C3, t) with the analysis (component C3,2), Analysis (including measurement) cannot be an add-on but

must be part of the execution process and drive the construction. The+_-x-ec-rtir_pla_+=derived during the planning task are supposed to provide for the required integration of construction and analysis.

(C4) The E'_,pr?ience Base includes the entire body of

experience that_actb,'ely+available to the project. We can

tl characterize this experience accordin_ to the following dimensions: a) the degree of precision!detail, and b) the degree to which it is tailored to meet the specific needs of

the project (context). The precision/detail dimension involves the level of detail of the experimental design and

the level and quality of data collected. On one end of the

spectrum we have detailed objective quantitativedatathat

allows us to build mathematically tractable models. On

the other end of the spectrum we have interviews and

qualitative information that provide guidelines and "lessons learned documents", and permit the better formumm

m

W

IB

tit

W

li

w

J

U

m

t==l

N

J

r

=_

5207

3-26

m
w

F

764 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 14, NO. 6. JUNE 1988

lation of goals and questions. The level of precision and

detail affects our level of confidence in the results of the

expenment as well as the cost of the data collection process. Clearly priorities play an important role here. The

context dimension involves whether the focus is to learn

about the specific project, projects within a specific application domain or general truths about the software process or product (requires the incorporation of formalized

experience from prior projects into the experience base).

Movement across the context dimension assumes an ability to generalize experience to a broader context than the

one studied, or to tailor experience to a specific project.

The better this experience is packaged, the better our understanding of the environment. Maintaining a body of

experience acquired during a number of projects is one of

the prerequisites for learning and feedback across environments.

(C5) Learning and Feedback are integrated into the

TAME process model in various ways. They are based

upon the experimental model for learning consisting of a

set of steps, starting with focused objectives, which are

turned into specific hypotheses, followed by running experiments to validate the hypotheses in the appropriate environment. The model is iterative; as we learn from experimentation, we are better able to state our focused

objectives and we change and refine our hypotheses.

This model of learning is incorporated into the GQM

paradigm where the focused objectives are expressed as

goals, the hypotheses are expressed as questions written

to the degree of formalism required, and the experimental

environment is the project, a set of projects in the same

domain, or a corporation representing a general environment. Clearly the GQM paradigm is also iterative.

The feedback process helps generate the goals to influence one or more of the components in the process model,

e.g., the characterization of the environment, or the analysis of the construction processes or products. The level

of confidence we have in feeding back the experience to

a project or a corporate environment depends upon the

precision/detail level of the experience base (component

C4) and the generality of the experimental environment

in which it was gathered.

The learning and feedback process appears in the model

as the integration of all the components and their interactions as they are driven by the improvement and GQM

paradigms. The feedback process can be channeled to the

various components of the current project and to the corporate experience base for use in future projects.

Most traditional software engineering process models

address only a subset of the individual components of this

" model; in many cases they cover just the constructive aspects of characterization (component CI), "how" planning (component C2.2.1), and execution (component

C3.1). More recently developed software engineering

process models address the constructive aspect of execution (component C3.1) in more sophisticated ways (e.g.,

new process models [24],[30], [49], comhine various process dimensions such as technical, managerial, contractual [36], or provide more flexibility as far as the use of

methods and tools is concerned, for example via the automated generation of tools [45], [63]), or they add methods and tools for choosing the analytical processes, methods, and tools (component C3.2.2) as well as actually

performing analysis (component C3.2) [52], [59]. However, all these process models have in common the lack

of completely integrating all their individual components

in a systematic way that would permit sound learning and

feedback for the purpose of project control and improvement of corporate experience.

III. AUTOMATED SUPPORT THROUGH ISEEs: THE

TAME SYSTEM

The goal of an Integrated Software Engineering Environment (ISEE) is to effectively support the improvementoriented software engineering process model described in

Section II-B-3: An ISEE must support all the model components (characterization, planning, execution, and the experience base), all the local interactions between model

components, the integration, and formalization of the

GQM paradigm, and the necessary transitions between the

context and precision/detail dimension boundaries in the

experience base. Supporting the transitions along the experience base dimensions is needed in order to allow for

sound learning and feedback as outlined in Section II-B-3

(component C5).

The TAME system will automate as many of the components, interactions between components and supporting

mechanisms of the TAME process model as possible. The

TAME system development activities will concentrate on

all but the construction component (component C3.1) with

the eventual goal of interfacing with constructive SEEs.

In this section we present the requirements and the initial

architecture for the TAME system.

A. Requirements

The requirements for the TAME system can be derived

from Section II-B-3 in a natural way. These requirements

can be divided into external requirements (defined by and

of obvious interest to the TAME system user) and internal

requirements (defined by the TAME design team and required to support the external requirements properly).

The first five (external) requirements include support

for the characterization and planning components of the

TAME model by automating an instantiation of the GQM

paradigm, for the analysis component by automating data

collection, data validation and analysis, and the learning

and feedback component by automating interpretation and

organizational learning. We will list for each external

TAME system require.Blent the TAME process model

components of Section-l'l-B-3 from which it has been derived.

External TAME requirements."

(RI) A mechanism for defining the constructive and

analytic aspects of project goals in an operational and

quantifiable way (derived from components C l, C2.1,

C2.2.2, C3.2).

We use the GQM paradigm and its templates for defin5207

3-27
BASIL| AND ROMBACH_ THE T,%ME PROJECT

ing goals operationally and refining them into quantifiable

questions and metrics. The selection of the appropriate

GQM model and its tailoring needs to be supported, The

user will either select an existing model or generate a new

one. A new model can be generated from scratch or by

reusing pieces of existing models. The degree to which

the selection, generation, a,_ reuse tasks can be supported automatically depends largely on the degree to

which the GQM paradigm and its templates can be formalized. The user needs to be supported in defining his/

her specific goals according to the goal definition template. Based on each goal defi.nition, the TAME system

will search for. a model in the experience base. If no appropriate model exists, the user will be guided in developing one. Based on the tractability of goals into subgoals

and questions the TAME system will identify reusable

pieces of existing models and compose as much of an initial model as possible. This initial model will be completed with user interaction. For example, if a user wants

to develop a model for assessing a system test method

used in a particular environment, the system might compose an initial model by reusing pieces from a model assessing a different test method in the same environment,

and from a model for assessing the same system test

method in a different environment. A complete GQM

model includes rules for interpretation of metrics" and

guidelines for collecting the prescribed data. The TAME

system will automatically generate as much of this information as possible.

(R2) The automatic and manual collection of data and

the validation of manually collected data (derived from

component C3.2).

The collection of all product-related data (e.g., lines of

code, complexity) and certain process-related data (e.g.,

number of compiler runs, number of test runs) will be

completely automated. Automation requires an i,tefface

with construction-oriented SEEs. The collection of many

process-related data (e.g., effort, changes-) and subjective

data (e.g., experience of personnel, characteristics of

methods used) .cannot be automated. The schedule according to which measurement tools are run needs to be

defined as part of the planning activity. It is possible to

collect data whenever they are needed, periodically (e.g.,

always at a particular time of the day), or whenever

changes of products occur (e.g., whenever a new product

version is entered into the experience base all the related

metrics are recomputed). All manually collected data need

to be validated. Validating whether data are within their

defined range, whether all-the prescribed data are collected, and whether certain integrity rules among data are

maintained will be automated. Some of the measurement

tools will be developed as part of the TAME system development project, others will be imported. The need for

importing measurement tools will require an effective intereonnection mechanism (probably an interconnection

language) for integrating tools developed in different languages.

(R3) A mechanism for controlling measurement and

analysis (derived from component C3.2).

765

A GQM model is used to specify and control the execution of a particular analysis and feedback sesSiOn. According to each GQM model, the TAME system must

trigger the execution of measurement tools for data collection, the computation of all metrics and distributions

prescribed, and the application of statistical procedures.

If certain metrics or distributions cannot be computed due

to the lack of data or measurement tools, the TAME system must inform the user.

(R4) A mechanism for interpreting analysis results in a

context and providing feedback for the improvement of

the execution model, methods and tools (derived from

components C3.2, C.5).

We use a GQM model to define the rules and context

for interpretation of data and for feedback in order to refine and improve execution models, methods and tools.

The degree to which interpretation can be supported depends on our understanding of the software process and

product, and the degree to Which we express this understanding as formal rules. Today, interpretation rules exist

only for some of the aspects of interest and are only valid

within a particular project environment or organization.

However. interpretation guided by GQM models will enable an evolutionary learning process resulting in better

rules for interpretation in the future. The interpretation

process can be much more effective provided historical

experience is available allowing for the generation of historical baselines. In this case we can at least identify

whether observations made during the current project deviate from past experience or not.

(RS) A mechanism for learning in an organization (derived from components C4, C5).

The learning process is supported by iterating the sequence of defining focused goals, refining teem into hypotheses, and running experiments. These experiments

can range from completely controlled experiments to regular project executions. In each case we apply measurement and analysis procedures to project claSses of interest. For each of those classes, a historical experience base

needs to be established concerning the effectiveness of the

candidate execution models, methods and tools. Feedback from ongoing projects of the same class, the corresponding execution models, methods and tools can be refined and improved with respect to context and precision/

detail sd that we increase our potential to improve future

projects, _ ' :

The remaining seven (internal) requirements deal with

user interface management, report generation, experience

base, security and access control, configuration management control, SEE interface and distribution issues. All

these issues are important in order to support planning,

construction, learning and feedback effectively.

Internal TAME require_: :

(R6) A homogeneous user interface.

We distinguish between the physical and logical user

interface. The physical user interface provides a menu or

command driven interface between the user and the

TAME system. Graphics and window meehansims will be

e--

E--

u

J

J

ml

ll

m

i

w

n

B

l

,lllm  ̧

Ill

W

I

5207

3-28

I
=

F

766 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL 14, NO 6. JUNE 19fl8

incorporated whenever useful and possible. The logical

user interface reflects the user's view of measurement and

analysis. Users will not be allowed to directly access data

or run measurement tools. The only way of working with

the TAME system is via a GQM model. TAME will enforce this top-down approach to measurement via its logical user interface. The acceptance of this kind of user

interface will depend on the effectiveness and ease with

which it can be used. Homogeneity is important for both

the physical and logical user interface.

(R7) An effective mechanism for presenting data, information, and knowledge, "

The presentation of analysis (measurement and interpretalion) results via terminal or printer/plotter needs to

be supported. Reports need to be generated for different

purposes. Project managers will be interested in periodical reports reflecting the current status of their project.

High level managers will be interested in reports indicating quality and productivity trends of the organization.

The specific interest of each person needs to be defined

by one or more GQM models upon which automatic report generation can be based. A laser printer and multicolor plotter would allow the appropriate documentation

of tables, histograms, and other kinds of textual and

graphical representations.

project organization. It is part of planning a project to

decide who needs to have access to what functions and

pieces of data, information, and knowledge. In addition

to these security functions, more sophisticated data access

control functions need to be performed. The data access

system is expected to "recommend" to a user who is developing a GQM model the kinds of data that might be

helpful in answering a particular question and support the

process of choosing among similar data based on availability or other criteria.

(RI0) Mechanisms allowing for the implementation of

a variety of configuration management and control strategies.

In the context of the TAME system we need to manage

and control three-dimensional configurations. There is

first the traditional product dimension making sure that

the various product and document versions are consistent.

In addition, each product version needs to be consistent

with its related measurement data and the GQM model

that guided those measurements. TAME must ensure that

a user always knows whether data in the experience base

is consistent with the current product version and was collected and interpretated according to a particular model.

The actual configuration management and control strategies will result from the project planning activity.

(R8) The effective storage and retrieval of all relevani (R11) An interface to a construction-oriented SEE.

data, information, and knowledge in an experience base.

All data, information, and knowledge required to support tailorability and tractability need to be stored in an

experience base. Such an experience base needs to store

GQM models, engineering products and measurement

data. It needs to store data derived from the current project as well as historical data from prior projects. The effectiveness of such an experience base will be improved

for the purpose of learning and feedback if, in addition to

measurement data, interpretations from various analysis

sessions are stored. In the future, the interpretation rules

themselves will become integral part of such an experience base. The experience base should be implemented as

an abstract data type, accessible through a set of functions

and hiding the actual implementation. This latter requirement is especially important due to the fact that current

database technology is not suited to properly support software engineering concepts [26]. The implementation of

the experience base as an abstract data type allows us to

use currently available database technology and substitute

more appropriate technology later as it becomes available. The ideal database would be self-adapting to the

changing needs of a project environment or an organization. This would require a specification language for software processes and products, and the ability to generate

database schemata fromspecifications written in such a

language [46].

(R9) Mechanisms allowing for the implementation of

a variety of access control and security strategies.

TAME must control the access of users to the TAME

system itself, to various system functions and to the experience base. These are typical functions of a security

system. The enforced security strategies depend on the

An interface between the TAME system (which automates all process model components except for the construction component C3.1 of the TAME process model)

and some external SEE (which automates the construction

component) is necessary for three reasons: a) to enable

the TAME system to collect data (e.g., the number of

activations of a compiler, the number of test runs) directly

from the actual construction process, b) to enable the

TAME system to feed analysis results back into the ongoing construction process, and c) to enable the construction-oriented SEE to store/retrieve products into/from the

experience base of the TAME system. Models for appropriate interaction between constructive and analytic processes need to be specified. Interfacing with constructionoriented SEE's poses the problem of efficiently interconnecting systems implemented in different languages and

running on different machines (probably with different operating systems).

(RI2) A structure suitable for distribution.

TAME will ultimately run on a distributed system consisting of at least one mainframe computer and a number

of workstations. The mainframes are required to host the

experience base which can be assumed to be very large.

The rest of TAME might be replicated on a number of

workstations. --'1"

B. Architecture

Fig. 2 describes our current view of the TAME architecture in terms of individual architectural components and

their control flow interrelationships. The first prototype

described in Section IV concentrates on the shaded components of Fig. 2.

We group the TAME components into five logical lev5207

3-29
ORIGINAL

OF POOR

PAGE IS

QUALITY

BASIL[ AND ROMBACH; THE TAME PROJECT 767

PHYSICAl,

USER

I AI' U-- later-- M saalem'mt I INTERFACE

LEVEL

Itll , I ;

...... ,t---'- .......... :-}:........:...+-......

'.

i_.;." -_ ..............._".........

....... ....;:.....

II I I *.,o....

[ i I I °'*"='**II _._,,v_ I

T Y T ' -

gxpe_l_ B_e

LOGICAL

(COM-ORm_"_O)

USER

INTERFACE

LEVEL

ANAL YSIS

N FEEDBACK

LEVEL

MEASUREMENT "

LEVEL

SUPPORT

LEVEL

Fig, 2. _¢-archiiectural design of the TAME system.

els, the physical user interface, logical user interface,

analysis and feedback, measurement and support level.

Each of these five levels consists of one or more architectural components:

* The Physical User Interface Level consists of one

component:

(A l) The User Interface Management component

implements the physical user interface requirement R6. It

provides a choice of menu or command driven access and

supports a window-oriented screen layout.

• The Logical (GQM-Oriented) User Interface Level

consists of two components:

(A2) The GQM Model Selection component implements the homogeneity requirement of the logical user interface (R6). It guarantees that no access to the analysis

and feedback, measurement, or support level is possible

without stating the purpose for access in terms of a specific GQM model.

(A3) The GQM Model Generation component impiements requirement R I regarding the operational and

quantifiable definition of GQM models either from scratch

or by modifying existing models.

• The Analysis and Feedback Level consists of two

components:

(A4.1) This first portion of the Construction Interface component implements the feedback interface between the TAME system and c0nstruction-oriented SEEs

(pan b) of requirement RI 1).

(A5) The GQM Analysis and Feedback component

implements requirement R3 regarding execution and control of an analysis and feedback session, interpretation of

the analysis results, and proper feedback. All these activities are done in the context of a GQM model created by

A3. The GQM-Analysis and-i%edback C0m_fient needs

to have access to the specific authorizations of the user in

order to know which analysis functions this user can perform. The GQM Analysis and Feedback component also

provides analysis functions, for example, telling the user

whether certain metrics can be computed based upon the

data currently available in the experience base. This analysis feature of the subsystem is used for setting and operationally defining g0aIs_ questions, and metrics, as well

as actually performing analyses according to those previously established goals, questions, and metrics.

* The Measurement Level consists of three compo=

nents: : : _ =_--_::_

(A4.2) This second portion of the Construction Interface component implements the measurement interface

between the TAME system find SEE's (part a) of requirement Rl 1) and the SEE'S access tothe expenence base of

the TAME system (part c) of requirement RI 1).

(A6) The Measurement Scheduling component implements requirement R2 regard i_ngthe defin!t!on (and execution) Of automated data collection strategies. Such

strategies for when to collect data via the measurement

tools may range from collecting data whenever they al'e

needed for an analysis and feedback session (on-line) to

collecting them periodically during low-load times and

storing them in the experience base (off-line).

(A7) The Measurement Tools component implements requirement R2 regarding automated data collection. The component needs to be open-ended in order to

W

ID

U

g

lw

m

II

Wl

m

m

J

!

5207

3-30

1
m

768 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL 14. NO 6. JUNE 1988

allow the inclusion ot new and different measurement tools

as needed.

• The Support Level consists of three components:

(A8) The Report Generation component implements

requirement R7 regarding the production of all kinds of

reports.

(A9) The Data Entry and Validation component implements requirement R2 regarding the entering of manually collected data and their validation. Validated data

are stored in the experience base component.

(AI0) The Experience Base component implements

requirement R8 regarding the effective storage and retrieval of all relevant data, information and knowledge.

This includes all kinds of products, analytical data (e.g.,

measurement data, interpretations/, and analysis plans

(GQM models). This component provides the infrastructure for the operation of all other components of the

TAME process model and the necessary interactions

among them. The experience base will also provide mechanisms supporting the learning and feedback tasks. These

mechanisms include the proper packaging of experience

along the context and precision/detail dimensions.

In addition, there exist two orthogonal components

which for simplicity reasons are not reflected in Fig. 2:

(All) The Data Access Control and Security component(s) implement requirement R9. There may exist a

number of subcomponents distributed across the logical

architectural levels. They will validate user access to the

TAME system itself and to various functions at the user

interface level. They will also control access to the project experience through both the measurement tools and

the experience base.

(AI2) The Configuration Management and Control

component implements requirement RI0. This component can be viewed as part of the interface to the experience base level. Data can only be entered into or retrieved

from the experience base under configuration management control.

IV. FIRST TAME PROTOTYE

The first in a series of prototypes is currently being developed for supporting measurement in Ada projects [I 5].

This first prototype will implement only a subset of the

requirements stated in Section III-A because of a) yet unsolved problems that require research, b) solutions that

require more formalization, and c) problems with integrating the individual architectural components into a

consistent whole. Examples of unsolved problems requiring futher research are the appropriate packaging of the

experience along the context and precision/detail dimension and expert system support for interpretation purposes. Examples of solutions requiring more formalization are the GQM templates and the designing of a

software engineering experience base. Examples of integration problems are the embedding of feedback loops into

the construction process, and the appropriate utilization

of data access control and configuration management control mechanisms. At this time, the prototype exists in

pieces that have not been fully integrated together as well

as partially implemented pieces.

In this section, we discuss for each of the architectural

components of this TAME prototype as many of the following issues as are applicable: a) the particular approach

chosen for the first prototype, b) experience with this approach, c) the current and planned status of implementation (automation) of the initial approach in the first TAME

system prototype, and d) experiences with using the component:

(AI) The User Interface Management component is

supposed to provide the physical user interface for accessing all TAME system functions, with the flexibility

of choosing between menu and command driven modes

and different window layouts. These issues are reasonably

well understood by the SEE community. The first TAME

prototype implementation will be menu-oriented and

based upon the 'X' window mechan.ism. A primitive version is currently running. This component is currently not

very high on our priority list. We expect to import a more

sophisticated user interface management component at

some later time or leave it completely to parties interested

in productizing our prototype system.

(A2) The GQM Model Selection component is supposed to force the TAME user to parameterize each

TAME session by first stating the objective of the session

in the form of an already existing GQM model or requesting the creation of a new GQM model. The need for this

restriction has been derived from the experience that data

is frequently misused if it is accessible without a clear

goal. The first prototype implementation does not enforce

this requirement strictly. The current character of the first

prototype as a research vehicle demands more flexibility.

There is no question that this component needs to be implemented before the prototype leaves the research environment.

(A3) The GQM Model Generation component is supposed to allow the creation of specific GQM models either

from scratch or by modifying existing ones.. We have provided a set of templates and guidelines (Section II-B-2).

We have been quite successful in the use of the templates

and guidelines for defining goals, questions and metrics.

There are a large number of organizations and environments in which the model has been applied to specify what

data must be collected to evaluate various aspects of the

process and product, e.g., NASA/GSFC, Burroughs,

AT&T, IBM, Motorola. The application of the GQM paradigm at Hewlett Packard has shown that the templates

can be used successfully without our guidance. Several of

these experiences have I_en written up in the literature

[4], [16]. 117], [39], [48]. [56], [60], [61]. We have been

less successful in automating the process so that it ties

into the experience base. As long as we know the goals

and questions a priori, the appropriate data can be isolated and collected based upon the GQM paradigm. The

first TAME prototype implementation is limited to sup5207

3-31
BASILI AND ROMBACH; THE TAME PROJECT

port the generation of new models and the modificaton of

existing models using an editor enforcing the templates

and guidelines. We need to further formalize the templates and guidelines and provide traceability between

goals and questions. Formalization of the templates and

providing traceability is our most important research issue. In the long run we might consider using artificial intelligence planning techniques.

(A4.1 and A4.2) The Construction Interface component is supposed to support all interactions between a SEE

(which supports the construction component of the TAME

process model) and the TAME system. The model in Fig.

1 implies that interactions in both directions are required.

We have gained experience in manually measuring the

construction process by monitoring the execution of a variety of techniques (e.g., code reading [57], testing [20],

and CLEANROOM development [61]) in various ,environments including the SEL [4], [48]. We have also

learned how analysis results can be fed back into the ongoing construction process as weli as into corporate experience [4], [48]. Architectural component A4.1 is not

part of this first TAME prototype. The first prototype implementation of A4.2 is limited to allowing for the integration of (or access to) external product libraries. This

minimal interface is needed to have access to the objects

for measurement. No interface for the on-line measurement of ongoing construction processes is provided yet.

(A5) The GQM Analysis and Feedback component is

supposed to perform analysis according to a specific GQM

model. We have gained a lot of experience in evaluating

various kinds of experiments and case studies. We have

been successful in collecting the appropriate data by tracing GQM models top-down. We have be_en less__successful

in providing formal interpretation rules allowing for the

bottom-up interpretation of the collected data. One automated approach to providing interpretation and feedback

is through expert systems. ARROWSMITH-P provides

interpretations of software project data to managers [44];

it has been tested in the SEL/NASA environment. The

first prototype TAME implementation triggers the collection of prescribed data (top-down) and presents itto .the

user for interpretation. The user-provided interpretations

will be recorded (via a knowledge acquisition system) in

order to accumulate the necessary knowledge that might

lead us to identifying interpretation rules in the future.

(A6) The Measurement Scheduling component is supposed to allow the TAME user to define a strategy for

actually collecting data by running the measurement tools.

Choosing the most appropriate of many possible strategies (requirements Section Ill-A) might depend on the response times expected from the TAME system or the storage capacity of the experience base. Our experience with

this issue is limited because most of our analyses Were

human scheduled as needed [4], [48]. This component will

not be implemented as part of the first prototype. In this

prototype, the TAME user will trigger the execution of

measurement activities explicitly (which can, of course,

769

be viewed as a minimal implementation supporting a human scheduling strategy).

(A7) The Measurement Tools component is supposed

to allow the collection of all kinds of relevant process and

product data. We have been successful in generating tools

to gather data automatically and have learned from the

application of these tools in different environments.

Within NASA, for example, we have used a coverage tool

to analyze the impact of test plans on the consistency of

acceptance test coverage with operational use coverage

[53]. We have used a data bindings tool to analyze the

structural consistency of implemented systems to their design [41], and studied the relationship between faults and

hierarchical structure as measured by the data bindings

tool [60]. We have been able to characterize classes of

products based upon their syntactic structure [35]. We

have not, however, had much experience in automatically

collecting process data. The first prototype TAME imple+

mentation consists of measurement tools based on the

above three. The first tool captures all kinds of basic Ada

source code information such as lines of code and structural complexity metrics [35], the second tool computes

Ada data binding metrics, and the third tools captures dynamic information such as test coverage metrics [65]. One

lesson learned has been that the development of measurement tools for Ada is very often much more than just a

reimplementation of similar tools for other languages.

This is due to the very different Ada language concepts.

Furthermore, we have recognized the importance of having an intermediate representation level allowing for a

language independent representation of software product

and process aspects. The advantage of such an approach

will be that this intermediate representation needs to be

generated ofiiy ogce-per product or process. All the measurement tools can run on this intermediate representation. This will not only make the actual measurement process less time-consuming but provide a basis for reusing

the actual measurement tools to some extent across different language environments. Only the tool generating

the intermediate representation needs to be rebuilt for each

new implementation language or TAME host enviroment.

(AS) The Report Generator Component is supposed to

allow the TAME user to produce a variety of reports. The

statistics and business communities have commonly accepted approaches for presenting data and interpretations

effectively (e.g., histograms). The first TAME prototype

implementation does not provide a separate experience

base reporting facility. Responsibility for reporting is attached to each individual prototype component; e.g., the

GQM Model Generation component provides reports regarding the models, each measurement tool reports on its

own measurement data. +

(A9) The Data Entry and Validation component is supposed to allow the TAME user to enter all kinds of manually collected data and validate them. Because of the

changing needs for measurement, this component must allow for the definition of new (or modification of existing)

Ill

J

U

m

W

D

i

m

w

i

E--

W

W

i

5207

3-32

g

J
F

77O IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL 14, NO 6, JUNE 1988

data collection forms as well as related validation (integrity) rules. If possible, the experience base should be capable of adapting to new needs based upon new form definitions. We have had lots of experience in designing

forms and validations rules, using them, and learning

about the complicated issues of deriving validation rules

[4], [48]. The first prototype implementation will allow

the TAME user to input off-line collected measurement

data and validate them based upon a fixed and predefined

set of data collection forms [currently in use in NASA's

Software Engineering Laboratory (SEL)]. This component is designed but not yet completely implemented. The

practical use of the TAME prototype requires that this

component provide the flexibility for defining and ac--

cepting new form layouts. One research issue is identifying the easiest way to define data collection forms in

terms of a grammar that could be used to generate the

corresponding screen layout and experience base structure.

(AI0) The Experience Base component allows for effective storage and retrieval of all relevant experience

ranging from products and process plans (e.g., analysis

plans in the form of GQM models) to measurement data

and interpretations. The experience base needs to mirror

the project environment. Here we are relying on the experience of several faculty members of the database group

at the University of Maryland. It has been recognized that

current database technology is not sufficient, for several

reasons, to truly mirror the needs of software engineering

projects [26]. The first prototype TAME implementation

is built on top of a relational database management system. A first database schema [46] modeling products as

well as measurement data has been implemented. We are

currently adding GQM models to the schema. The experiences with this first prototype show that the amount of

experience stored and its degree of formalism (mostly

data) is not yet sufficient. We need to better package that

data in order to create pieces of information or knowledge. The GQM paradigm provides a specification of what

data needs to be packaged. However, without more formal interpretation rules, the details of packaging cannot

be formalized. In the long run, we might include expert

system technology. We have also recognized the need for

a number of buih-in GQM models that can either be reused

without modification or guide the TAME user during the

process of creating new GQM models.

(AI 1) The Data Access Control and Security component is supposed to guarantee that only authorized users

can access the TAME system and that each user can only

access a predefined window of the experience base. The

• first prototype implements this component only as far as

user access to the entire system is concerned.

(AI2) The Configuration Management and Control

component is supposed to guarantee consistency between

the objects of measurement (products and processes), the

plans for measurement (GQM models), the data collected

from the objects according to these plans, and the attached interpretations. This component will not be implemented in the first prototype.

The integration of all these architectural components is

incomplete. At this point in time we have integrated the

first versions of the experience base, three measurement

tools, a limited version of the GQM analysis and feedback

component, the GQM generation component, and the user

interface management component. Many of the UNIX ®

tools (e.g., editors, print facilities) have been integrated

into the first prototype TAME system to compensate for

yet missing components. This subset of the first prototype

is running on a network of SUN-3's under UNIX. It is

implemented in Aria and C.

This first prototype enables the user to generate GQM

models using a structured editor. Existing models can be

selected by using a unique model name. Support for selecting models based on goal definitions or for reusing

existing models for the purpose of generating new models

is offered, but the refinement of goals into questions and

metrics relies on human intervention. Analysis and feedback sessions can be run according to existing GQM

models. Only minimal support for interpretation is provided (e.g., histograms of data). Measurement data are

presented to the user according to the underlying model

for his/her interpretation. Results can be documented on

a line printer. The initial set of measurement tools allows

only the computation of a limited number of Ada-sourcecode-oriented static and dynamic metrics. Similar tools

might be used in the case of Fortran source code [33].

V. SUMMARY AND CONCLUSIONS

We have presented a set of software engineering and

measurement principles which we have learned during a

dozen years of analyzing software engineering processes

and products. These principles have led us to recognize

the need for software engineering process models that integrate sound planning and analysis into the construction

process.

In order to achieve this integration the software engineering process needs to be tailorable and tractable. We

need the ability to tailor the execution process, methods

and tools to specific project needs in a way that permits

maximum reuse of prior experience. We need to control

the process and product because of the flexibility required

in performing such a focused development. We also need

as much automated support as possible. Thus an integrated software engineering environment needs to support

all of these issues.

In the TAME project we have developed an improvement-oriented (Integrated) process model. It stresses a)

the characterization of the current status of a project environment, b) the planning for improvement integrated

into software projects, and c) the execution of the project

according to the prescribed project plans. Each of these

*UNIX is a regisleredtfiademarkof AT&TBell Laboratories.

5207

3-33
BASIL[ AND ROMBACH: THE TAME PROJECT

tasks must be dealt with from a constructive and analytic

perspective.

To integrate the constructive and analytic aspects of

software development, we have used the GQM paradigm.

It provides a mechanism for formalizing the characterization and planning tasks, controllling and improving projects based on quantitative analysis, learning in a deeper

and more systematic way about the software process and

product, and feeding back the appropriate experience to

current and future projects.

The effectiveness of the TAME process model depends

heavily on appropriate automated support by an ISEE. The

TAME system is an instantiation of the TAME process

model into an ISEE; it is aimed at supportTng all aspects

of characterization, planning, analysis, learning, and

feedback according to the TAME process model. In addition, it formalizes the feedback and learning mechanisms by supporting the synthesis of project experience,

the formalization of its representation, and its tailoring

towards specific project needs. It does this by supporting

goal development into measurement via templates and

guidelines, providing analysis of the development and

maintenance processes, and creating and using experience

bases (ranging from databases of historical data to knowledge bases that incorporate experience from prior projects).

We discussed a limited prototype of the TAME system,

which has been developed as the first of a series of prototypes that will be built using an iterative enhancement

model. The limitations of this prototype fall into two categories, limitations of the technology and the need to better formalize the model so that it can be automated.

The short range (1-3 years) goal for the TAME sy_stem

is to build the analysis environment. The mid-range goal

(3-5 years) is to integrate the system into one or more

existing or future development or maintenance environments. The long range goal (5-8 years) is to tailor those

environments for specific organizations and projects.

The TAME project is ambitious. It is assumed it will

evolve over time and that we will learn a great deal from

formalizing the various aspects of the TAME project as

well as integrating the various paradigms. Research is

needed in many areas before the idealized TAME system

can be built. Major areas of study include measurement,

databases, artificial intelligence, and systems. Sp¢_cific

activities needed to support TAME include: more forrealization of the GQM paradigm, the definition of better

models for various quality and productivity aspects,

mechanisms for better formalizing the reuse and tailoring

of project experience, the interpretation of metrics with

respect to goals, interconnection languages, language independent representation of software, access control in

general and security in particular, software engineering

database definition, configuration management and control, and distributed system architecture. We ate interested in the role of further researching the ideas and principles of the TAME project. We will buil d a series of

771

evolving prototypes of the system in order to learn and

test out ideas.

ACKNOWLEDGMENT

The authors thank all their students for many helpful

suggestions. We especially acknowledge the many contributions to the TAME project and, thereby indirectly to

this paper, by J. Bailey, C. Brophy, M. Daskalantonakis.

A. Dells, D. Doubleday, F. Y. Farhat, R. Jeffery, E. E.

Katz, A. Kouchakdjian, L. Mark, K. Reed. Y. Rong, T.

Sunazuka, P. D. Stotts, B. Swain, A. J. Turner. B. Ulery,

S. Wang, and L. Wu. We thank the guest editors and external reviewers for their constructive comments.

REFERENCES

Ill W. Agresti. "'SEL Ada experiment: Status aBd design experience,'"

in Proe. Eleventh Annu. Software Engmeerin_ Workshop, NASA

Goddard Space Flight Center, Greenbelt, MD, Dec, 1986:

I21 J Bailey and V R. Basili. "A meta-model for software development

resource expenditures." in Proc Fifth Int. Conf Software Engineering, San Diego. CA. Mar. 1981, pp, t07-116.

[31 V. R, Basili. "'Quantitative evaluation of software engineering methodology."in Proc. First Pan Pacific Computer Conf. Melbourne.

Austra_pt. _ also avat_ as Tech Rep, TR-1519, Dep.

Comput. Sci.. Univ, Maryland. College Park, July t985.

[4] V. R. Basili, "Can we measure software technology: Lessons learned

from 8 years of trying," in Proc. Tenth Annu. Softkare Engineering

Workshop. NASA Goddard Space Flight Center, Greenbelt, MD. Dec.

1985.

15] --, "'Evaluating software characteristicsi Assessement of software

measures in the Software Engineering Laboratory," in Proc. Sixth

Annu, Software Engineering Workshop, NASA Goddard Space Flight

Center, Greenbelt, MD, 1981.

[61 V. R. Basili and J. Beane, "'Can the Parr curve help with the manpower distribution and resource estimation problems," J. Syst. Software, vol. 2. no. 1, pp 59-69, 1981.

I71 V. R. Basili and K. Freburger. "Programming measurement and estimation in the Softy, are Engineering Laboratory," J. Syst. Software.

[81 V. R Basili and D. H, Hutchens. "An empirical study of a syntactic

measure family," IEEE Trans. Software Eng., vol. SE-9. no. I 1, pp.

664-672, Nov. 1983.

[91 V. R. Basili and E E. Katz. "'Measures of interest in an Ada development," in Proc. IEEE Comput. Soc, Workshop Software Engineering Technology Transfer. Miami. FL, Apr. 1983. pp, 22-29,

[10l V. R Basili. E. E. Katz, N. M. Panlilio-Yap, C, Loggia Ramsey,

and S. Chang, "Characterization of an Ada software development.'"

Computer, pp, 53-65. Sept. 1985.

[I 1] V, R, Basili and C. Loggia Ramsey, "'ARROWSMITH-P: A prototype expert system for software enginceringmanagemeni.'" in Proc,

IEEE Syrup. Expe_'t Systems in Government, Oct. 23-25, 1985. pp.

252-264.

[t2] V R, Basili and N, M. Panlilio-Yap, "'Finding relationships between

effort and other variables in the SEE" in Proc_ IEEE COMPSAC,

Oct. 1985. , : _ _=

[131 V R. Basili and B. Perricone, "Software ern'ors and complexity: An

empirical investigation." ACM, Commun., vol. 27, no. I. pp. 45-

52, Jan. 1984.

[14] V, R. Basili and R, Reiter, Jr.. "A controlled experiment quantitatively comparing software development approaches," IEEE Trans.

Software_Eng?_=voli_._7_no?3jpp.:_-320, May 1981.

[15] V. R. Basili and H. D. Rombach, "TAME: Tailoring an Aria measurement environment," in Proc. Joint ,4da Conf. Arlington. VA.

Mar. 16-19, 1987. pp. 318-325.

[16] --, "'Tailoring the software process to project goals and environments," in Proc. Ninth Int. Conf. Software Engineering, Monterey;

CA. Mar. 30-Apr. 2, 1987. pp. 345-357.

[17]--, "TAME: Integrating measurement into software environments." Dep. Comput, Sci.. Univ Maryland, College Park, Tech.

Rep, TR-1764 (TAME-TR-1-1987). June 1987.

i

rot'

q

m

III

u

M

w

g

J

Ul

i

J

u

U

5207

3-34

L_

mm

I
772 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, V/_L I4. NO. 6. JUNE 1988

[18] --. "Software reuse: A framework," in Proc. Tenth Minnowbrook

Workshop Software Reuse, Blue Mountain Lake, NY, Aug, t987.

[19] V. R. Basiti and R. W. Selby, Jr., "Data collection and analysis in

software research and management," in Proc. Amer, Statist. Ass. and

Biomeasure Soc, Joint Statistical Meetings. Philadelphia, PA, Aug.

13-16, 1984+

1201 --, "Comparing the effectiveness of software testing strategies,"

IEEE Trans. Software Eng., vol, SE-13, no. 12, pp. 1278-1296, Dec.

1987.

1211 --, "Calculation and use of an environment's characteristic software metric set." in Proc. Eighth Int. Conf. Software Engineering,

London. England. Aug 1985.

[22] V R. Basili, R. W Selby, and D. H, Hutchens, '+Experimentation

in software engineering," IEEE Trans. Software Eng.. vol. SE-12+

no, 7, pp. 733-743, July 1986.

[23] V. R. Basili, R. W. Selby, and T.-Y. Phillips, "'Metric analysis and

data validation across Fortran projects," IEEE Trans. Software Eng..

vol+ SE-9. no. 6, pp. 652-663, Nov. 1983,

[24] V, R, Basili and A. L Turner, "lterativc enhancement: A practical

technique lot software development." IEEE Trans. Software E.g.,

vol. SE-I, no. 4. pp, 390-396, Dec. 1975.

1251 V, R. Basili and D. M. Weiss, "A methodology for collecting valid

software engineering data," IEEE Trans. Software Eng., vol, SE-10,

no. 3. pp. 728-738. Nov. 1984,

[26] P. A. Bemstein, "Database system support for software engineering,'" in Proc. Ninth Im Conf. Software Engineering, Monterey, CA,

Mar. 30-Apr. 2. 1987, pp. 166-17g.

[27] D. Bjomer, "'On the use of formal methods in software development," in Proc. Ninth Int. Conf. Software Engineering, Monterey,

CA. Mar. 30-Apr. 2, 1987. pp. 17-29,

128] B. W. Bochm, "Software engineering," IEEE Trans, Comput., vol,

C-25, no. 12, pp 1226-1241, Dec. 1976.

[291--, Software Engineering Economics. Englewood Cliffs, NJ:

Prentice-Hall, 1981.

[301 --, "A spiral model of software development and enhancement,"

ACM Software Eng. Notes, vol. 1I. no. 4. pp. 22-42, Aug. 1986

1311 B. W. Boehm. J. R. Brown, and M, Lipow, "Quantitative evaluation

of software quality,'" in Proc. Second Int. Conf. Software Engineering. 1976, pp. 592-605.

132] C. Brophy, W. Agresti, and V, R. Basili, "Lessons learned in use of

Ada oriented design methods," in Proc. Joint Ada Conf.. Arlington,

VA. Mat, 16-19, 1987, pp. 231-236.

[33] W. I. Decker and W. A. Taylor, "Fortran static source code analyzer

program (SAP)." NASA Goddard Space Flight Center. Greenbelt,

MD, Tech. Rep. SEL-g2-002, Aug. 1982.

[34] C. W. Doe_inger and V. R. Basili, "Monitoring software development through dynamic variables," IEEE Trans. Software Eng., vol.

SE-II. no. 9, pp. 978-985, Sept. 1985.

1351 D. L. Doubleday, "ASAP: An Ada static source code analyzer program," Dep. Comput, Sci., Univ. Maryland, College Park, Tech.

Rep. TR-lg95, Aug. 1987.

[36] M. Dowson, "'ISTAR--An integrated project support environment,"

in ACM Sigplan Notices (Proc. Second ACM Software Eng. Syrup.

Practical Development Support Environments), vol. 2, no. 1. Jan.

1987.

[37] M. Dyer, "Cleanroom software development method," IBM Federal

Systems Division, Bethesda. MD, Oct. 14, 1982,

[38] I. Gannon, E E, Katz, and V. R. Basili. "Measures for Ada packages: An initial study." Commun. ACM. vol. 29, no 7. pp. 616-

623, July 1986.

1391 R. B. Grady, "Measuring and managing software maintenance,'"

IEEE Software, vol 4. no. 5. pp. 35-45. Sept, 1987.

140] M. H. Halsread. Elements of Software Science. New York: Elsevier

Noah- Holland, 1977.

[41] D. H. Hutchens and V. R. Basili, "'System structure analysis: Clustering with data bindings." IEEE Trans. Software Eng.. vol. SE-I 1,

pp. 749-757, Aug. 1985.

,[42] E. E. Katz and V. R. Basili, "Examining the modularity of Ada programs." in Proc. JointAda Coal, Arlington. VA. Mar 16-19, 1987,

pp, 390-396.

[43] E. E: Katz, H. D. Rombach, and V. R Basili, "Structure and maintainability of Ada programs: Can we measure the differences?" in

Proc. Ninth Minnowbrook Workshop Software Performance Evaluation, Blue Mountain Lake, NY, Aug. 5-8, 1986.

[44] C. Loggia Ramsey and V. R. Basili, "An evaluation of experl systems for software engineering management," Dep. Comput. Sci.,-

Univ, Maryland, College Park, Tech. Rep. TR-170g. Sept. 1986.

[45] M. Marcus, K. Sanley, S. C Schaffner, and E Albert "'DAPSE: A

distributed Ada programming suppun environment," in Proc. IEEE

Second Int. Conf Ada Applications and En vironmenm 1986. pp. I 15-

125.

I46] L. Mark and H. D. Rombach, "'A meta information base for software

engineering," Dep Comput, Sci,, Uni'.= Maryland. College Park.

Tech+ Rep. TR-1765. July 1987.

147] T. J. McCabe, "'A complexity measure. +. IEEE Trans. Software Eng.,

vol. SE-2, no. 4. pp. 308-320, Dec. 1976

I48] F. E McGarry, "Recent SEL studies," in Proc. Tenth Annu. Software Engineering Workshop. NASA Goddard Space Flight Center,

Greenbelt, MD, Dec. 1985+

[49] L. Oster_eil, "Sort's, are processes are software too,'" in Proc. Ninth

" Int. Conf Software Engineering Monterey, CA. Mar. 30-Apr. 2,

1987, pp. 2-13.

[50] F. N. Parr, "An alteroative to the Ra_leigh cur'.+e model for ,,oftware

development effort," IEEE Trans. Software Eng., vol. SE-6. no 5.

pp. 291-296, May 1980,

[51] L Putnam, "A general empirical solution to the macro soft-are sizing and estimating problem.'" 1EEE Tra._. Software Eng.. vo. SE4, no. 4. pp. 345-361, Apr. 1978.

[52] C. V. Ramamoorthy, Y, Usuda, W.-T. Tsai, and A. Prakash. "GENESIS: An integrated environment for supporting development and evolution of software," in Proc. COMPSAC. 1985.

[53] J. Ramsey and V. R. Basili, "Analyzing the test process using structural coverage." in Proc, Eighth bit, Co.f Software Enetneering

London. England. Aug. I985, pp. 306-311.

[54] H. D. Rombach, "Software design metrics for maintenance." in Pro_'.

Ninth Annu, Software Engineering Workshop. NASA Gnddard Space

Flight Center, Greenbelt, MD. No',' 1984.

155] --. "'A controlled experiment on the impact of soft.are structure

on maintainability," IEEE Trans. Soft_are Eng.. vol. SE-13. no, 3.

pp. 344-354, Mar. 1987.

I56] H. D. Rombach and V. R. Basili, "A quantitative assessment of software maintenance: An industrial case study," in Proc. Co.f S+_ft-

.,are Maintenance. Austin, TX. Sept. 1987. pp. 134-t44,

[57] H. D. Rombach. V. R. Basili, and R. W. Selby. Jr., "The role of

code reading in the software life cycle." in Proc. Ninth Minnowbrook

Workshop Software Performance Evaluation. Blue Mountain Lake,

NY, August 5-8. 1986.

[58] W. W. Royce. "Managing the development of large software systems: Concepts and techniques.'" in Proc. WESCON. Aug 1970.

[59] R. W Selby, Jr., "Incorporating metrics into a sofl_are environmere," in Proc. Joint Ada Conf., Arlington, VA. Mar 16-19. 1987.

pp. 326-333.

[60] R. W. Selby and V. R. Basiti, "Analyzing error-prone system coupling and cohesion." Dep. Comput. Sci.. Uni',. Mat':land. College

Park, Tech. Rep., in preparation.

[61] R. W. Selby, Jr.. V. R. Basili. and T. Baker. "'CLEANROOM software development: An empirical evaluation." IEEE Trans. Software

Eng., vol, SE-13. no. 9, pp. 1027-1037. Sept. 1987.

[62] C E Walston and C. P. Felix. "A method of programming measurement and estimalion,'" IBM Syst. J., voi. t6, no I. pp. 54-73,

1977.

[63] A. I. Wasserman and P. A Pitcher. "Visible connections." UNIX

Roy,. Oct. 1986.

[64] Webster's New Collegiate Dictionary. Springfield. MA: Merriam.

1981.

[65] L. Wu. V. R. Basili, and K. Reed, "A structure coverage _ool for

Ada software systems," in Pr.c. Joint Ad. Con£, Arlinglon, VA.

Mar. 16-19. 1987. pp. 294-303.

1661 M. Zelkowitz, R Yeh, R Hamlet, J. Gannon+ and V R Basiti,

"Software engineering practice_, in the U.S. and Japan." C<.nputer.

pp, 57+66. June 1984

Victor R. Basili IM'83-SM'841 i_, Professor and

Chairr_ of the Depanmem of Computer Science

at the University of Maryland, College Park. He

was involved in the design and development of

several soft.,are project:,, including the SIMPL

family of programming languages. He is currentb

measuring and evaluating soft,,are development

in industrial and government settings and has consulted with many agencies and organlzations.-in.

eluding IBM, GE. CSC. GTE, MCC. AT&T,

Motorola, HP. NRL. NSWC. and NASA, He is

5207

3-35

ORIGINAL PAGE IS

OF POOR QUALITY
BASILI AND ROMBACH; THE TAME PROJECT

one of the founders and principals in the Software Engineering Laborato_.

a joint venture between NASA Goddard Space Flight Center, the University of Maryland and Computer Sciences Corporation, established in 1976.

He has been working on the development of quantitative approaches for

software management, engineering, and quality assurance by developing

models and metrics for the software development process and product, He

has authored over 90 papers, In t982. he received the Outstanding Paper

Award from the IEEE TRANSACT_*'UI_,S ON SOFTWARE ENGINEEalNG for his

paper on Ihe evaluation of methodologies,

Dr Basili is currently the Editor-in-Chief of the IEEE TaANSACTtONS

ON SOFTWARE ENGINEERING and was Program Chairman for several conferences including the 6th International Conference on Software Engineering,

Hc has served on the Editorial Board of the Journal of Systems and Software. He is a member of the Board of Governors of the IEEE Computer

Society.

ORIGINAL PAGE IS

OF POOR QUALITY

773

-_'-_ .... _-_-+_-z H. Dieter Rombaeh received the B.S. degree

(Vordiplom} in mathematics and the M.S. degree

(Diplom) in mathematics and computer science

from the University of Karlsruhe, West Germany,

and the Ph.D. degree (Dr, rer. nat.) in computer

science from the University of Kaiserslautero,

West Germany.

He is an Assistant Professor of Computer Science at the University of Maryland, College Park.

He is also al_liated with the University of Maryiand Institute for Advanced Computer Studies

(UMIACS) and the Software Engineering Laboratory (SELL a joint venture between NASA Goddard Space Flight Center, the University of Maryland, and Cornputbr 5c]e_nces Corporati0nl His researFh_nterests include

software methodoi0gies, measurement of the software process and its products, software engineering environments, and distributed systems.

Dr. Rombach served as Guest Editor for the IEEE Software magazine

Special issue on Software Quality Assurance (September 1987). He is a

member of the IEEE Computer Society, the Association for Computing

Machinery, and the German Computer Society (GI).

m

m

m

U

m

U

U

w

gig.

U

I

j

gg

W

5207

3-36
VALIDATING THE TAMERESOURCEDATA MODEL*

D. Ross Jeffery (i) & Victor R. Basill (2)

(I) Un£verslCy o6 New South _ales, Auscralfa

(2) University of Maryland, College Park, lid 20742

Abstract

This paper presents a conceptual model of

software development resource data and validates

the model by reference to the published literature

on necessary resource data for development support environments. The conceptual model

presented here was developed using a top-down

strategy. A resource data model is a prerequisite

to the development of integrated project support

environments which Mm to assist in the processes

of resourre estimaCion,evaluation and control.

The model proposed isa four dimensionalview of

resourceswhich can be used for resourceestimation,utilization,and review. The mode] is vaildated by reference to three publicatibnson

resource databases,and the implicationsof the

model arisingout of these comparisons is discussed.

Keyworda : software process, methods, tools,

conceptual model, resources, estimation, environments, software engineering database, va{[dation

INTRODUCTION

To date, the approach taken to the accumulation

of knowledge concerning the software process has

been largely bottom-up. Studies have been carried

out to determine the existence and nature of project relationships. These studies,such as [Wolverton 74],[Nelson67], [Chrysler 78], [Sackman et.al.

_8], [Basili, Panlilio-Yap 85], [Bastli, Freburger

811, {Basifi, Sefb_', Phillips 83J, IWalston Felix

77]), [Jeffery 87a,87b], and [Jeffery, Lawrence

1979, 1985] have explored the relationships

between project variables, searching for an understanding of the software process and product. For

example, relationships between effort and size,

errors and methods, and test strategy and bug

identification, have been found.

*This research was funded in part by NASA Grant

NSG-5123 to University of Maryland

This paper has two major aims:

I) To brieflypresent a top-down characterization

(TDC) structureof software projectresourcedata,

which aims to facilitate:

I. Further accumulation of knowledge of project resourcecharacteristicsand metricswithin

a theoreticalstructure.

2. The storage of project resource data in a

generalizedstructuredway so that estimation,

evaluation,and controlcan be facilitatedusing

an organized quantitative and qualitative data

base.

2) To validate this structure against published

resource data models.

The characterization structure of resource data is

a prerequisite to the development of an Integrated

Project Support Environment (IPSE) in which it

is possible to:

1. Objectively choose appropriate software

processes.

2. Estimate the process characteristics such ss

time, cost, and quality

3. Evaluate the extent to which the resource

aims are being met during development, and

4. Improve the software process and product.

.

The structure presented and validated here is a

part of the TAME (Tailoring A Measurement

Environment) project which seeks to develop an

integrated software project measurement,

analysis, and evaluation environment. This

environment is based in part on the evolutionary

improvement paradigm Idiscussedin Ba.sili,Rombach 87].Itis alsobased on the Goal-QuestionMetric" paradigm outlined in [Basili85] and

[Basili, Weiss 84].

The aims of this paper are firstly to present the

TDC structure or model for the perception of

software development resourceswhich will assist

in the process of taking those aims of, say, a

development manager and translatingthem into a

set of questionsand metrics which can be used to

measure the software process.It is meant to be

independent of the particularprocessmodel used

0270-5257/88/0000/0187$01,00 © 1988 IEEE

187

Recommendedby: B. BoehmandJ. Musa

3-37

5207
for development and maintenance. A full description of the model, including its dynamic nature is

described in [Jeffery, Basili 87a and 87b]. The

paper secondly aims to validate the model by a

comparison of the model with the resource data

models presented in the literature.

2. THE PROJECT ENVIRONMENT

CHARACTERIS TIC S

Resources are consumed during the software process in order to delivera software product. The

software process has overallcharacteristicswhich

are super-ordlnate to the resources consumed.

Therefore,before resourcedata can be characterized it is necessary that a process characterization

profile be established, This characterization

includes data on factors such as:

projecttype

organizationaldevelopment conventions

projectmanager preferences

targetcomputer system

development computer system

projectschedulesor milestones

projectdellverables

In this data the broad project and its environment

characteristics are established, For example, is the

process using evolutionary development or a

waterfall method? Is the project to be developed

by in-house staff or external contractors? What

organizationalconstraintsare being imposed on

the projectdevelopment time? What management

constralntsare being imposed, say on staffinglevels?

These factors form the environment in which the

software process must occur, and will therefore

determine, in many ways, the nature of that

software process. A simple example of this is the

question of the process model - evolutionary or

waterfall. This constraint establishes milestones

and the pattern of resource use, and therefore

partially determines the interpretation of the

resource data collected.

3. THE RESOURCE CLASSIFICATION

At the level below the characterization of the project and its environment we are interested in classifying the resources consumed in the generation

of the software product. In this section of the

paper we present a structure for that

classification. This structure covers only the

resource aspect of the project and is therefore

only concerned with the software process and the

resources consumed or used in the process. The

model is not concerned with the software product.

As stated above, the resource model was first

developed and presented in [Jeffery, Basill 87]

5207

188

3-38

The model structure consi.sts of a four dimensional view. This four dimensional view is divided

into two segments:

I.resourcetype, and

2. resourceuse

In a software process the two segments being

separated are (1)the nature and characteristics of

the resource, and (2) the manner in which we look

at or consider the Consumption of that resource.

3.I Resource Type

In the firstsegment we are concerned with classifying the nature of the re_urce; iS lt=_meone's

time,or a physicalobject such as a computer, or

a logical object such as a piece of software? We

are also interested in describing the properties of

those resources such as description, model

number, and cost per unit of consumption.

By decomposing the resources into different types

different views of the resources can be provided.

For example, it may be important for operations

personnel to know a breakdown of the hardware

resources used on a project according to the

differentphysical machines being used, whereas

from a projectmanager's perspectiveat a point in

time, the specificmachine may not be of interest,

but the availabilityof a certainclassof machine

may be critical.Resource managers will be

interestedin the types of resourcesavailable(for

example, people)and the characteristicsof those

resourcesfor projectplanning purposes. Thus the

categorizationprovided here is the basis of the

resourcemanagement environment, in that itisin

this segment of the model that the resourcesare

listedand described.

The resources of a software project can be

classifiedas:

- hardware

- software

- human

- support (supplies, mater!sis,

cornmunicatlons facillty costs, etc.)

These categories are meant to be mutually

exclusive and exhaustive and therefore are able to

contain each instance of resource data in one or

other of the categories.

Hardware resources encompass all equipment used or potentially able to be used in the

environment under consideratlon. (For example,

target and development machines, terminals,

workstations).

Software resources, encompass all previously existing prograrns 4 and software systems

used or potentially able to be used in the environment under consideration. IFor example, compilers, operating systems, utdlty routines, previously existing application software).

m

R

i

m

I

I

t

m
Human resources encompass all the people

used or potentially able to be used for

development, operations, and maintenance in the

environment under consideration whether internal

or external (subcontractors, consultants, etc)

Support resources encompass all of the

additionalfacilitles such as materials, communications, and supplies which are used or potentially

able to be used in the environment under conslderation.

The values associated with these resources may be

stored in both price and volume measures, where

volume means, for example, hours of use or availability, or the number of times a resource is

needed, and price refers to the $ values associated

with that resource. This may be a cost per unit

measure or n cost per period of tlme.

This four-way classification provides an initial

resource-type decomposition. The aim in this

decomposition is to separate the major resource

elements that are used in the software process in

order to provide manageability. This initial

separation is necessary because of the very

different l_ature of each of these resource types

and the consequent difference in attriLutes and

management techniques which are necessary in

the estimation, evaluation, and control of each of

these resource categories.

Further decomposition within this segment may

be desirable and will be dependent on the goals of

the responsible persons. The number of different

posslbilltles increase as the decomposition continues within each of the major resource categories.

For example, the exact nature of the resource

decomposition wlthin the hardware category will

vary significantly from one organization to

another because of the different hardware utilized

and the organizational structure surrounding that

hardware utilization. For example, it may be

desirable to decompose hardware into target and

development hardware if there is a difference, and

software into operating systems and

languages/editors in order to model say the availability of cross-compilers.

3.2 Resource Use

Over the type segment we need to impose the

second segment; the "use" structure. The categorization within this dimension allows the resources

consumption to be associated with different perspectives of the software process. For example, it

is through this use structure that we are able to

distinguish, for example,

between prlor-project expectations of consumption and resources actually consumed, or

between resources consumed in each phase of

the project, or

between the utilization of a resource and the

availability of that resource, or

5207

189

3-39

between an ideal view of resource planning and

the resources actually available.

The use structure consists of :

1. INCURRENCE

1.1 Estimated

1.2 Actual

2. AVAILABILITY

2.1 Desirable

2.2 Accessible

2.3 Utilized

3. USE DESCRIPTORS

3.1 Work type

3.2 Point in Time

3.3 Resources Utilized

3.2.1 Incurrenee

This category allows the resource information to

be gathered and used in a manner suitable to the

management of the resource. It is necessary, for

example, to store data on *stimated resource

usage, resource requirements, and resource availability.

This data is necessarily kept separate from the

actual resource incurrence or use, which is stored

via the actual category.

These two categories then permit process tracking

'via comparisons between them and extrapolation

from the actual data. At the project summary

points, explanations and defined data accumulations on estimated and actual resource use provide

feedback on the process. This feedback should

contain reasons for variance between the

estimated and actual so that a facility for corporate memory can be established and the necessary data stored to facl]itate and explain any

updates of the current resource values. It needs to

be noted that the model proposed allows for

different estimates and actuals at different points

in time.

The two classifications are the basis for the structure proposed because they constitute significantly

different viewpoints on the process, and again provide mutually exclusive categorization which will

facilitate management estimation, evaluation, and

control.

This structure requires that process data, as it

changes in value during the project, will not be

lost but will be stored _an accessible manner so

that meaningful analysis_f projects can be carried

out using a database that provides complete

details of the project history.
This phl]osophyspecificallyaddressesthe need for

a corporate memory concerning past projects.By

implementing such a structuredproject log the

basic data for such a memory is available in

numeric and text format.

3.2.2 Availability

This category allows storage of a resource use by ;

- desirable

- accessible

- utilized

This categorization provides further refinement of

the resource data. Through this, and say the

]neurrence category., it is possibKe to compare the

actual resources utilized with the estimated utilization, and then trace posslb[e reasons for variance through the desirable and accessible dimensions. That is, differences between planned availability and actual availability of a resource will be

significant in understanding the software resource

utilization that occurred during the process.

Desirable is defined as all the resources

that are reasonably expected to be of value on the

project.

Accessibleis a subset of desirable(when

consideringthe projectresourceson]y)and isused

to definethe resourceswhich are able to be used

on the project.

The differencebetween desirableand accessibleis

those resourcesseen as desirablefor the project

but which were not availablefor use during the

project.This differencemay occur, for example,

because of budget constraintsor inabilityto

recruitstaff.The desirableresourcelistpermitsan

"ideal" planning view. When compared with

accessibleit allows management t¢ see th_e

compromises that were made in establishingthe

project,thus facilitatinga very explicitbasisfor

risk management within the resource database.

The database isthereby able to hold viewsof not

only the resourcesactuallyappliedto the project

but also those resourcesWhich were consideredto

be desirablealong with the reasons for theiruse

or non-use.In thisway the resourcetrade-offsare

made explicit.

Utilizedis a subset of accessibleand is

definedas the resourceswhich are used in a project.

The difference between accessible and utiiized

represents those resources available for the project

but not used. This difference will arise because of

three possible reasons:

1. The resources prove to be inappropriate for

the project under consideration, or

2. The resources are appropriate but they are

excess to those needed

5207

190

3-40

3. The resources are appropriate, and their use

is contingent on an uncertain future event.

The use of these storage categories is somewhat

complex and is explained in detailfurtherbelow

insection3.4.2.

Through this avaJiab_Jity category we are able to

distinguish between:

(1) the resources which are reasonably expected

to be beneficial to the process (desirable),

(2) the resources which exist in the organization

and are able to be used if needed (accessible),

and

3) the resources which are used in a project

utiliz.ed)

Through this categorization it is then possible to

track resource usage and to pinpoint their use or

non-use and to ascribe reasons particularly to

their non-use as in the case of non-accesslbillty.

As in the INCURRENCE category, the reasons

for divergence between desirable, accessible, and

utilized are stored in a feedback facility.

3.2.3 Use Descriptors

This category provides a description of the consumption of the resource item in terms of three

essential characteristics of the consumption that

item:

1. The Nature of the Work being done by

the resource: (e.g. coding, inspecting, or

designing) This category can be used in conjunction with other views to distinguish

between process actlvlties, such as human

resources estimated to be desirable in design

work, or machine resources actually utilized

in test[n9 , or elapsed time implications of

inspections,

2. Point in Calendar Time : This category

pinpoints the resource item by calendar

time. In this way resource items (estimated

or actual; desirable, accessible, or utilized)

are associated with a specific point in time

or period of time. This facilitates tracing of

time dependent relationships and the comparison of r_esource values over time.

3. ResoUrces Utilized : This category measures the extent of resource consumption in

terms of hours, dollars, units, or whatever is

the appropriate measure of use.

The Use Descriptors also provide the link to the

work breakdown structure which is commonly

embodied in process models. This link is established through the association of a _)art}cular

piece of work being do_ at a point in time with

the work package desclqbed in the work breakdown structure. This point is discussed further

below in Section 8, Validating the Model.

W

D

I

D

J

W

I

w

W

m

Q

J

J

i

U
ORIGINAL PAGE iS

OF POOR QUALIT_

3.3 COMBINING THE VIEWS

The structure suggested here can be viewed as a

hierarchy for the purpose of explanation. Such a

hierarchy is shown in Figure 1.

(DescrID_IO_ , mtleSto_cs, tlCQet _V_wlr;

_v#lOOmef_t hl_Ow_*e, _tlTver_les, ttg )

4>Co.furors

p

(Har_,_e. software. _aB

_oort Dt_s ittrlbules of the

IWP[ restore)

(Wo_ _ltuce, C$1en_=¢ _tme

FIGURE I. THE STRUCTURE OF THE TDC MODEL

In this figure we see that the proposed structure

views the softwaxe project (which has attributes

describing that project) consuming resources. The

resources are characterized as having four dimensions of interest (type, use, incurrence, and availability). At the resource type level we describe each

resource as being one of hardware, software,

human, or support, and having various attributes.

The attributes for each of these four types will be

different in nature. For example, the human attributes might include name, address, organizational

unit, skills, pay rate, unit cost, age, and so forth.

The attributes for hardware will be quite

different, describing manufacturer, purchase date,

memory capacity, network connections, or similar

types of characteristics.

At the next level in the diagram we model the use

of the resource. In the first instance this involves

the type of work that the resource is performing,

the point (or span) in calendar time at which the

work is being done, and the measure of the

amount of work done. This last measure (amount

of work) might be expressed in person-time,

execution-tlme, connect-tlme, or whatever is the

relevant measure of work for the resource

instance.

The use of the resource is then described as being

either estimated or actual, and both of these may

be desirable, accessible, or utilized. In this way

the followingconceptsare supported :

1. Estimated Desirable : The resources considered "ideal" at various stages of the planning

process.

2. Estimated Accessible : The resources

which are expected to be available for use in the

process, given the constraints imposed on the

software process (a contingency plan).

3. Estimated Utilized : The resources which

it is anticipated will be used in the software process.

4. Actual Desirable : With hindsight, the

resources which proved to be the "ideal" considering the events that occurred in the software process. A part of the learning process.

5. Actual Accessible : Again with hindsighf,

the resources which were actually available and

could have been utilized. A part of the learning

process.

6. Actual Utilized : The resources actually

used in the software process.

Categories one through three are used initially for

planning purposes. The numeric and text values

associated with each of these three categories may

be derived from:

a. individual or group knowledge

b. a knowledge base

c. a database of prior projects, and/or

d. algorithmic models

At the very simplest level, the planning process

might establish only numeric values in the

estimated utilized category based on individual

knowledge alone. In essence, this is the only form

of estimation used in many organizations, wherein

project schedules and budgets are established by

an individual, based on that individuals experience. These estimates represent the expected project and resource characteristics for the duration

of the project.

The extensions suggested here allow these estimates to be enlarged in the following dimensions :

The nature of the estimate

The source of the estimates

The timlng of the estimates

1, The nature of the estimate. The model

allows project and resource managers to distinguish between desirable, accessible, and utilized

estimates as discussed above. The estimated desirable dimension would be used at a fairly high

level in the project planning process to outline the

hardware, software, people, and support resources

that are considered to be desirable for the project.

This may list specific ._.eces of hardware and

software which are desirable at certain points in

time. It might also be used to list characteristics

or"the people (such as skills), tha_ wou_d be ideal

on the project. The accessible dimension would

5207

191

3-41
m

then reflect the expected resources that will actually be available to be used. Again this could be

at a fairly high level, indicating the resources

available, the differences between these and those

desirable, and the reasons why the two categories

do not agree; reflecting cost constraints, or risk

attitudes which have been adopted as part of the

project management profile. The utilized category

would normally extend to a lower level in terms of

the project plan, detailing estimated resources

perhaps down to the work package level and short

periods of time.

2. The source of the estimates It was suggested above that there are four major possible

sources for these estimates; individuals or groups

of people, a knowledge base, a database of prior

rojects, and algorithmic models of the process.

ach of these should be supported in a measurement environment, and each has significant implications with respect to the design of such an

environment. The current state of the art appears

well equipped to support algorithmic models of

some parts of the est]mation process (for example,

estimates of project effort based on one of the

many available estimation packages such as

COCOMO [Boehm 81], SLIM ]Putnam 81], SPQR

[Jones 86]). Similarly the tools available in the

database environment allow the storage and

retrieval of numeric data on past projects. However the storage and searching of large volumes of

text data on prior projects, the use of a

knowledge base, and the support of group decision

support processes are all the subject of current

research (see for example, [Bernstein 87],

[Nunamaker, et.al. 88], [Barstow 87], [Valett 87]).

The timing o/ the estimates In the structure suggested, all estimates may be made before

the commencement of the software process and

also at any point in time during the process. However there are certain po!nts in time during the

process at which estimates are more likely to be

updated. These are:

1. at project milestones

2. at manager inltlated points in time at

which major divergence between estimate

and actual is recognized by the manager

3. at system initiated points in time at

which the measurement system recognizes a

potentlaily significant divergence between

estimate and actual

The third possibility implies that the measurement system is able to intelligently recognhe the

existence of a problem with respect to the comparison of actual and estimate. This facility is

suggested as needed because one of the major

management stumbling blocks is generally not

concerned with taking action once a problem is

identified, but the identification of the problem in

the first place. Thls ident[t]cation problem occurs

because of the volume of data that needs to be

roCessed in order to recognize a potential probm state. It is the measurement environment

5207

which is expert at processing the data volume. It

is the manager who is expert at taking corrective

action once the problem is highlighted.

Categories four (actual desirable) and five (actual

accessible) of the structure exist to provide a feedback and learning dimension to the project database. These values would be determined after the

project is complete. And in the comparison of the

estimates made at various stages of the process

and these two categories, a process is facilitated in

which the organization can learn based on the

variance of expectations and actual which have

occurred in the past projects. As with the estimates, the categories of desirable and accessible

are used in order to allow the comparison of

"actual ideal" with "actual available _ so that an

ex-post 'view of the management of the process

can be captured. The question being asked here is;

"How could we have handled resources better?" It

]s a learning mechanism to generate explicit new

knowledge for the knowledge and data ba_es, and

also to improve individual and group knowledge.

Category six (actual utillzed) will be the most

active category within the structure, carrying all

of the values assoclated with the resources of the

project. These values will be updated on a regular

basis throughout the software process, and will be

the source of the triggering process mentioned in

the discussion of updates to the estimates.

The data collected during the project should be

able to:

1. increase individual ahd group knowledge

2. improve the knowledge base

3. add to the prior project database, and/or

4. support the algorithm determination

process in the individual organization.

In summary, the model proposed is a four dimensional view of resource data. The four views in the

data model are:

1. RESOURCE TYPE: which is a mutually

exclusive and exhaustive categorizatien

which Captures the nature of theYesource.

2. IN_NCE: which is also mutually

exclusive and exhaustive describing actual or

estimated resources. It carries an addkional

feedback e|em_ent to contain the corporate

memory exp[a[fiing tSe difference bevween

the category values and dlfferences over

time.

3. AVAILABILITY: in =Which each categ0ry

is a subset of the the higher category, allow:

ing desirable, accessible, and utilized

resources. Again feedback is used to explain

the differences between categories and over

time.

192

3-42

I

g

m

m

M

N

g

m

D

m

m

U

m

w

m

J

m

=.--

i

I

_=

IIW

m
w

ORiGI,NAL PAGE IS

OF POOR QUALITY

4. USE DESCRIPTORS: which categorizes

specific elements in the nature of the

resource use. These are the nature of the

work done by the resource, the point in time

of the work, and the amount of that work.

3.4 USING THE TD_'STRUCTURE

3.4.1 At the project level

Discussion so far has applied the proposed 4D

structure to _source cla-_sification. It is appropriate to also consider using this structure, or a part

of it, for the Project Environment Characteristics

outlined in section 2 above. In thls way the constraints acting on the software process can be

identified as applying:

to a particular type of resource,

either estimated or actual

with a stated availability

at a point in time,

concerning a particular type of work

An overallmodel of the software projectisshown

in Figure 2. In this figurethe meta-entityproject

is decomposed into a number of tasks or contracts, each task consuming the meta-entity

resourceand producing the meta-entityproduct.

In the implementation of this model the metsentitieswill requiremany entitiesto characterize

them.

:a_[$?$ of

FIGURE 2. AN OVERVIEW OF THE SOFTWARE PROJECT

Thus the project has characteristics,as do the

tasks and subtasks, the resources,and the products. Characteristicsat allof these levelsneed

to be stored.

Through the storageof the projectcharacteristics,

the constrMnts actingon the product or process

determined at any time beforeor during the project can be tracked for consistency,and any

changes noted to facilitatea relationshipanalysis

between the project and the resourceoccurrence

valuesaccumulated duringthe process.

5207

193

3-43

A simple example of the applicationof thisstructure would be where the processorganizationis

changed during the development, say a change

toward greater user involvement. This change

would be reflectedin a differencebetween the

estimated project characteristic and those at the

point in time at which the change occurred. This

in.formation is then used to explain variances that

occur in the process data, such as a changed pattern in staff utilization.

Examples of the data stored at the project level

would include:

- the type of project

e.g.real time, business application

- the project elapsed time

- the total project effort

- the total project cost

- the type of development process

e.g. evolutionary

- the target computer

- the development computer

- the project deliverables

- the project milestones

- the project risk profile

The applicationof the TDC model at this level

providesa mechanism for storingestimates,accumulating actualvalues,and facilitatingfeedback

and learningat the levelof the project and its

development environment.

If we take the projectmilestonesas an example

and assume that the milestonesapply equallyto

all resource types, then the model suggests we

store:

estimated desirable milestones. This is an

"ideal world" view of the project milestones;

the dates at which we could deliver if we were

not constrained.

estimated accessible milestones. Given the

constraints we will be working under, these are

the dates at which we could deliver if it were

necessary.

- estimated utilized milestones. These are the

dates at which we expect to deliver, taking into

account the dlmensions of desirable and accessible.

These three views, in their values and difference,

provide a perspective on the risk associated with

the project; the smaller the dlfference between the

categories, the higher the risk. More specifically,

the difference between estimated desirable and

estimated accessible shows the extent to which

elapsed time could be changed if the constraints

could be modified. For example, if the estlmated

final desirable milestone were June 30th and the
estimatedfinalaccessible milestone was August

30th, the difference of two months measures the

estimate of the extent to which the project could

be compressed if the restricting constraints could

be be removed.

The difference between the estimated accessible

and the estimated utilized provides a measure of

the available slack in the milestones. This

difference is the extent to which the milestones

could be compressed, without modifying the project constraints. In the example above, the

estimated utilized final milestone might be say

November 30th. In this ease the difference

between accessible and utilized of three months

reveals the amount of elapsed time compression

that is possible on this project without changing

constraints.

In these relationships we see some of the dynamic

nature of the project characteristics. This suggests

that for the TAME measurement environment, if

a change in project characteristics such as the

nature of the process occurs, then this should

trigger the review of the project milestone and

effort values, which will also be reflected at the

lower level in the task and resource data values.

In the actual category we need to store the •

actual desirable milestones. As explained

above, this category is used for feedback and

learning. It carries the values calculated after

project comp]etior, based on the knowledge

gained about the project during its completion.

This value is again an "ideal world" value.

- actual accessible milestones This is also a

feedback and learning category which says,

based on the constraints which did eventuate

in the process what milestones could have been

achieved?

- actual utilized milestones. Thls category stores

the dates of the milestones achieved.

Differences between actual and estimated are

stored in a feedback facility to provide a

mechanism for learning and a mechanism for

calculating the actual desirable and accessible

at project end.

3.4.2 At the resource level

The description of the use of the TDC structure

at the resource level amounts to a process model

of resource planning and use in software development. This process can be described as an

interacting three-stage process involving the subprocesses of:

1. planning

2. actualization

3. review

The planning process establishes and records the

resource expectations or estimates before and dur5207

194

3-44

ing the software project, and the actualization

process tracks and records the actual use of

resources dur]ng the software project. The review

process compares actuals with estimates for the

purposes of modifying the estimates and learning

from experience. In this way the feedback referred

to above provides information for an historic

resource database for future planning and estimation. Details of this process model are given in

[Jeffery, B_ili 87].

Applieat|on of the planning and review

cycles

In any particularorganization,itmay be deemed

sufficiento use only a part of the planning and

review processesoutlinedhere,and thereforeonly

a part of the TDC structure presented in this

paper.

For example organizationsmay not wish to use

project reviews, or they may not consider it

appropriateto carry out formal contingency plannmg or risk management. At the simplest level

only the estimated utilizedand the actualutilized

may be used,perhaps providinginput to an informal project learningprocess which occurs at the

individuallevel.

Specifically,it is most Hke[y that in software

environments with very littleuncertaintyIsay-an

imp[ementatlon of the twentieth slightlydifferent

versionof a well known system) theremay be no

need to explicitlyc_onsiderthe desirableor even

accessibledlmensions of the resource model. If

uncertainty isvery low, the utilizedlevelof the

model may capture all the necessary data. The

advantage of the model in thls case is that the

data excluded is done so in the knowledge that

there is no information in those levels not used.

In higher uncertainty environments, the model

prompts the estimator to think explicitly of the

resource risks and uncertainty of the development

process, and to quantify or express that risk as a

part of the resource database.

4. VALIDATING THE MODEL

Three significant pieces of work in the literature

which provide definitions of the types of data

needed to support the measurement of the

software process are [Penedo, Stuckle 85],

[Tausworthe 79t, and ]Data & Analysis Center for

Software 84, STARS Measurement DID Review].

Penedo and Stuck[e (P&S) provide an excellent

structure and content of a project database for

software engineering environments which can be

used here to test whether the model resulting

from the top-down methodology employed is able

to encapsulate all of the process data suggested by

them as needed in a proj_t database, Table 1

lists the entities identified by Penedo and StuckIe

and associates the particular model categories

which would be used in the model derived here to

describe them.

m

w

t

L_

a

U

mm

z

m !

u

M

N

U

I
= =

The first aspectwhich isnoticed when mapping

the 31 P&S entitytypes to the TDC model isthat

the broad structurepresented in section2 above

(The Project Environment Characteristics)is an

important link between the software processand

product. The P&S listcontains entitiesfor the

project,task,product, and resourcecategoriesof

Figure 2. In table 1 the P&S entltiessuch as the

requirement aud risk have been categorized as

projectcharacteristlcs,while entitlessuch as data

component, externalcomponent, document, interface,product description,product, and software

component have been categorized as product

instances.

But the focus of this paper isnot on the project

or the tasks which go togetherto make up that

-project.Rather the focus is the resources consumed by those tasks.In this respectwe notice

that only a subsetof the availableTDC categories

are used in the P&S entities.For example, at the

Resource Type levelwe see instancesof allfour

categories(Hardware, Software,Human, and Support),but at the next levelit appears that the

P&S model concentrateson actual values.It is

difllcu]tto see how the P&S mode] storesvalues

for estimates,and particularlyhow the information explainingdivergencebetween estimate and

actual can he stored.The same appliesto the

Availabilitylevelof the TDC structure.The P&S

model appears to concentrate on the Utilized

aspect and does not appear to model the other

availabilitydimensions presented in the TDC

structure.This may well be because these dimensionsof resourcedata were considerednot to be

necessaryin the environment of the P&S study.

Table I. P_kS DLtabue Entities in The Model Structure

Penedo & Stuckle Top Down Model

Entiti_ Categories

Accountable Tuk The tuk nnd contract are the

Itad Contact co1_v_l'_nce o_"prc_Mn

and product and subsets of the project.

It in ia • contract

or tuk that resources are consumed

to produce the product. Thny a_e not,

theref_e, resource entities

Chn|n hem Th_ item m $ener_iy usociMed

with n product ¢h_ge.

Conlumsble PurehMn *Support resource, iacurrence L.d uv_nbility

not n_ecifled.

D-'a Compo0ent Product Entity

Dictlonacy *Softwnre ru.ource, or perhl-pn product entity

Document Product Entity

Equipment Purchue "HLrdwate resource

Extera_ Component *Hm'dwzre resource or perhnps Product _,ntity

H_dwLte Architecture *H_'dwate resource _r perhlLp| product entity

H_dw_e Component *_-l_dwl_e resouT_e Or prO4UCt entity

interface Product ]_ntlty

Milestone *Proiect Entity

Oper_ion_ Scenario Product Entity

Per_n *Hum_ R.ource

Problem Report 'Process u patt of feedblck or Product entity

Product Product Entity

Product Description Product Entity

Requirement Project Entity

Resource *Supgort r_source

Rink *Pro,iect Entity

Simul_ion ProducT, entity

Software Component Product Entity

Software Configuration Product Entity

Software Executable Tuk Product Enti_z

Software Purchue *Software resource

T_t Csse *Software resource _nd/or precinct entity

Test Procedure *T_k or project chm'tcterlstlc

Tool *Softwate resource

WBS Element Project Decomp_ition Entity, may "be the ame

u accountable tub _.nd contrnct

It remains to be seen,of course,whether allof the

categoriesavailable in the TDC structure are

deemed necessary in any particularenvironment.

However, the advantage of such a structure is

that exclusionof certaincategoriesof data occurs

explicitlyratherthan implicitly.

The second model suggested as a means of testing

the TDC model isthat provided by ITausworthe

79]. In this work the models entitiesare not

presented in a listform, but are included in text

discussionand reportforms.For thisreasonithas

been necessary to convert the form to a listof

entities.In doing so it ]s always possible that

misconceptions of Tausworthe's ideas may be

•present.However, even ifincomplete,it provides

another testof the suitabilityof the TDC mode!,

The Tausworthe structureisvery much oriented

towards a decomposition of the projectinto tasks

and the associationof resourceswith those tasks.

Thus the modelling approach used by Tausworthe

is somewhat at a tangent to the mode]ling

approach used here since once again our focus is

on resources, not the activities which consume

those resources. This is not to say, however, that

it is not necessary to associate resources with

tasks, but that it may-._e necessary to model

resources apart from the t_asks that consume them

in order to better understand all of the dimensions of resource data.

5207

195

3-45
The entities listed here are a partial list derived

from the work breakdown structure, the software

technical progress report, the software change

analysis report, and the software change order of

Tausworthe's model. From these sources the following resource data, among others, were

identified as necessaw to establish a resource

database. Only some"_ the Tausworthe entities

have been listed here. Tb.is has been done to the

extent that is necessary to illustrate the conclusions drawn.

From Table 2 it is clear that the focus of attention in the Tausworthe work is the project and

the decomposition of that project into its component parts. Thus we see that the resource data

is associated with particular tasks and activities.

In viewing the data in this way a structure is provided which is excellent for control purposes, in

that it establishes units of accounting which are

more easily estimated and controlled. What is not

clear from the structure, however, is how questions of desired versus accessible resources can be

modelled, nor exactly how actual versus estimated

can be compared and conclusions stored for use in

later project estimates. It is also difficult to see

how the model proposed in the WBS can easily

facilitate the analysis of resources consumed on a

particular activity type (say inspections), regardless of the project phase in which the inspections

were done or the project task in which 'they were

done. Thus questions such as the value to the project of using a particular form of inspection may

be difllcult to answer because the data model may

make this data difficult to isolate.

Tn'bh 2. Tsusworth* D_rivtd Entity List

Tnusworth,

Entitim

StaB:

St_ I.D.

St_ N,m,

$tLff Phon,

_Fuk :Activit3,:

Tuk LD.

Tuk Actiyity I.D.

Budlet $

Tuk:

TME LD.

TMk b/am,

TMkDeJ_

TMk M'pr

Ta*k Budg*t $. ETC.

Sottwsre C_l,e OTd*r

S/wsre E)

Chang. Order #

Activity ID

Person ID

Description

Start Dat4,, eta,

Top Down Model

CsCeSori_ _

Hurna_t relouree, eetimtted or tctueJ

The _ollu .*J,e may be • s,m or _1 rt_ourcw

¢onsum.d on • tmlk-*ctlvlty, estimated or •¢tual

Th* wlJun bl t sum of id] rt-Joureen, entire•ted

*rid/or _'_. u*J

The focus ta tlaia on the tetivlty. The resetltees

may be tar type, eltimtted or *_tutJ.

However, it is clear that the resource data suggested as necessary by Tausworthe are readily

modelled in the TDC structure. The importance

of the application of the TDC model to the project and task level is highlighted by Tausworthe

and also Penedo & Stuckte, so that the association of resource data and project work breakdown

structures can be facilitated.

5207

196

3-46

Perhaps the most detailed resource data collection

forms developed so far has been that of the

STARS Measurement Data Item Descriptions.

The information which follows in Table 3 was

derived from stars Software Development

Environment Summary Reports DI-E-SWDESUM,

DI-F-RESUM, DI-F-REDET, [06 JULY 1984 I.

These reports contained information most

relevant to the task of validation of the TDC

model. The data suggested as necessary by these

reports concerned aspects of the project, the process, and the product. In this paper only those

aspects concerning the project and the process

have been listed. As with the Penedo and the

Tausworthe models, the data model implied in the

work appears not to have been developed on the

basis of a theoretical structure, but rather from a

pragmatic evaluation of those data items deemed

necessary for project management. In addition,

because the data items are

listed in the context of data capture form J, some

rearrangement of these items has been carried out

in the following data list in order to provide a

clearer presentation of these items.

W

m

r

BII

m

U

g

M

u

lIB

U
TABLE 3. STARS Measurement Data Items

Descriptions

=

A. PROJECT NAME

Project Name _.

Contractor ----

Contract No.

Start date, Finish Date

Software Level (System, Subsystem, CSC_

Application Type

Application des_riptinn

Revision of current project (y/n)

Revision -version no.

of software redeveloped

ToUd no. lines of source code

Initial development (y/n)

if y - Total no. lines source code

no. of i_tructinne

no. of data words

System Structure- ..

single overlay

multiple overlay

(_ overlays, avg. sise bytes

independent subsystems

(# subs, avg.sisebytes

virtual memory system

(amount of addressable memory, siae bytes

Progamming language and _ used

Constraints -

Execution Time, rating

Main memory size, rating

product Complexity, rating

Databue size, rating

Methodology, rating

required reliability, rating

Other, rating

Concurrent Hardware development (y/n)

Operational site development (y/n)

Multiple site development (y/n)

no. of development sites

no. of test sites (if different)

Other Constraints .(text).

cost estimation amsumptions made

cost estimation methods used and supporting

rationale

rationale for discrepencies between current

estimates and all previous estimates

B. SITE CONFIGURATION INFORMATION

Site 1D

Description (development, test)

Computer manufacturer

Model name

Model no.

no. of persons accessing site

no. of input terminals

Terminals in each programmers office (y/n)

Input terminals in central area (y/n)

no. of card readers

no. of printers

no. tape drives

no. disk drives

other peripberals.(specify).

no. documentation set_ on hardware/software

environment available

no. site support personnel

amount of storage in development computer

main memory real

main memory virtual

aux memory

DEVELOPMENT SITE ACCF__S

Site I.D.

Access type: ¢_ batch

e_ interactive

Average job turnaround time

no. hours per day development site available

no. days per week development site available

no. hours per day utilized

no. days per week utilized

TEST SITE ACCF--£S

SiteI.D.

no. hours per dsy testsiteavailable

no. days per week testsiteavailable

no. hours per day testsiteutili_ed

no. days per week testsiteutilised

5207

197

3-47
C. PROJECT PHASE INFORMATION

Iexamples]

requirementa

Development system used (y/n)

Documents maintained on the dev.system (y/n)

Methodology (formalspec.,functionalspec.,

proceduralspee.,englishspec.,none,other)

Tooh/Formalisma (requirementsanalyzer,word

processor,on-lineeditor,em.t.,librarian,

spec lang_ PD_L, none, other)

startand finishdate

delivarab]es

dMlgn

Development system used (y/n)

Documents developed/maintainedon system (y/n)

Methodology (topdown, bottom up, hardest

first, pmtotyping, iterative enhancement,

none, other)

Tools_0rmaiisma ( softwaredev. folders,

design reviews, walkthru's, flow charts,

HIPO, etc.)

start and finish date

deliverables

implementation

Development system used (y/n)

Documents maintained on development system (y/n)

Unit testingperformed on dev.system (y/n)

Methodology (topdown, cpt,prototyping,etc.)

Tools/Formalisra_ ( code reading, pre-compiler,

dbms, ere)

start and finish date

deliverables

test and Integration

Testingperformed on development system (y/n)

Documents maintained On system (y/n)

Level of testingperformed on dev system

Methodology (specdriven,top down, none,etc)

Tools/Formalisms(...... )

start and finish date

deliverables

D. PROJECT PERSONNEL INFORMATION

]these values can be derived from more detailed

records]

ProjectName

Job Classification(supervisor,consultant,

analyst,programmer, siteoperator,

librarian, other)

Avg. no. years application experience

Avg. no. years experience with software

ArK. no. yrs software training

Avg. no. yrs programming language experience

Avg. no. yrs hardware experience

Avg. capability rating

eommtmlcatlon

Regular projectstatusmeetings (y/n)

How often?

Personstypicallyinattendance

(cl_ification,No.)

E. RESOURCE EXPENDITURE ATTRIBUTES

summary level

]these values may be derived]

Project name

total system cost, estimated, actual

total software cost, estimated, actual

total labour cost $, estimated, actual

total software labour cost $. estimated, actual

total labour hours, estimated, actual

total software labour hours, estimated, actual

total staff size, start, finish, estimated,

actual

totalsoftwarestaffsize, start,finish,

intimated, actual

totalcomputer costa$,estimated,actual

total software computer costs $, estimated,

actual

totalcomputer hours,estimated,actual

totaltravel costs$

total material costs $

total miscellaneous costs $

[these may be divided by milestones or activities]

labour costa

ithesevaluesmay be derived]

labourcategoryid

tots] hours

no. of people, start, finish

cost$

computer hours

computer costs$

computer costa

Ithese valuesmay be derived]

no. of computers used

no. of different types of computers

total computer hours

*** for each computer***

computer i.d.

number ofhours

totalcomputer costs$

costof each computer $

tuk costs

[these values may be derived I

tLsk i.d.

definition

personnel costs

software costs

hardware costs

supplies costs

 for each task'** * ****for each ta_k'***

****for each labour category""

totalhours

no. ofpeople,start- finish

cost$

computer hours

computer cost$

travelco_t$

total cost of labour

total hours of labour

total cost of computer

total hours of'computer

totalcostof travel

total cost of materials

total cost of miscellaneous

t

Im

m

m

g

g

I

m

n

J

I

_Mm

5207

198

3-48
The Table provides data items to describe the

project, development and test site configurations

and access, project phases, personnel assigned to a

project, and resource expenditure summaries. The

detail shown here has been selected to highlight

the volume of data items which will be necessary

in a measurement system.

In terms of the TDC model, the STARS list shows

recognition of the need to store resource availability in that the development and test slte access

data includes an accessible and a utliized dimension. There appears, however, to be no facility for

storing the desirable dimension suggested in the

TDC model. The STARS list also shows extensive

use of the incurrence dimension in section E -

Resource Expenditure Attributes, wherein

estimated and actual resource use is tracked. The

USE DESCRIPTORS of work type, point in tlme,

and resource utilized are also extensively used in

the STARS list. It is not possible from the documentation, however, to determine the reasons that

the availability dlmension was not applied more

extensively in the data model (for example accessability of personnel or specific hardware or

software items are not modelled). It can be

assumed that it was considered to be ]nnapproprlate for entities other than site access.

The STARS data list provides considerable support for the theoretical structure provided in the

TDC model. It reveals a considered need for the

storage of :

I.Projectinformation

2.Resource type information

3.Incurrenceinformation

4.Availabilityinformationand

5. Use descriptors

Of considerable significance is the fact that none

of the three schemas considered here have suggested data entities or items which cannot be successfully modelled using the TDC structure. It

appears that the schemas considered here may be

incomplete when compared with the TDC structure, but the reasons for the apparent exclusion of

data entities and items are not known, but may

be based on purely pragmatic reasons.

5. CONCLUSIONS AND IMPLICATIONS

AT THE RESOURCE DATA LEVEL

The model presented here is meant to be general

and provide a perspective for project manager and

organization in identifying and tracking resources.

It should help in better understanding the

compromises made in resource allocation. However, it is assumed that any project (or even

organization) will work with a subset of this

model. For example, one might limit the number

of availability views, such as combining desirable

and accessible, or track only a subset of the

resource categories. The subsetting process provides feedback on what has not been tracked. The

actual data collected is driven by the

goal/question/metric paradign based upon the

goals set by the project and the organization.

The conclusions to be drawn from this research

can be divided into two categories: those concerning the model itself, and those concerning the

validation of that mode].

In terms of the model itself, the discussion has

suggested storage of resource data of a type which.

has significant storage and access implications;

that of numeric and non-numeric project and

resource data. It has been assumed in the discussion that the resource database is able to store

not only numeric resource values, but also reasons

for those values along with the resource environment characteristics.

A system using these suggestions should be able

to e_]ciently search the numeric and non-numeric

data in a manner which will eventually enable the

system to propose reasons for numeric variances

which occur in the database. In this way the system must be able to not only highlight a

significant variance, say between an estimated

and an actual resource occurrence value, but it

should also be able to search the project characteristic database and the numeric and nonnumeric resource classificatlon database in order

to propose or associate reasons for the variance.

It can be said that the model presented here has

four broad implications :

I. It proposes a resource categorization

which will allow project database designers to

explicitly consider the content of that database

against a model of the resource environment. In

this way, a particular individual's view of the

resource data can be positioned in a context and

compared with other external views of the same

data. This model should motivate the resource

data user to consider the measures that may be

beneficial ia seeking improvement in the particular process goals.

2. It suggests a project management

system's environment which will be able to

achieve far more in terms of management support

than any known environment available today. It

is able to do this because of the extent and

dynamic nature of the model of the resource data

proposed.

3. It provides a resource categorization

which can be used when considering relationships

between tasks or contracts and resources.

Specifically it provides a focus for the consideration of the resources consumed within a task.

4. It provides assistance when applying the

Goal/Question/Metric process paradigm, so that

questions which answer the resource purpose of

the study are highlighted and the measures

appropriate to those questions are suggested.

In terms of the validation of the data model we

5207

199

3-49
have seen by reference to three published models

that the proposed theoretical structure for

resource data is able to encompass all that has

been suggested as necessary for resource managemeat. Also of significance, is the fact that each of

the publications used contains different views of

the nece._ary data and that each one omits certain elements that the other appears to consider

of benefit. This is, of course, the norm in comparing different external views in a database design

exercise. One advantage of the TDC model is that

it is able to act as a data model template, suggesting the data categories which need to be considered when designing a resource data schema. If

it is used in this way the data items excluded

from the particular resource model instance will

have been excluded on the grounds that they are

deemed unneccesary in the partlculai-en_,]ronment, rather than being excluded because the

category of data ( for example, estimated desirable hardware for testing) was not noticed by the

data base designers as necessary.

Thus we can be confident that the theoretical

model proposed in the TDC structure can contain

all of the project and resource data so far su_

gested in the literature as necessary in a resource

management environment. In addition it appears

that there may be project and resource information of use in resource management which has not

been included in prior models. The practical need

for this additional information has not been

justified in this piece of research but is the subject

of other current work by the authors.

We have begun to apply the model independent

of TAME in a couple of industrial environments

and have found it provides a useful framework for

planning and tracking resources throughout a project. We have not yet reached the stage where we

have been able to evaluate the feedback process,

however.

8. REFERENCES

[Barstow 87] D. Barstow, "Artificial Intelligence

and Software Engineering," Proc. 9th Intn'l. Conf.

on S'ware.Eng. IEEE, Monterey, April, 1987,

pp.200-211;

[Basili 85] V.R.Basili, "Quantitative Evaluation of

Software" Engineering Methodology," Proc. First

Pan Pacific Computer Conference, Melbourne,

Australia, September, 1985.

IBasili, Freburger 81] V.R.Basili, K.Freburger,

Programming Measurement and Estimation in

the Software Engineering Laboratory," The Journal of Systems and Software, 2, 1981, pp. 47-57.

_tBasill, Panlilio-Yap 85] V.R.Basili, N.M.Panlilioup, Finding Relationships Between Effort and

Other Variables in the SEL," Proc. 9th COMPSAC Computer Software & Applications Conference, Chicago, October, 1985, pp. 221-228.

IBasili, Rombach 87] V.R.Basili, H.D.Rombach,

allorlng the Software Process to Project Goals

and Environments," Proc. 9th Intn'l.Conf. on

S'ware Eng. Monterey, April,1987,pp. 34S-357.

_asi]i, Se]by_,Phillips 83] V.R.BasiIi,R.Selby,

.Y.Phillips,Metric Analysis and Data ValidationAcross FORTRAN Projects,"IEEE Trans. on

Software Eng. Vol. SE-9 No.8, November, 1983,

pp.652-663.

asill,Weiss 84] V.R.BasiIi, D.M.Weiss, "A

ethodology for Collecting Valid Software

Engineering Data," IEEE Transactions on

Software Engineering, SE10,3, November,1984,

pp.728-738.

Berustein 87] P.A.Bernstein, "Database System

upport for Software Engineering, Proc. 9th

Intn'l. Conf. on S'ware. Eng., Monterey, April,

1987, pp. 166-178. - :

LBoehm 81] B.W:Boehm, Software Engineering

Economics, Prentice-Hall Englewood Cliffs, New

Jersey, 1981.

[Chrysler 78] E.Chrysler, "Some Basic Determinants of Computer Programming Productivity," Comm. of the ACM, 21,6, June, 1978, pp.

472-483.

ID_ata & Analysis Center for Software 84] STARS

Measurement Data Item Descriptions, Data &

Analysis Center for Software, RADC/COED,

Griffiss AFB, N'Y. July, 1984.

[Jeffery 87a] D.R..reffery, "The Relationship

between Team Size. Experience, and Attitudes

and Software Development Productivity," Proc.

COMPSAC87, Tokyo, October, 1987.

[Jeffery 87b] D.R.Jeffery, "A Software Development Productivity Model for MIS Environments,"

Jnl. of Systems And Software, June, 1987.

[Jeffery, Sasiil 87] D.R.Jeffery, V.R.Basili,

"Characterizing Resource Data: A Model for Logical Association of Software Data," Technical

Report TR-1848, University of Maryland, May

1987, 35pp.

iJeffery, Lawrence 79] D.R.Jeffery, M.J.Lawrence,

An Inter-Organizational Comparison of Programming Productivity," Proc. 4th Intn'l Conf. on

S'ware. Eng. Munich, 1979, pp.369-377.

LJeffery, Lawrence 85] D.R.Jeffery, M.J.Lawrence,

anaging Programming Productivity," The

Journal of Systems & Software, 5,1, February,

1985, pp. 49-58. : :_: :,

Jones 86] T.C.Jones, SPQR/20 User Guide V1.1,

oftwsre Productivity Research Inc. January,

1986 ..............

J

m

m

m

g

I

m

5207

2oo

3-50

!
Nelson 67] E.A.Nelson, "Management Handbook

r the Estimation of Computer Programming

Costs," System Development Corporation, Santa

Monica, March, 1967.

[Nunamaker, Applegate, Konsynski 86]

J.F.Nunamaker, L.M.App__gate, B.R.Konsynskl,

"Facilltating Group Creatf'v_ty: Experience with a

Group Decision Support System," Proc. 20th

Annual Hawaii Intn'l. Conf. on System Sciences,

Hawaii, January, 1987, pp.422-430.

iPenedo, Stuckle 85] M.H.Penedo, E.D.Stuck[e,

MI)B - A Project Master Database for Software

Engineering Environments," Proc. 8th Intn'l.

Conf. on S'ware. Eng., London, August, 1985, pp.

150-157.

utnam 811 L.H.Putnam, "SLIM A Quantitative

ooi for Software Cost and Schedule Estimation,"

Proc. NBS/IEEE/ACM Software Tool Fair, San

Diego, CA, March, 1981, pp. 49-57.

ackman, Erikson, Grant 881 H.Sackman,

.J.Erlkson, E.E.Grant, Exploratory Experimental Studies Comparing Online and Offline

Programming Performance Comm. of the ACM,

11,I, 1968, pp. 3-11.

Ta_worthe 79] R.C.Tausworthe, Standardized

evelopment of Computer Software: Part II Standards, Prentice-Hall, Englewood Cliffs, New Jersey, 1079.

[Valett 871 J.D.Valett, "The Dynamic Management Information Tool (DYNAMITE): Analysis of

the Prototype, Requirements and Operational

Scenarios$ M.Sc. Thesis University of Maryland,

1087.

htalston, Felix 771 C.E.Walston, C.P.FeHx, "A

ethod of Programming Measurement and Estimation," IBM Systems Journal, 16,1, 1977, pp.54-

73.

olverton 74] R.Wolverton, "The Cost of

eveloping Large Scale Software," IEEE Transactions on Computers, 23,6, 1974.

5207

201

3-51
Ill

II

I

m

m

mm

ilm

g

I

I

i

g

I

_E

W

I

rl

Imm

d

J

m
I

SECTION 4 - ADA TECHNOLOGY STUDIES
JB

ii:

ul

imJ z

il

iip

mi

iB

±

JJl
SECTION 4 - ADA TECHNOLOGY STUDIES

The technical papers included in this section were originally

prepared as indicated below.

• "Experiences in the Implementation of a Large Ada

Project," S. Godfrey and C. Brophy, Proceedinqs of

the 1988 W_hinqtQn Ada Symposium, June 1988

• "General Object-Oriented Software Development with

Ada: A Life Cycle Approach," E. Seidewitz, Proceedinas of the CASE Technoloqv Conference, April

1988

• "Lessons Learned in the Implementation Phase of a

Large Ada Project," C. E. Brophy, S. Godfrey,

W. W. Agresti, and V. R. Basili, Proceedinas of the

Washinqton Ada Technical Conference, March 1988

• "Object-Oriented Programming in Smalltalk and Ada,"

E. Seidewitz, Proceedinas. 0f the 1987 Conference on

Obiect-Oriented Programming Systems, Lanauages and

Applications, October 1987

5207

4-1
EXPERIEHCES IN THE IMPLEHENTATION OF A LARGEAda PROJECT

Sally Godfrey

Code 552

Goddard Space Flight Center

Greenbe I t, Md. 20771

(30I) 286-3600

Carolyn Brophy

Department of Computer Science

University of Maryiand

College Park, Nd. 20742

(30I) 454-87II

BACKGROUND

During the past several years, the

Software Engineering Laboratory (SEL) of

Goddard Space Flight Center has been

conducting an experiment in Ada [6],[8] to

determine the cost effectiveness and

feasibility of using Ada to develop flight

dynamics software and to assess the effect

of Ada on the flight dynamics environment.

This experiment consists of near parallel

developments of a dynamics simulator in both

FORTRAN and Ada. A study team consisting of

members from the SEL has monitored

development progress and has collected data

on both projects throughout their

development.

Both the Ada and the FORTRAN teams

began work in January, 1985, using the same

set of requirements and specifications to

develop their simulators. The FORTRAN

dynamics simulator team completed acceptance

testing by June, 1987, after following a

development life cycle typical of projects

in the flight dynamics environment [5]. The

development was carried out on a DEC VAX11/780 and the completed FORTRAN dynamics

simulator consists of about 45,000 source

lines of code.

The Ada development began with a period

of training [7] in both the Ada language and

the methodologies appropriate for Ada [11].

The team was not previously experienced in

Ada, although they were more experienced

than the FORTRAN team in both the number of

years they had programmed (8.6 years

compared to 4.8 for the FORTRAN team) and

also in the number of languages they knew (7

compared to 3). The Ada team was also

experienced In more types of software

applications, but only 43% of the Ada team

had previous dynamics simulator experience

compared to 66% of the FORTRAN team.

Following the training period, the Ada

team began a phase of analyzing the

requirements and then they began design

using an object oriented methodology called

GOOD (General Object Oriented Design) which

was developed by the team during the

training and design phases. More

information on GOOD and the lessons learned

during the design phase can be found in [2],

[4], and [10].

Coding and unit t estlng began in :April,

i986, on a DEC VAX 8600 and continued

through June 1987. The Ada project has

completed system testing and consists _f

approximately 135,000 source lines of code .

This paper Will describe some of the

similarities and differences of the two

projects and will discuss some of the

interesting lessons learned during the

code/unit test and integration phases of

thls project.

INFORMATION COLLECTION

The information presented in this paper

was collected by using the following four

methods: i) Collection of SEL forms

2) Interviews 3) Observation of development

4) Code analysis. The SEL forms solicit such

information as a detailed breakdown of the

hours spent by programmers, managers, and

support staff on a project and detailed

information on changes and errors which

occurred during the development. During the

course of the project, over 2000 forms were

collected; about 625 of these documentederrors and changes.

I. A source line of code is defined to be

any 80 byte record of code including

commentary, blank lines and executable code.

m

r--

I

iI

mm

m

N

m

m

m

mll

III

j

m

m

m

m

I

5207

4-2 m

_m

m
Each member of the Ada team (11 total)

was interviewed individually to gain some

insight into the experiences he or she had

during implementation. Team members were

asked questions concerning ease or

difficulty of implementing features, unit

testing, integration, correcting errors,

using tools, etc. Questions concentrated on

an individual's particular area of work, but

general subjective questions were asked of

the entire team. Observation of the

development was accomplished by attending

reviews and regular implementation meetings

held by the team. These regular

implementation meetings were actual working

meetings in which team members discussed

progress, solved implementation problems,

clarified interfaces, shared knowledge, and

planned implementation strategies. In

addition, much information was gained

through informal conversations with the team

on Implementation progress. Information

received through code analysis was actually

collected two ways. First, the code was

examined to tabulate such attributes as

number of modules, number of lines of code,

number of comments, etc. Second, another Ada

team, in the process of Ada training,

performed code reading on parts of the

dynamics simulator code as a training

exercise and they provided their comments on

the code.

The remainder of this paper will

concentrate on some interesting comparisons

between the FORTRAN and the Ada projects and

some of the major lessons learned during the

implementation phase of the Ada project.

1. FORTRAN/Ada PROJECT COMPARISONS

Several factors need to be considered

when trying to directly compare metrics from

the FORTRAN project and those from the Ada

project. First, the FORTRAN project was

considered to be the "real" operational

version of the dynamics simulator being

developed, and as such, it was necessary for

that project to meet the schedules imposed

by an impending launch date. The Ada team,

on the other hand, was allowed a more

relaxed schedule for development which

included adequate training time, time to

experiment with design methodologies, and

finally, time to recode or enhance if

"better" methods occurred to the developers.

One result of this extra time was the

development of a much more sophisticated

user-interface for the Ada project.

Second, this general type of dynamics

simulator was a very well-known application

for the FORTRAN team since similar

simulators have been built repeatedly in

this environment. Thus, the general design

of the FORTRAN simulator was reused from

previous designs and was known to be a very

satisfactory design for the application. In

addition to the design, much of the code was.

reusable--about 36%. The Ada team developed

a new design [I] which they felt was more

suitable for Ada and which they felt more

accurately represented the actual physical'

system they were trying to simulate. While

this design may be a better physical

representation o6 the problem, it did not

have the advantage of previous use to refine

and correct any possible problems. No Ada"

code was available for reuse but several

FORTRAN routines were used by the Ada team.

These comprised only about 2% of the code.

Keeping in mind these differences in

the actual projects, we will discuss some

interesting FORTRAN/Ada comparisons.

I.I Size of Ada project is larger than

FORTRAN project.

As mentioned in the background section,

a simple count of the number of lines of

code, including every line of any type as a

line, yields a count of 135,000 source lines

of code for the Ada project and a count of

45,500 source lines of code for the FORTRAN

project. These figures are really a little

misleading, since the Ada llne count

includes 23,000 lines of blank lines which

are inserted for readability. Also, the Ada

count includes 49,000 lines of comments

compared to 19,500 lines of comments in the

FORTRAN count. When the number of executable

lines of code are compared, we find that the

Ada project has 63,000 lines of executable

code compared to 25,500 for the FORTRAN

project.

In these particular projects, there

were other reasons why the Ada project was

larger. As we mentioned earlier, the Ada

project was not constrained by schedule

pressure and so they developed a system with"

more functionality--a system with more of

the "nice to have, but not required"

features. Naturally this increased the size

of the system. To some extent, the Ada

language itself was a driving factor for the

size difference, since it requires more code

to write such constructs as package

specifications, declarations, etc. In

5207

4-3
addition, the Ada team used a style guide

[3] that required certain constructs to be

spread over several lines of code for

readability.

Another interesting way to compare the

size of the two projects is to examine the

size of the load modules For each one. This

also shows the Ada system to be largeroccupying 2300 512-byte blocks, compared to

953 512-byte blocks for the FORTRAN load

module.

1.2 Project cost is similar for the two

implementations.

One of the problems with trying to

compute productivity is tha_t there are

many ways to compute it. Usually, in the

Software Engineering Laboratory, the

calculation is made by taking the total

number of source lines of code developed and

dividing by the number of hours spent on the

project. The number of hours is carefully

recorded on forms weekly and includes the

hours spent on all phases of the project

beginning with requirements analysis and

ending with the completion of acceptance

testing. In order to compare the FORTRAN and

Ada projects, the calculations were made

using the number of hours spent on each

project from requirements anaT)_sis tO the

completion of system testing since

acceptance testing has not yet been

completed on the Ada system. As we see in

figure I, using the total number of source

lines of code (SLOC) for each project, we

get a productivity of 3.8 SLOC/hr. for the

FORTRAN project and a productivity of 6.1

SLOC/hr. for the Aria project. Rememberin(

that the Ada code included many blank linei

of code that were not included in th(

FORTRAN line count, We recompu_ed the Ad_

figure, excluding the blank lines and got

productivity of 5.2 SLOC/hr. When w(

considered the effort required. Just tc

develop new lines of code and not the

reusable code, the figures are 2.7 SLOC/hr.

for FORTRAN and 6.1 SLOC/hr. for Ada with

blanks and 5.0 SLOC/hr. without blanks. This

would seem to imply that Ada is more

productive, but we must remember that it

took many more lines of code to develop the

Ada system and that the style guide caused

many Ada constructs to be spread over

several lines.

Let's look at the figures when we

consider only executable lines of code.

Using only the number of lines of code which

are executable, we got a productivity figure

of 2.14 SLOC/hr. For the FORTRAN project and

2.8 SLOC/hr. for the Ada project. When we

considered that many of the Ada constructs

use more than one line, we looked at the

nuTnber of executable statements "(or

semicolons) in the Ada project and

recomputed productivity. Similarly For the

FORTRAN, we counted statements and their

continuations as one executable statement.

Now we get a productivity of 1.85 SLOC/hr.

for the FORTRAN project and .96 SLOC/hr. For

the Ada project. Looking at the number of

executable new statements in the FORTRAN

yields a Figure of 1.2 SLOC/hr. compared to

.95 SLOC/hr. for the Ada project. These

calculations would make FORTRAN look more

productive.

Lines Of Code Lines of Code

Used for Computation Productivity Used for Computation Productivity

Total lines of code 3.8 SLOC/hr Total lines of Code 6.17 SLOC/h¢"

Total lines of code Total lines of code

excluding blanks 3.8 SLOC/hr excluding blanks 5.12 SLOC/hr

Executable lines

of code 2.14 SLOC/hr

: Ada :

Executable lines

of code 2.8 SLOC/bx

New linesof code 2.7 SLOC/hr _New linesof code 6.08 SLOO/hr

New linesof code New linesof code

excludingblanks 2.7SLOC/hr excLudingblanks 5.03 SLOC/hr

Executable statements 1.85SLOC/hr Executable statements 0.96 SLOC/hr

Executable _new" Executable _new _

statements 1.2SLOC/hr statements 0.95 SLOC/bx

Figure 1: Productivity Comparisons

4-4

5207

I

I

mm

U

m

W

w

u

U

=_

u

L

j -
Perhaps a better way of viewing the

productivity problem is to examine it from

the standpoint of cost to produce the

product. The total cost of the FORTRAN

project from requirements analysis through

acceptance testing was about 8.5 man-years

of effort. The Ada project cost, using

actual figures from requirements analysis

through system testing and estimating the

acceptance testing cost, is around 12 manyears of effort. When we take into

consideration the percentage of reused code

in the FORTRAN project and assume all the

code generated was new code,it would have

taken about 11.5 man-years of effort to

develop the FORTRAN system. This makes the

cost of developing the two systems roughly

the same. especially when we consider that

the Ada project was a "first-time" project

and that the Ada project had slightly more

functionality than the FORTRAN.

1.3 Error types found in both projects

show similar profiles.

Detailed information was kept on the

types of errors found in both projects and

based on 104 forms collected for the FORTRAN

project and 174 forms collected for the Ada

project, the error types show a similar

profile. Figure 2 shows the distribution of

error types for each project.

Error l_Jpe" FORTRAN _ Ada c

% %

Computational 12 9

Initialization 15 16

Data Value or

Structure 24 28

Logic/Control

Structure 16 19

Internal Interface 29 22

External Interface 4 6

"There may be more than one error reported on • form.

s104 formJ

c174 forms

Figure 2: Error Profile

An example of a _omputational error

might be an error in a mathematical

expression. An error like using the wrong

variable would Eave been classified as data

value or structure error. Internal interface

errors refer to errors in module to module

communication, while external interface

errors refer to errors in module to external

communications.

Perhaps one result here that is

suprising is that the team expected to have

fewer internal interface errors with Ada,

but the percentage is not significantly

different from the FORTRAN. When the

detailed information on the Ada errors was

examined, we learned that many of the errors

classified as internal interface errors were

caused by a type change of some sort. For

example, a variable may have been classified

as one type in one portion of the code and

different type in another, or the original

type chosen for a variable might not have

been suitable. Another common reason that

internal interfaces were changed was that a

new function was added to the module which

required an interface change. Also, in some

cases, a developer would find he needed

another variable from some other module

which he did not originally think he needed.

1.4 The percentage of "very easy to

find" errors was less in the Ada project

than the FORTRAN project.

Detailed information was captured on

the effort required to isolate errors .The

error levels were categorized a) very easy

or less than one hour b) easy or one hour to

one day c) hard or one to three days

d) very hard or more than three days. The

FORTRAN team found that 81% of their error_"

were in the "very easy" to isolate category.

In comparison, the Ada team found only 59_,

of their errors in that category. There are

several possible explanations for this.

First, many of the errors found by th_

FORTRAN team were types of errors which

would have been identified by a mot;

rigorous compiler such as the Ada compiler

Throughout the project, the Ada team fel'.

that the compiler was one of the most usef_

tools because it was able to pinpoint man;,'

errors at the early stage of compilation.

Another possible explanation for the

difference in effort to locate errors is the

difference in experience of the teams with

the language. The Ada team was not

5207

4-5
experienced in Ada.and did not feel they had

the same intuition as the FORTRAN team did

to aid in isolating errors.

2. MAJOR LESSONS LEARNED DURING

INPLEHENTATION OF THE Ada PROJECT

2.1A flat structure usually has more

advantages than a nested structure. Thus,

nesting should be used sparingly.

The object oriented design used by the

team [9] seemed to promote a nested

structure for information hiding purposes.

While the nesting was not explicitly

specified in the design, it seemed to be a

natural manifestation of the object oriented

design--so the parts of.an object or a

package would be tncluded inside that

package instead of being called in from the

outside. The team felt that they were

implementing nesting conservatively, and

indeed, one view of the system shows that it

has 124 packages of which 55 are library

units. However, the nesting in the system

was extensive--many levels deep in some

places.

This amount of nesting caused many

problems for the Ada developers. First,

nesting increased the amount of

recompilation necessary during

implementation and testing. Many more units

• had to be recompiled when changes were made

to the system since Ada assumes dependencies

between nested obje_ or procedures even

when there are none. Since compilation is a

lengthy process, this slowed down the

development process. Much unneccessary

recompilation could have been avoided by the

use of more library units.

Second, nesting increased the difficulty

of unit testing. In fact, the greater the

level of nesting, the more difficult the

unit testing was. The lower level units were

not in the scope of the test driver, and a

debugger was necessary to "see" into these

lower level units. For the purposes of unit

testing in FORTRAN, a unit is defined as a

subprogram. When this same definition was

applied to the Ada, unit testing

difficulties arose since many of these units

could not be tested in isolation. Instead,

tt was necessary to integrate units_h_h

fit logically together, usually integrating

up to the package level, before testing was

done. Nesting also increased the difficulty

of tracing problems since tt ts'hard t

identify the calling module of a neste

unit.

2.2 A high degree of nesting was foun

to be an impediment for reuse.

Perhaps the major advantage of usin

library units instead of nested units I

that their use increases the potential o

reusability. When nesting is used, the siz

of the compilation units, the componen

sizes and the file sizes all tend to b

larger. Thus when these larger units ar,

examined for potential reuse, it is mucl

more likely that only a portion of the larg,

unit will actually have the code whicl

performs the needed funct)9 p for the net

system. Then it becomes necessary to unnesi

the code before reuse is possible. Thi:

unnesting is very labor intensive.

Another similar Acla project presentlb

under development in the SEL has examinee

this project's code for reuse and has fount

that it could use as much as 40% of th(

original code. However, it was necessary tc

unnest all of this c0de before reuse. This

use of library units would have enabled the

second project to reuse the code directly,

2.3 "Call-through" units are not an

efficient way to implement an objectoriented design.

"_al_-throughS" are procedures whose

only function is to call another routine.

These were used to group appropriate modules

exactly as they were represented in the

design so that a physical module of code was

created for every object in the design.

Thus, when objects were nested inside

objects, a "call-through" was us_i:l_o get to

the inner object. Implementation of "callthrough" units could be accomplished using

either nested or library units. This

practice resulted in additional code which

increased the system size and testing

complexity. This unneccessary code could

have been eliminated if some of the objects

in the design were left as logical objects,

rather than coding every object in the

design to preserve the exact design

structure.

II

lib

m

ml

i

m

m

m

BB

= .

Ill i

m

I

m

im

m

5207

4-6

m
2.4 An abstract data type analysis

should be incorporated into the design

process to control types.

Since the Ada team was not previously

experienced tn Ada, it took time to get

accustomed to the strong typing of Ada. The

tendency was to create too many types. A

type would be created with a strict range

for a particular portion of the application.

Then other areas of the application would

need a similar type, but the original one

would be too restrictive. So another type

was created, along with a corresponding set

of operations. Some of the difficulty with

this method of typing began to emerge during

critical design,--where-interface problems

developed due to typing differences.

Multiple types also increased the

difficulty of testing modules. Test drivers

needed to be larger to handle multiple types

and were often coded as large "case"

statements in order to provide a testing

capability for each type.

A recommendation for future Ada

developments is to incorporate an abstract

data type analysis into the design process

to control the generation of types. A more

general new type would be defined, then many

subtypes of that type could be used In

various sections of the application. This

type analysis would provide the following

advantages: 1) operations would be reused,

2) there would be fewer main types to

manage, and 3) families of types would be

developed that would inherit properties from

each other.

SUMMARY

In spite of a lack of experience in Ada

at the beginning of the project, the Ada

team was able to develop a very suitable

dynamics simulator In Ada which meets the

requirements originally developed for the

FORTRAN development effort. The overall cost

of the projects appears to be similar and

early indications of reuse potential in the

Ada project are very encouraging. Most of

the problems encountered by the Ada team are

surmountable. Many are either caused by a

lack of experience with Ada or an immaturity

of the tools. Both of these problems will be

resolved in time.

There are stlll many unanswered

questions to be considered on thls project--

for example, nothing at all has been

mentioned about maintainability, rellabllil

or performance. It is still too early t

look at these results on this project, but

research efforts are continuing on thi

project and several other Ada project in th

SEL. Hopefully, these efforts will provid

even more answers about the use Ada in th

future.

REFERENCES

]. Agresti, W., Church, V., Card, D., et

al. "Designing with Ada for Satellit

Simulation: A Case Study," Proceeding

of Ist Annual Symposium on Ad

Applications for NASA Space Station

Houston, Texas, June 1986.

2. Brophy, C. and Godfrey, S.,et. al

"Lessons Learned in the Implementatio:

Phase of a Large Ada Project,

Proceedings of the Washington Ad

Technical Conference, March 1988.

3. Goddard Space Flight Center Ada User':

Group. Ada Style Guide" (Version 1.1)

Goddard Space Flight Center document

SEL-87-002, June 1987.

4. Godfrey, S., and Brophy, C. Assessin(.

the Ada Design Process and It:

Implications: A Case Study, Goddar(

Space Flight Center document, SEL-87-

004, July 1987.

5. McGarry, F., Page, G., et. al.

Recommended Approach to Softwar(

Development, Goddard Space Flighl

Center document, SEL-81-205, April

1983.

6. McGarry, F., and Nelson, R. At.

Experiment with Ada-The GRO Dynamic.(

Simulator, Goddard Space Flight Center,

April 1985.

7. Murphy, R. and Stark, M. Ada Traininc

Evaluation and Recommendations, Goddard

Spoace Flight Center, October 1985.

8. Nelson, R. "NASA Ada Experiment--

Attitude Dynamics Simulator,"

Proceedings of Washington Ad_

Symposium, March, 1986.

5207

4-7
g. Seldewitz, E. and Stark, M. "Towards a

General Object Or|ented SOftware

Development Methodology," Proceedings of

Zst International Conference on Ada

Applications For the Space Station, June

1986. ..... ....

10. Seidewitz, E. and Stark, H. General

Object Oriented Software Development,

Goddard Space Flight Center document, SEL86-002, August 1986.

1]. Stark,- N. and Seidewitz, E. "Towards a

General Object Oriented Ada Ltfecycle,"

Proceedings of Joint Conference on Ada

Tech/Washington Ada Symposium, Harch 1986.

Bill

= =

III

D

m

J

I

_I

m

III

m

m

Ill

M

m

m

BI

m

m

5207

4-8

g
GENERAL OBJECT-ORIENTED SOFTWARE DEVELOPMENT WITH ADA: A LIFE CYCLE APPROACH

CASE Technology Conference

April 1988

Ed Seidewitz

Code 554 / Flight Dynamics Analysis Branch

Goddard Space Flight Center

Greenbelt MD 20771

(301) 286-7631

w

Abstract

The effective use of Ada requires the adoption of

modern software-engineering techniques such as

object-oriented methodologies. A Goddard Space

Flight Center Software Engineering Laboratory Ada

pilot project has provided an opportunity for studying

object-oriented design in Ada. The project involves

the development of a simulation system in Ada in

parallel with a similar FORTRAN development. As

part of the project, the Ada development team

trained and evaluated object-oriented and processoriented design methodologies for Ada.

In object-oriented software engineering, the software

developer attempts to model entities in the problem

domain and how they interact. Most previous work

on object-oriented methods has concentrated on using

object-oriented ideas in software design and

implementation. However, we have also found that

object-oriented concepts can be used advantageously

throughout the entire Ada software life-cycle. This

paper provides a distillation of our experiences with

object-oriented software development. It considers

the use of entity-relationship and process/data-flow

techniques for an object-oriented specification which

leads smoothly into our design and implementation

methods, as well as an object-oriented approach to

reusability in Ada.

1. Introduction

Increased productivity and reliability from using Ada

must come from innovative application of the nontraditional features of the language. However, past

experience has shown that traditional development

methodologies result in Ada systems that "look like a

FORTRAN design" (see, for example, [Basili 85]).

Object-oriented techniques provide an alternative

approach to effective use of Ada. . As the name

indicates, the primary modules of an object-oriented

design are objects rather than traditional functional

procedures. Whereas a procedure models an action,

an object models some entity in the problem domain,

encapsulating both data about that entity and

operations on that data. Ada is especially suited to

this type of design because its package facility

directly supports the construction of objects.

The Goddard Space Flight Center Software.

Engineering Laboratory is currently involved in an

Ada pilot project to develop a system of about 60,000

lines (20,000 statements) [Nelson 86, McGarry 88].

This project has provided an opportunity to explore

object-oriented software development methods for

Ada. The pilot system, known as "GRODY", is an

attitude dynamics simulator for the Gamma Ray

Observatory (GRO) spacecraft and is based on the

same requirements as a FORTRAN system being

developed in parallel.

The GRODY team was initially trained both in the

Ada language and in Ada-oriented design

methodologies. The team specifically studied the

methodology promoted by Grady Booch [Booch 83] TM and the PAMELA methodology of George Cherry

[Cherry 85]. Following this, during a training

exercise, the team also began synthesizing a more

general approach to object-oriented design. At an

early stage of the GRODY development effort, the

team produced high-level designs for GRODY using

each of these methodologies. Section 2 summarizes

the comparison of methodologies made by the

GRODY team.

PAMELA is a registered trademark of George W. Cherry.

5207

4-9
General Object-Oriented

Unfortunately, the system requirements given to our

team were highly biased by past FORTRAN designs

and implementations of similar systems. Therefore

we began by recasting the requirements in a more

language-independent way using the "Composite

Specification Model = [Agresti 84, Agresti 87]. This

method involves the use of state transition and entityrelationship techniques as well as more traditional

data flow diagrams. We then designed the system to

meet this specification, using object-oriented

principles. The resulting design is, we believe, an

improvement over the previous FORTRAN designs

[Agresti 86]. The system is currently in final system

testing.

Previous work by the present authors has

concentrated on using object-oriented ideas in

software design and implementation. This work

resulted in a design method which synthesizes the best

methods studied during the GRODY project

[Seidewitz 86a, Seidewitz 86b]. However, we have

found that object-oriented concepts can be used

advantageously throughout the entire Ada software

life-cycle [Stark 87]. Section 3 provides a distillation

of our experience with GRODY and other Ada

projects into an evolving life-cycle methodology.

2. Comparison of Methodologies

This section presents a comparison of design

approaches to the GRO dynamics simulator, including

the traditional functional approach usedf0r the

FORTRAN version, the Booch methodology,

PAMELA and the general methodology developed by

the team itself. It should be noted that the GRODY

team was trained in the Booch and PAMELA

methodologies in early 1985. Since then, both

methodologies have evolved considerably, in many

cases addressing in different ways the very issues that

led us to develop our methodology. Nevertheless, as

background motivation for tlae direction taken by the

GRODY team, the comparison in this section is in

terms of the 1985 versions of the methodologies.

Li F_netional Desiun

The design of the FORTRAN version of the

simulator is functionally-oriented. This de s!g_n_has a

strong heritage in previous simulator and ground

support systems. It consists of three major subsystems

which interact as shown in figure 1. The "TRUTH

MODEL" subsystem includes models of the spacecraft

Software Development with Ada

hardware, the external environment and the attitude

dynamics; that is, the "real world" as opposed to the

spacecraft control system. The SIMULATION

CONTROL subsystem alternatively activates the

SPACECRAFT CONTROL and TRUTH MODEL

subsystems in a cyclic fashion. Each subsystem

consists of a single driver subroutine which calls on a

hierarchy of lower-level subroutines to perform the

functions of the subsystem when activated by

SIMULATION CONTROL. Data flow between

subsystems, as well as system parameterization, is

entirely though a set of global COMMON areas.

f ]

SIMULATION

CONTROL

FIGURE 1 FORTRAN Simulator Functional Desig_

The strengths of this functional design lay in its

relatively simple structure and direct implementation

in FORTRAN. However, its main drawback is the

complete lack of encapsulation of global data. The

only restrictions on which code may access which

global data are enforced by programmer discipline.

This can lead, intentionally or not, to illicit

corruption of global data by code in one part of the

system which is unexPeCted: by another part of the

system. Further, most simulation parameters are

hard-coded into the global common area, making the

user interface for the system hard to modify and

impossible to generalize.

5207

4-10

w

m

m

m

m

I

mlm

I

l

m

m

lid

m

u

J

m

m

m

g

I

I
General Object-Oriented Software Development with Ada

7

w

2_2 Booth's Methodology

Grady Booch is, perhaps, the most influential

advocate of object-oriented design in the Ada

community [Booth 86b, Booth 87]. As learned by the

GRODY team, Booth's methodology derives a design

from a textual specification or informal design

[Booch 83], an approach adopted from Abbott

[Abbott 83]. The technique is to underline all the

nouns and verbs in the specification. The objects in

the design derive from the nouns; object operations

derive from the verbs. Obviously, some judgment

must be used to disregard irrelevant nouns and verbs

and to translate the remainingconcepts into design

objects. Once the objects have been identified, the

design can then be represented diagrammatically

using a notation which shows the dependencies

between Ada packages and tasks which implement the

objects. Figure 2 shows such a diagrammatic toplevel design for GRODY.

¢

wN

FIGURE 2 Object-Oriented Simulator Design

( Booch Methodology)

The Booch design methodology contains all the basic

framework of the object-oriented approach.

However, application of this methodology to GRODY

indicated that it was not readily applicable to sizable

systems. The team found the graphical notation clear

but not detailed or rigorous enough. Further, Booch

gives no explicit method for diagramming a

hierarchical decomposition of objects, which is

needed for any sizable system. Booth's notation does

not, therefore, seem to be a complete design notation.

Note, however, that in more recent work Booth has

extended the scope of the notation to address some of

these shortcomings [Booth 87].

A second difficulty of Booth's methodology is in the

technique for deriving the design from the

specification text. This works well when the

specification can be written concisely in a few

paragraphs. However, when the system requirements

are large, as with GRODY, this can be difficult. In

addition, any attempt to use such a technique directly

on a requirements document such as ours is doomed

to failure due to the sheer size and complexity of the

document. Realizing such drawbacks, Booth no

longer advocates the use of this textual method,

which was never actually intended for large systems

development [Booth 86b]. Instead, he derives an

object-oriented design from a data flow diagram

based specification [Booch g6a, Booch 87]. However,

from the published examples it is still unclear how to

systematically apply this method to realistic systems.

2.3 PAMELA

The second methodology considered by the GRODY

team was the Process Abstraction Method for

Embedded Large Applications (PAMELA) developed

by George Cherry [Cherry 85, Cherry 86]. PAMELA

is oriented toward real-time and embedded systems.

PAMELA is process-oriented, so a PAMELA design

consists of a set of interacting concurrent processes.

A well designed process is effectively a concurrent

object, thus PAMELA is object-oriented in a general

way.

PAMEEA uses a powerful graphical notation wiihout

many of the drawbacks found in Booch's notation

[Cherry 86]. During the PAMELA design processes,

the designer successively decomposes processes into

concurrent subprocesses until he reaches the level of

primitive single-thread processes. The GRODY team

found that PAMELA provides fairly explicit

heuristics for constructing good processes. The

designer uses these hints to construct the top-level

processes from the system specification. The designer

then recursively decomposes each non-primitive

processes until only primitive processes remain. The

primitive processes can then be coded as Ada tasks

with a single thread of control. Non-primitive

processes are simply packages of lower level processes

and thus contain multiple threads of control. Figure

3 shows the top levels of a PAMELA design for

GRODY.

5207

4-11
ORIGINAL PAGE IS

OF POOR QUALITY

General Object-Oriented Software Development with Ada

update of PAMELA known as "PAMELA 2" which is

now explicitly object-oriented [Cherry 88]. In fact,

PAMELA now stands for "Pictorial Ada Method for

Every :Larg_e - Ai_plication." It is stiii to early,

however, to evaluate the generality o£ PAMELA 2 as

an object-oriented methodology.

2.3 General 0biect-0riented Development

As a result of the above experiences, the GRODY

team developed its own object-oriented methodology

which attempts to capture the best points of the

object-oriented approaches studied by the team as

well as traditional structured methodologies

[Seidewitz 86a, Seidewitz g6b, Stark 87]. It is

designed to be quite general, giving the designer the

flexibility to explore design alternatives easily. It is

also based on principles that guide the designer in

constructing good object-oriented designs. This

methodology was used to develop the complete

detailed design for GRODY.

FIGURE 3 PAMELA Simulator Design

PAMELA's heuristics can be very effective when

designing a real-time system that is heavily driven by

external asynchronous actions, in Other cases,

however, they require considerable interpretation to

be applicable. Al.though parts of GRODY might

conceptually be concurrent (because GRODY

simulates actions that happen in parallel in the real

world), there is no requirement for concurrency in

the simulation of these actions because GRODY does

not have to interface with any active external entity

(except the user). In addition, since GRODY runs on

a sequential machine, the overhead of Ada tasking

and rendezvous could greatly degrade the time

performance of the system. Thus, one interpretation

of PAMELA's principles might leave very large

sections of GRODY as primitive single-thread

processes, with only a few concurrent objects in the

entire design. -To proceed further in the

decomposition, the designer has to rely more on

intuition about what makes a good object and rely

This general object-oriented development ("GOOD").

methodology is based on general principles of

abstraction, information hiding and design hierarchy

discussed in the next section. These principles are

less explicit thanBboch's methodology or PAMELA,

but they do provide a firm paradigm for generating

and evaluating an object-oriented design. Indeed, as

mentione_:abdve, the team £dund _fhe Booch and

PAMELA _ design:construCtion techniques restrictive,

often necessitating the designer to rely on intuition

for object-oriented design. The GOOD methodology

is an attempt to codify this intuition into a basic set

of principles that provide guidance while leaving the

designer the flexibility to explore various design

approaches.

In addition, we have also considered, independently

of Booth, the transition from structured analysis

[DeMarco 79] to object-oriented design in the context

of the GO_ methodology, °developing a technique

known as abstraction analysis [Seidewitz 86a,

Seidewitz 86b]. This technique is analogous to

less on the methodology.

In fact, at the time that the GRODY team was using

PAMELA, it provided no support for the

decomposition and design of anythin_g below the level

of the primitive process, an Ada task [Cherry 85].

Since then, Cherry has added several concepts to the

methodology, including the use of abstract data types

[Cherry 861.- Recently he has introduced a major

transform and transaction analysis used in structured

design [Yourdon 78]. However, proceeding into

object-oriented design from a structured analysis, by

whatever means, requires an "extraction" of problem

domain entities from traditional data flow diagrams.

From an object-oriented Viewpoint, it seems

appropriate to instead begin a specification effort by

identifying the entities in a problem domain and their

interrelationships. Study is continuing on including

4

5207

4-12

m

=_

mm

i

m

mm

i

M

l

mm

I

i

m

m

!

I

w

m

I

I

I
ORIGINAL PAGE i5

OF POOR QUALITY

General Object-Oriented Software Development with Ada

w

such object-oriented system specification techniques

in the GOOD methodology and on applying objectoriented principles throughout the Ada life cycle

[Stark 87]. Section 3 will discuss this in more detail.

Figure 4 shows the actual design of the main part of

GRODY. The object diagram notation

[Seidewitz 86b] used in figure 4 shows the

dependencies between the various objects which make

up a system design, in a manner similar to Beech's

diagrams. However, the object diagram notation also

explicitly includes the idea of leveled composition of

objects, like the PAMELA process graph notation.

Moreover, as will be discussed in' more detail in

section 3, the designer may use object diagrams to

express the design from the highest levels all the way

down to the procedural level. (This capability has

also been added to PAMELA 2 [Cherry 88].)

Since GRODY was derived from the same basic

requirements as the FORTRAN design, there are

similarities in the designs of the two systems.

However, there are also some fundamental differences

in the GRODY design that can be traced to the

object-oriented methodology. For example, in

GRODY the TRUTH MODEL is effectively passive,

with the SPACECRAFT CONTROL calling on

operations as needed to obtain sensor data and

activate actuators. All sensor and command data is

passed using these operations. This design approach

was encouraged by viewing the TRUTH MODEL as

an object with multiple operations rather than as a

functional subsystem with a single driver.

The simulation timing of GRODY is also different

from the FORTRAN design. The object-oriented

methodology led to consideration of a "TIMER"

object in GRODY which provides an abstraction of

the simulation time. This utility object provides a

common time reference for the SPACECRAFT

CONTROL and TRUTH MODEL separate from the

SIMULATION CONTROL loop. Unlike the

FORTRAN design, in GRODY the "cycle times" of

the SPACECRAFT CONTROL and TRUTH MODEL

are not the same. The GRODY team chose to

faithfully model, in the SPACECRAFT CONTROL

abstraction, the timing of the actual spacecraft control

software, which is not under user control. However,

GRODY allows the simulation user to set the cycIe

time for the TRUTH MODEL over a fairly wide

range, to allow the user to trade-off speed and

accuracy as desired.

f---q

SIMULATION

CONTROl.

FIGURE 4 Object-Oriented Simulator Design

(GOOD Methodology)

Finally, the PARAMETER DATABASE and

GROUND COMMAND DATABASE objects

encapsulate user settable parameters for the

simulation. Similar data is contained in COMMON

blocks in the FORTRAN design. This encapsulation

of "global" data is typical of object-oriented designs.

It provides both increased protection of the data

encapsulated and increased opportunity for reuse. For

example, the simulation parameters in the FORTRAN

design are COMMON block parameters which must

be hard-coded into the user interface code. (For

simplicity the user interface modules have 'not been

included in figure 4.) In the GRODY des'ign,

simulation parameters are identified by enumeration

constants, which allows the user interface displays to

be parameterized by external data files. This should

greatly increase the reusability of the user interface.

The differences discussed above could probably have

been incorporated into the FORTRAN design.

However, it was largely the influence of the objectoriented approach which lead to their consideration

for GRODY when they had not been considered in

several previous designs of simulators for FORTRAN.

Considerations of encapsulation and reusability

indicate that the GRODY design may be "better" than

the FORTRAN design. This is, of course, the goal of

object-oriented methods. However, the true test of

the merits of the GRODY design will only come from

continuing studies of the comparative maintainability

of the FORTRAN and Ada simulators.

5207

4-13
General Object-Oriented Software Development with Ada

In terms of the methodology itself, the team found

the object diagram notation extremely useful for

discussing the design during developmenL Further,

the notation provided complete documentation of the

design and was tailored specifically towards Ada. This

made the transition to coding very smooth, and

allowed the documentation to be readily updated as

coding proceeded. By the end of coding, there were

no major changes in the design and most changes that

did occur were additions rather than alterations.

The object diagram notation evolved considerably

during the GRODY project in response to continuing

experience with its use. The lack of a specific

methodology at the start of the GRODY project was a

problem for the team, as was the continuing evolution

of the methodology over the duration of the project.

Further, the fact that managers were not familiar

with the new methodology made the use of object

diagrams difficult at reviews. Another problem was

that the detail of the object diagrams and the

emphasis on keeping the documentation up-to-date

required a great deal of effort to maintain a rather

large design notebook. The team clearly saw the great

need for automated tools to support the methodology

in this area. Consideration has also been given to

extend the object diagram notation to better cover

such topics as generics, abstract data types and large

system components.

3. The GOOD Methodology

Section 2 described the background motivation of the

GRODY team in developing the GOOD methodology

and applying it to the full GRODY design. The

experience with the Composite Specification Model

and object-oriented design on GRODY, as well as

experience on other Ada projects, has led to the

continuing evolution of a comprehensive, integrated,

object-oriented approach to software development,

encompassing all phases of the software life cycle.

This section provides an overview of the current

GOOD life cycle approach.

3.1 Entities and Relationshivs

The modules of an object-oriented design are

intended to primarily represent problem domain

entities. From an object-oriented viewpoint, it seems

appropriate to begin a software specification effort by

identifying the entities in a problem domain and their

interrelationships. Entity-relationships and data fl0w

techniques can then complement each other, the

former delineating the static structure problem

domain and the latter defining the dynamic function

of a system.--'i_is is similar to the "contextual" and

"functional" views of the Composite Specification

Model [Agresti 84, Agresti 87]. A close relation to the

specification approach discussed here is described in

some detail in [Bailin 88].

An entity is some individual item of interest in the

problem domain. For example, consider the

specification, of GRODY. Several problem domain

entities immediately come to mind: the spacecraft

structure, sensors and thrusters on the spacecraft, the

environment, etc. An entity is described in terms of

the relationships into which it enters other objects. A

spacecraft might be in a certain orientation, have

certain thrusters; etc. Entities can also have

attributes, such as spacecraft mass, which are data

items describing the intrinsic properties of the entity.

To model the structure of the problem domain

requires the identification of entity types which are

groups of entities with the same types of attributes

and relationships. For example, we may define a

SPACECRAFT STRUCTURE e_ntity type with

SPACEC/_AFT MASS and DRAG COEFFICIENT

attributes. All SPACECRAFT STRUCTURE entities

have these attributes, but different individual entities

have different specific values for the attributes.

A problem domain model must also include a

specification of all possible relationships between

various types of entities. These relationships may

themselves have attributes and enter into other

relationships. For example, the ATTITUDE STATE

of a spacecraft describes its current orientation

relative to inertial space and its current rotational

motion. The ATTITUDE STATE is effectively a

relationship between the spacecraft, the environment

and the effect of any thruster firings used to reorient

the spacecraft. This relationship has such attributes

as the current spacecraft orientation and the

spacecraft angular rotation rates.

The entity-relationship diagram (ERD) is a common

graphical tool for entity-oriented specification

[Chert 76]. Figure 5 shows an ERD for the GRODY

prob_lem domain, oThe notatio n_for this diagram is

based on [Ward 85]. Complex relationships such as

ATTITUDE STATE are shown as associative entities

on ERDs such as figure 5. Associative entities can be

identified on an ERD by being .connected to a

5207

4-14

i

m

llm

[]

ram"

II

m

m

m

i

I

l

l

m

I

i

I

m

m

m

m

U

I

I
ORIGINAL PAGE IS

OF POOR QUALITY

General Object-Oriented Software Development with Ada

m

w

relationship symbol by an arrow. Associative entities

are "objectivizations" of relationships which may have

attributes and enter into other relationships.

SENSORS CAUII MA_nON

pARAII ETIUm

•..omr.F7 .o.o jy • ALIamlEIMT • a_Vlff_ C_ST_T

j S,P4¢ECmlFT W_Sll

ASSOCIATlYE _ , OMAG CoF.._ll_

ENTITY

• AT'r RIll UTE

FIGURE 5 Attitude Dynamics Entity-Relationship

Diagram

Figure 5 shows only a small part of the example

problem domain. It would grow as additional entities

and relationships are added to describe additional

parts of the problem domain. As the specification

grows, a complete ERD can quickly become

cumbersome. It is possible to "level" ERDS showing

complex entities on high-level diagrams which enter

into composite relationships. These are then broken

down in lower-level diagrams. An extended data

dictionary notation is also useful as a textual

representation of entity type and relationship

definitions. In addition, the data dictionary provides

a common basis for data definition between the static

and the dynamic views of the problem domain.

3,2 Processes and Data Flow

ERDs show all possible relationships between

different types of entities. They do not show the

actual relationships between specific entities at

specific points in time, nor how these actual

relationships change over time. Data flow techniques,

however, provide exactly this dynamic view.

Traditional data flow diagrams (DFDs) show the flow

of data between functional transformations. We will,

instead, diagram the flow of data between processes

which represent the dynamic view of one or. more

entities in the problem domain. A process is

effectively a state machine which accepts input

stimuli, reacts to it and produces output stimuli,

possibly modifying some internal state data. It has no

"operations" as such, only stimuli and responses.

These stimuli may be either in the form of data flow

or pure control signals.

To construct a dynamics data flow model, one needs

to identify those active entities which have associated

processes. For each relationship in the static entityrelationship model, we choose one of the related

entity types to be active. This entity type has an

associated process which is charged with maintaining

the state of the relationship in response to internal

and external stimuli. Note that an entity type may be

active relative to one relationship and passive relative

to another, and that associative entities may be active.

or passive.

For example, consider a simplified attitude dynamics

simulation system similar to GRODY. The attitude of .

a spacecraft is its orientation relative to inertial space,

and an attitude dynamics simulator models the

rotational motion of the spacecraft in response to

external disturbances and the spacecraft control

system. Figure 5 describes the problem domain for

such a system. The active entities in this case interact

in a control loop outlined in figure 6. All the

processes shown on figure 6 are associated with active

entities on figure 5. A data item flowing on a

diagram such as figure 6 may be a passive entity, an

attribute or any other composite data item or data

element defined in the data dictionary.

The dynamic model must also provide a specification

for each individual process. This specification should

include a textual description of the object as well as a

listing of all inputs and outputs. The process

specification also provides a place to include "nonfunctio.nal" requirements such as timing and accuracy

constraints. However, the main point of a process

specification is to detail the function of the process.

This can be in the form of structured English, a state

transition diagram or some other appropriate notation,

such as differential equations for the time evolution

of the spacecraft attitude.

5207

4-15
General Object-Oriented Software Development with Ada

f---G SPACECRAFT

ENVIRONMENT

t___./ CONTROL

LEGEND

FIGURE 6 Attitude Dynamics Data Flow Diagram

The function of a process can also be given by a

lower=level data flow diagram. Decomposition can

continue recursively on all diagrams until all processes

have been decomposed into primitive functions and

states. This results in a leveling similar to the

leveling of traditional DFDs. However, unlike DFDs,

each object at each level of a process-data-flow

diagram specification has a complete process

specification. Each process must also be associated a

reasonable problem domain entity independently of

its decomposition.

3.3 Object Identification

The intent of an object is to represent a problem

domain entity and any associated process. The

concept of abstraction deals with how an object

presents this representation to other objects

[Beech 86b, Dijkstra 68]. Ideally, the objects in a

design should directly reflect the problem domain

entities identified during system specification.

However, various design considerations may require

splitting or grouping of objects and there will almost

always be additional objects in a design to handle

"executive" and "utility" functions. Thus there is a

spectrum of levels of abstraction of objects in a

design, from objects which closely model problem

domain entities to objects which really have no reason

for existence [Seidewitz 86b]. The following are some

points in this scale, from strongest to weakest:

Entity Abstraction - An object represents a useful

model of a problem domain entity or class of entities.

: : :+_ 7 -= .......

Action AbstractiOn An object provides a

generalized set of operations which all perform

similar or related functions (this is similar to the idea

of a "utility" object in [Beech 87]).

Subsystem Abstraction - An object groups together a

set of objects and operations which are all related to a

specific part of a larger system (this is similar to the

"subsystem" concept in [Beech 87]).

The stronger the abstraction of an object, the more

details aid Sfi-pp_6ssed by the abstract concept. The

principle of information hiding states that such details

should be kept secret from other objects [Beech 87,

Parnas 79], so as to better preserve the abstraction

modeled by the object.

3.4 Design Hierarchies

The principles of abstraction and information hiding

provide the main guides for creating *good" objects.

These objects must then be connected together to

form an object-oriented design. This design is

represented using the graphical object diagram

notation [Seidewitz 86b].

The construction of an object-diagram-based design

is mediated by consideration of two orthogonat

hierarchies in software system designs [Rajlich 85].

The composition hierarchy deals with the composition

of larger objects from smaller component objects. The

seniority hierarchy deals with the organization of a set

of objects into "layers". Each layer defines a virtual

language extension which provides services to senior

layers [Dijkstra 68]. A major strength of object

diagrams is that they can distinctly represent these

hierarchies.

The composition hierarchy is directly expressed by

leveling object diagrams (see figure 7). At its top

level, any complete system may be represented by a

single object which interacts with external objects.

Beginning at this system level, each object can then

be refined into component objects on a lower-level

object diagram, designed to meet the specification for

the object. The result is a leveled set of object

diagrams which completely describe the structure of a

system. At the lowest level, objects are completely

decomposed into primitive objects such as procedures,

tasks and internal state data stores. At higher levels,

5207

4-16

I

= z

N

.-.i

t:zm

ii

I

I

I

i

U

ill

mm 7

l

.4

D

l

I =

I

m

I
General Object-Oriented Software Development with Ada

n

w

I

object diagram leveling can be used in a manner

similar to Booch's "subsystems" [Booch 87].

COMPONE i

FIGURE 7 Composition Hierarchy

The seniority" hierarchy is expressed by the topology

of connections on a single object diagram (see figure

8). An arrow between objects indicates that one

object calls one or more of the operations provided by

another object. Any layer in a seniority hierarchy

can call on any operation in junior layers, but never

any operation in a senior layer. Thus, all cyclic

relationships between objects must be contained

within a virtual language layer. Object diagrams are

drawn with the seniority hierarchy shown vertically.

Each senior object can be designed as if the

operations provided by junior laye_ were "primitive

operations" in an extended language. Each virtual

language layer will generally contain several objects,

each designed according to the principles of

abstraction and information hiding.

3.5 System Design

The main advantage of a seniority hierarchy is that it

reduces the coupling between objects. This is because

all objects in one virtual language layer need to know

nothing about senior layers. Further, the

centralization of the procedural and data flow control

in senior objects can make a system easier to

understand and modify.

iiii

2

FIGURE 8 Seniority Hierarchy

However, this very centralization can cause a messy

bottleneck. In such cases, the complexity of senior

levels can be traded off against the coupling of junior

levels. The important point is that the strength of the

seniority hierarchy in a design can be chosen from a

spectrum of possibilities, with the best design

generally lying between the extremes. This gives the

designer great power and flexibility in adapting

system designs to specific applications.

Figure 9 shows one possible preliminary design for

the ATTITUDE SIMULATOR. For simplicity, the

sensors and thrusters are represented by a single

"SPACECRAFT HARDWARE" object in figure 9.

Note that, by convention, the arrow labeled "RUN" is

the initial invocation of the entire system. In

preliminary design diagrams such as figure 4, it is

sometimes convenient to show what data flows along

certain control arrows, much in the manner of

structure charts [Yourdon 78] or "Buhr charts"

[Buhr 84]. These annotation.s will not appear on the

final object diagrams.

In figure 9, the junior level components do not

interact directly. All data flow between junior level

objects must pass through the senior object, though

each object still receives and produces all necessary

data (for simplicity not all data flow is shown in

figure 9). This design is somewhat like an objectoriented version of the structured designs of ¥ourdon

and Constantine [Yourdon 78].

5207

4-17
ORIGINAL PAGE fS

OF POOR QUALITY

General Object-Oriented Software Development with Ada

RUN

p

LEG_O

OBJECT O

DATA FLOW

CONTROL FLOW

We can even remove the senior object completely by

distributing control among the junior level objects

(see figure 11). The splitting of the RUN control

arrow in figure 11 means that the three objects are

activated simultaneously and that they run

concurrently. The seniority hierarchy has collapsed,

leaving a homologous or non-hierarchical design

[Yourdon 78] (no seniority hie-archy, that is; the

composition hierarchy still remains).

A design which is decentralized like figure 11 at all

composition levels isv--cry simi-lar to what would be

produced by the PAMELA methodology [Cherry 86].

In fact, it should be possible to apply PAMELA

design criteria to the upper levels of an object

diagram based design of a h]ghly ¢0neurrent system.

All concurrent objects would then be composed, at a

certain level, of objects representing certain process

"idioms" [Cherry _6]. Below this level concurrency

would generally no longer be advantageous.

1

m

I

1

U

i

m

1

FIGURE 9 Centralized Design

We can remove the data flow control from the senior

object and let the junior objects pass data directly

between themselves, using operations within the

virtual language layer (see figure 10). The senior

object has been reduced to simply activating various

operations in the virtual machine layer, with very

little data flow.

RESUV_J

SIMULATION _

CONTROL

l ]

ATTITUDE m' _ _,

I l- ':_-'-_"i_I l" a'--'--'-'_ L I

ATTITUDE _ SENSOR

STATE DATA I

aRou.otl+I

FIGURE 10 Design with Decentralized Data Flow

RUN

STATE

I ATTITUDE

STATE

, _'IRUSTER 1 _n4RUSTER l

TORQUE /_ COMMAND

/-"_ I 1.4-------0 I I

UDE _ SPACECRAFT" P,PACECRAFT

kllCSl_ HARDWARE ,I CONTROL

i- o_.---,_ i l- o-----_ | /

ATTITUDE _ SENSOR _-

DATA

TELEMETHY I

GROU, D I

C OMM_ O

10

FIGURE 11 Decentralized Design

To complete the design, we need toadd a virtual

language layer of utility objects which preserve the

level of abstraction of the problem domain entities. In

the case of the ATTITUDE SIMULATOR these

objects might include VECTOR, MATRIX,

GROUND COMMAND and simulation

PARAMETER types, Figure 12 shows how these

objects might be added to the simulator design of

Figure I0.

i

I

i

mm

i

m -

1

!

m

m

5207

4-18 i

i :
---. _.

OF"POOR QUALITY

General Object-Oriented Software Development with Ada

Figure 12 gives one complete level of the design of

the ATTITUDE SIMULATOR. Note that figure 12

does not include the data flow arrows used in earlier

figures. When there are several control paths on a

complicated object diagram, it rapidly becomes

cumbersome to show data flows. Instead, object

descriptions for each object on a diagram provide

details of the data flow.

An object description includes a list of all operations

provided by an object and, for each arrow leaving the

object, a list of operations used from another object.

We can identify the operations provided and used by

each object in terms of the specified data flow and

the designed control flow. The object description can

be produced by matching data flows to operations.

For example, the description for the ATTITUDE

DYNAMICS object in, figure 12 might be:

Provides:

procedure Initialize;

procedure Integrate (For Duration: In DURATION);

procedure Apply (Torque: In VECTOR);

function Current_Attitude return ATTITUDE;

function CurrentAngular__Velocity

return VECTOR;

Uses:

5.0 LINEAR ALGEBRA

Add (Vector)

Dot

Multiply (Scalar)

Multiply (Matrix)

6.0 PARAMETER DATABASE

Get

We could next proceed to refine the objects used in

figure 12 and recursively Construct lower level object

diagrams. These lower level designs must meet the

functionality of the system specification and provide

the operations listed in the object description. The

design process continues recursively until the entire

system is designed and all objects are completely

decomposed.

The GRODY design of figure 4 is basically the same

as the example design of figure 12. However, the

GRODY team chose to simplify the design by

combining the ATTITUDE DYNAMICS and

SPACECRAFT HARDWARE objects into a single

TRUTH MODEL subsystem object, similar to the

corresponding subsystem in the FORTRAN design.

Further, in GRODY, the LINEAR ALGEBRA

functions are part of a UTILITIES module not shown

in figure 4.

$1MULA110N

CONTROt D

_1ALQEBRA I DATABASE CG_

FIGURE 12 Attitude Dynamics Simulator Design

3.5 lmolementation

The transition from an object diagram to Ada is

straightforward. Package specifications are derived

from the list of operations provided by an object. For

the ATTITUDE DYNAMICS object the package

specification is:

package AttitudeDynamics is

subtype ATTITUDE is Linear Algebra.MATRIX;

procedure Initialize;

procedure Integrate

( For Duration : in DURATION );

procedure. Apply

( Torque : in Linear Algebra.VECTOR );

function Current Attitude

return ATTITUDE;

function CurrentAngular_Velocity

return Linear Algebra.VECTOR;

end Dynamics;

11

4-19

5207
General Object=Oriented Software Development with Ada

The package specifications derived from the top level

object diagram can either be made library units or

placed in the declarative part of the top level Ada

procedure. For lower level object ctiagrams the

mapping is similar, with component package

specifications being nested in the package body of the

composite object. States are mapped into package

body variables. This direct mapping produces a highly

nested program structure. Alternatively, some or all

of these packages can be made library units or even

reused from an existing library. However, this may

require additional packages to contain data types and

state variables used by two or more library units.

Nevertheless, experience has shown that, to promote

reusability and reduce the compilation burden, it is

best to avoid nesting of code [Godfrey 87], though it

is important to retain leveling in the design.

The process of transforming object diagrams to Ada

is followed down all the object diagram levels until

we reach the level of implementing individual

subprograms. Low-level subprograms can be designed

aoff:implemented_:_us1=_ng ` tradit]Oh-ffl ° functional

techniques. They should generally be coded as

subunits, rather than being embedded in package

bodies.

The clear definition of abstract interfaces in an

object-oriented design can also greatly simplify

testing. When testing an object, there is a well

defined "virtual language" of operations it requires

from objects at a junior level of abstraction, some of

which may be stubbed-out for initial testing. Further,

object-oriented composition encourages incremental

integration testing, since the "unit testing" of a

composite object really consists of "integration

testing" the component objects at a lower level of

abstraction.

3.7 Reuse

The concept of generic objects provides a powerfui

tool for reusability. Generic parameters may be used

to cut the dependencies of a general object on other

specific objects, allowing the general object to be

reused in similar but different contexts. Consider,

for example, a general numeric integrator with the

following package specification:

12

generic

type REAL is digits o:

type S'I'A'r_ VECTOR is

array (INTEGER range o) of REAL;

with function StateDerivative

( T : DURATION; -- from reference time

X : STATE VECTOR )

return STATEVECTOR;

package Generic Integrator Is

procedure Integrate

( For Duration : In DURATION );

function Current State

return STATEVECTOR;

procedure Initialize .... ;

end Generic_Integrator;

This package provides the ability to numerically

integrate a Vector differential equat_0n w_th anarbitrary state vector s|ze. The :_Integr_e'=procedure

can be implemented as a vector equation, or as a set

of individual real-valued functions. To implement it

as a single vector equation we wil! need the

operations provided by a LINEAR ALGEBRA object.

These operations can be incorporated in two ways.

One possibility is to make the operations needed into

generic formal parameters. Another is to have the

body of the integrator depend directly on LINEAR

ALGEBRA.

Each of these methods has advantages and drawbacks.

Using generic formal subprograms enhances

reusability by making the component self-contained,

but if too many are needed the interface becomes

complex. Depending on LINEAR ALGEBRA within

the GENERIC INTEGRATOR makes a cleaner

interface, but couples the generic package to another

library unit. The GRODY team h_: u_gd both

methods. Figure 13 shows the composition of

GENERIC INTEGRATOR assuming the latter choice.

Figure 14 shows a use of the GENERIC

INTEGRATOR in the composition of the

ATTITUDE DYNAMICS object. The component

object ATTITUDE INTEGRATOR is an instantiation

of the GENERIC INTEGRATOR object. The generic

object is instantiated' in figure 14 with the

ATTITUDE EQUATION subprogram as the generic

actual parameter. Most of the ATTITUDE

DYNAMICS operations are shown in figure 14 as

5207

4-20

= 1

U

i

=_

i

i

Ill

I

=

I

m

m

m

m

lib

m
F

General Object-Oriented Software Development with Ada

component procedures, represented by rectangles. The

"Integrate" operation, however, is directly inherited

from the ATTITUDE INTEGRATOR object.

LEGI_IO

OBJECT O

PROCEDURE

STA'rl_ DATA r-'-"

GENERIC FORMAL r------:

SUBPROGRAM "--.---_

CONTROL FLOW

DEPENDENCY WtO .... p.

CONTROL FLOW

Figure 13 Generic I, tegrator Object Composition

Ada features such as generic packages are useful

tools, but language features are not sufficient to

guarantee high levels of software reuse. What is also

needed is an approach to specifying and designing

reusable components. Using an object-oriented

approach is useful not because object-oriented design

is essential for reuse, bu_ because the underlying

concepts are. These crucial concepts are abstraction,

information hiding, levels of virtual languages (often

called virtual "machines') and inheritance [Parnas 79,

Cox 86].

Smalltalk's subclassing [Goldberg 83] provides an

elegant means of supporting inheritance. Ada does not

directly support inheritance, but the concept can be

simulated by using "call-throughs." A call-through is

a subprogram that has little function other than to call

on another package's subprogram. To simulate

inheritance when implementing the

AttitudeDynamics package the subprogram Integrate

would be respecifie d in the Attitude Dynamics

package, with the subprogram body in

AttitudeDynamics calling on the corresponding

operation from Attitude Integrator.

13

$

FIGURE 14 Attitude Dynamics Object Composition

This technique is clearly less elegant than Smalltalk

subclassing, but it also has advantages. First, Ada

allows inheritance from more than one object.

Second, Smalltalk forces the inheritance of all

operations and data. An operation can be overridden,

but not removed, from a class. The Ada specification

of the composite package gives the developer precise

control over which operations and data items are

visible or accessible. (See [Seidewitz 87] for a more

detailed discussion of Ada and the concept of

inheritance.)

4. Conclusion

The GRODY project has provided an extremely

valuable experience in the application of objectoriented principles to a real system. This experience

guided the creation of the GOOD methodology which

is now being used on an increasing number of

projects inside and outside of the Goddard Space

Flight Center. As with any pilot project, some of the

major products of GRODY are the lessons learned

along the way.

As part of the GRODY project, a detailed assessment

has been made of the team's experiences during

design [Godfrey 871. At this time, however, most of

the observations mdst remain qualitative.

Nevertheless, it is clear that the GRODY design is

significantly different from previous FORTRAN

simulator designs [Agresti 86].

5207

4-21
General Object-Oriented Software Development with Ada

It also became clear during the GRODY project that

the GOOD methodology does not fit comfortably into

the traditional life cycle management model. At the

very least, the design phase should be extended and

des!gn reviews should occur at different points in the

llfe cycle. The preliminary design review should

occur later in the design ph_e and should include

detailed object diagrams for the upper leveB of the

system, perhaps down to the level at which the design

becomes more procedural than object-oriented. The

critical design review would then inqlude the detailed

procedural designs, perhaps using an Ada-based

design language. This reyiew might actually take

place as a series of incremental reviews of different

portions of the design. This later approach is

supported by the well-defined modularity of an

object-oriented design.

The traditional functional viewpoint provides a

comprehensive framework for the entire software life

cycle. This viewpoint reflects the action-oriented

nature of the machines on which software is run.

The object-oriented approach discussed here can also

provide a comprehensive view of the fife cycle. The

object-oriented viewpoint, however, reflects the

natural structure of the problem domain rather than

the implicit structure of our hardware. Thus, it

provides a "higher-level" approach to software

development which decreases the distance between

problem domain andsoftware solution. By making

complex software easier to understand, this simplifies

both system development and maintenance.

References

[Abbott 83]

Abbott, R. J. "Program Design by Informal English

Description," Communications of the ACM, September

t983.

[Agresti 841

Agresti, William W. "An Approach to Developing

Specification Measures," Proceedings of the 9th

Annual Software Engineering Workshop, GSFC

Document SEL-84-004, November 1984.

[Agresti 86]

Agresti, William W., et. al. "Designing with Ada for

Satellite Simulation: a Case Study," Proceedings of the

1st fnternational Conference on Ada Applications for

the Space Station, June 1986.

14

[Agresti 87]

Agresti, William W. Guidelines for Applying the

Composite Specification Model (CSM), GSFC

Document SEL-87-003, June 1987,

[Bailin 88]

Bailin, Sidney C. and J. Michael Moore. "An ObjectOriented Speciflcation Method for Ada," to be

presented at the Fifth Washington Ada Symposium,

June 1988.

[Basili 85]

Basili, V. R., et. al. "Characterization of an Ada

Software Development," Computer, September 1985.

[Booth 83]

Beech, Grady. Software Engineering with Ada,

Benjamin/Cummings, 1983.

[Booch 86a]

Booch, Grady. "Object-Oriented Software

Development," IEEE Transactions on Software

Engineering, February 1986.

[Beech 86b]

Beech, Grady. Software Engineering with Ada, 2nd

Edition, Benjamin/Cummings, 1986.

[Beech 87]

Beech, Grady. Software Components with Ada,

Benjamin/Cummlngs, I987.

[Buhr 84]

Buhr, R. J. A. System Design with Ada, PrenticeHall, 1984.

[Chen 76]

Chen, P. "The Entity-Relationship Model -- Toward

a Unified View of Data," ACM Transactions on Data

Base Systems, March 1976.

[Cherry 85]

Cherry, George W.

Thought**Tools, 1985.

PAMELA Course Notes,

[Cherry 86]

Cherry, George W. PAMELA Designer's Handbook,

Thought**Tools, 1986.

[Cherry 88]

Cherry, George W. PAMELA 2: An Ada-Based

Object-Oriented Design Method, Thought**Tools,

February 1988.

m

I

i

W

MI.

g

I

Wll

D

i

m

5207

4-22

i
General Object-Oriented Software Development with Ada

w

[Cox 86]

Cox, Brad. Object-Oriented Programming: an

Evolutionary Approach, Addison-Wesley, 1986.

[Dijkstra 68]

Dijkstra, Edsgar W. "The Structure of the 'THE'

Multiprogramming System," Communications o1' the

ACM, May 1968.

[Godfrey 87]

Godfrey, Sara, Carolyn Brophy, et. al. Assessing the

Ada Design Process and its Implications: a Case

Study, GSFC Document SEL-g7-00,_, July 1987..

[Goidberg 83]

Goldberg, Adele and David Robson. Smalltalk-80:

The Language and Its Implementation, AddisonWesley, 1983.

[McGarry 88]

McGarry, Frank and William Agresti. "Measuring Ada

for Software Development in the Software

Engineering Laboratory (SEL)," Proceedings o/ the

21st Hawaii International Conference on Software

Engineering, January 1988.

[Nelson 86]

Nelson, Robert W. "NASA Ada Experiment --

Attitude Dynamic Simulator," Proceedings o/ the

Washington Ada Symposium, March 1986.

[Parnas 72]

Parnas, David L. "On the Criteria to be Used in

Decomposing Systems into Modules," Communicatio,s

of the ACM, December, 1972.

[Parnas 79]

Parnas, David L. "Designing Software for Ease of

Expansion and Contraction," IEEE Transactions on

Software Engineering, March 1979.

[Rajlich 85]

Rajlich, Vaclav. "Paradigms for Design and

Implementation in Ada," Communications o/ the

ACM, July 1985.

[Seidewitz 86a]

Seidewitz, Ed and Mike Stark. "Towards a General

Object-Oriented Software Development

Methodology," Proceedings o/ the 1st h_ternational

Conference on Ada Applications for the Space Station,

June 1986.

[Seidewitz 86b]

Seidewitz, Ed and Mike Stark.

Oriented Software Development,

SEL-86-002, August 1986.

General ObjectGSFC Document

[Seidewitz 87]

Seidewitz, Ed. "Object-Oriented Programming in

Smalltalk and Ada', Proceedings o/the Conference on

Object-Oriented Programming, Languages, Systems

and Applications, October 1987.

[Stark 87]

Stark, Mike and Ed Seidewitz. "Towards a General

Object-Oriented Ada Lifeeyele," Proceedings o/ the

Johtt Conference on Ada Technology / Washington

Ada Symposium, March 1986.

[Ward 85]

Ward, Paul T. and Stephen J. Mellor, Structured

Development for Real-Time Systems, Yourdon Press,

1985.

[Yourdon 78]

Yourdon, Edward and Larry L. Constantine.

Structured Design: Fundamentals o/ a Discipline o/

Computer Program and Systems Design, Yourdon

Press, 1978.

15

5207

4-23
!

Lessons Learned in the Implementation Phase of a

Large Ada TM Project

Carolyn E. Brophy I, Sara Godfrey 2,

William W. Agresti _, and Victor FL Basili I

Department of Computer Science

University of Maryland

College Park, MD. 20742

2 Goddard Space Flight Center 3

Code 552.1

Greenbelt, Nil:). 20771

Computer Sciences Corporation

System Sciences Division

8728 Colesville Road

Silver Spring, MD. 20gI0

Abstract

We need to understand the effects that introducing

Ada has on the software development environment.

Thls paper is about the lemons learned from an ongoing

Ada project in the Flight Dynamics division of the

NASA Goddard Space Flight Center. It is part of a

series of lemons learned documents being written for

each development phase.

FORTRAN is the usual development language is

this environment. This project is one of the first to use

Ada in this environment. The experiment consists of

the development of two spacecrm't dynamics simulators.

One is done ]n FORTRAN with the usual development

techniques, end the other is done with Ada. The Ada

simulator is 135,000 lines of code (LOC), and the FORTRAN simulator is 45,000 LOC.

We want to record the problems and successes

which occurred during implementation. Topics which

will be dealt with include (1) use of nesting vs. library

units, (2) code reading, (3) unit testing, and (4) lemons

learned using special Ada feature,.

It is important to remember that these resets are

derived from one specific environment; we must be very

careful when extrapolating to other environments.

However, we believet_ts is a goodbeg]naing to a better

understanding of Ada use in production environment*.

Ada im• trademark of the U.S.Department of Dtfev._¢ - Ada Joint

Program O_]cc.

C_ntaet: CJ.ro_y_ B_phy. Department. of Computer S¢i¢a¢¢.

Uaiverllty of Maryland. Co11¢$e Park. MD 20742. (301) 454-

81,54.

Support/'orthisrebcsa'¢hprovldedby NASA grantNSG-$123 tothe

University of Maryland.

Ada incorpocztes many software development concopes; it is much more than "just another language".

As such, we need to understand the effects of introducing Adat into the software development environment.

This paper coneentratcs on the lessons learned from an

ongoing Ada project in the Flight Dynamics Division of

the NASA Goddard Space Flight Center (GSFC). The

Ada project is sponsored by the GSFC Software

Engineering Laboratory (SEL). It is part of a series of

lessons learned documents being written for each

development phase.

Environment

FORTRAN is the usual development language in

this environment. The flight dynamics applieatlons

involve m'ssion analysis and spacecraftorbit and attitude determination and control. Many of the software

development projects are slmilar from mission to mission providing,for example, an attitude ground support

system or an attitude dynamics simulator. This pattern

of developing similar applications is important for

domain expertLse and for the legacy developed in this

environment for code, designs, expectations and intuitions. The similarity between project, allows a high

level of rex.me of both design and code. Since the

pro[_le_ are baslc_ly famili_ones, the development

methodologies which involve much iterationdo not seem

to be necessary. The waterfall development model is

basicallyused here, and seems to work well in thiscase.

Lessons learned from the initialuses of Ada do not

include changing this basic methodology.

Project

The project was originally designed as a parallel

study with two teams. Each would develop a spacecrLft

dynamics simulator, one with FORTRAN a.s the implementation language, and one with Ada as the implementation language. The specifications for each simulator

were the same, supporting the upcoming Gamma Ray

Observatory (GRO) mission. However, there are many

g

N

Im

I

II.

U

Z

Wire

• i

i

I

D

II

a

J

5207

4-24
w

2..-"

Other differences between the projec_ which keep the

study from being truly "parallel". The FOR_ version was the production version,thus they had scheduling pressures the Ada team did not have. Without

schedulingpre_sures,the Ada team made enhancements

in theirversionnot requiredby the specifications,which

increasedtime spent on the project. This was also the

firsttime any of these team members had done an Ado

project,while the FORTRAN team was quite experienced with the use of FORTRAN. The Ada team

required training in the language and development

methodologies associated with Ada, while the FORTRAN team did things in the usual way [McGarry,

Page et at.83]. The Ado team also experimented with

various design methodologies; this was necessary to find

which ones would work better for this development

environment. The FORTRAN team was working with

a mature and stable environment. In wa'itching to Ada,

the legacy of reuse for design, code, intuitions and

experience arc gone, and will be rebuilt slowly in the

new language.

The philo, ophies of development were quite

differentbetween the two projects. The Ada team cons_stent]yapplied the ideasof data abstractionand information hiding to their design development. The FORTRAN development used structural decomposition

methods.

Our goalswith this projectinclude:

(I) How is the use of Ado characterized in this

environment?

(2) How should the.existingdevelopment process be

modified to best changeover from FORTRAN to

Ada?

(3) What problems have been encountered in

development? What ways have we found to deal

with them?

Current Project Status

Both the FORTRAN and Ads teams started in

January, lg85. The Ads team began with training in

Ads, while the FORTRAN team immediately began

requirements analysis. The FORTRAN team delivered

its product (45K) after completing acceptance testing in

June, 1987. The Ads team is scheduled to finish system

tenting its 135K product in February, 1988. Discumions

of the product size differences and effort distributions

are presented in [McGarry, Agresti 88].

The lessons learned from major phases in the Ads

development are being recorded in a series of SEL

reports: Ads training [Murphy, Stark 851, design [Godfrey,Brophy 87], and implementation [in preparation[.

This paper presents some of the main resultsfrom the

implementation (code and unit test) lessons learned.

•Lessons Learned

1. Nesting vs. Library Units

1.1 The flat structure produced by u.sin# library un,ts has

advantages over a heavlllt nested 6tructure

Nc_ting has many effects on the resulting product.

The primary advantage of nesting is that it enforces the

principle of information hiding structurally, because of

the Ads visibility rules. Whereas with library units, the

only way to avoid violations of information hiding is

through self-disclpline. In addition, the dot notation

tells the package where a module i.s located.

There are quite a few disadvantages to nesting,

however. Nesting makes reuse more difficult. A second •

dynamics simulator in Ads is now being-developed

which can reuse up to ¢0% of the Ads project's code.

But in order to reuse it, the nested code has to be

unnested, sincethe new appllcatlononly needs some of

the nested units.This is often a labor intensive operation. Nesting also increases the amount of recompiiation required when changes are made, since Ada

assumes dependencies between even sibling nested

objects/procedures,even when the dependency is not

reallythere. This requires more parts of the system to

be recompiled than is necessary when more libraryunits

are used. It is also harder to trace problems back

through nested levels than it is through levels of library

units.There isno easy.way to tellwhere s unit of code

was called from, when it is nested. But library,units

have the "with" clauses to identifythe source of a piece

of code. For thisreason itisnow believed that over use

of nesting at the expense of using thore library units

makes maintenance harder. This is contrary to the

team's earlierexpectations. The team had used nesting

successfullybefore on a 5000 linesof code trainingproject. However, this kind of approach does not scale-up

well when developing large projects.

Library units seem to have a lot of advantages.

Besides fewer recompilations when changes are made,

and easier unit testing, every library unit can e_ily be

made visible-to an)' other library unit merely by use of

the "with" clause. In nested units this visibility does not

exist, and a debugger becomes essential to see what is

happening at the deeper levels that are not within the

scope of the test driver. Library units allow smaller

components, smaller files, smaller Compilation units, and

le_ duplication of code. The system is more maintainable, since it is easier to find the unit desired. Reuse

with librat3' units is also easier, since the parts of the

system are Smaller. Configuration control is also easier

with library uniLs since more pieces are separate (i.e.,

the ratio of changes to code segments modified is closer

to I). The major disadvantage seems to be that a complicated library structure develops, which can lead to

errors by the developers. However, if the Ads project

were to be done over now, the team would use more

librar'y units, and nest less.

5207

4-25
Advantages and Disadvantages of

Nesting vs. Library Units

i

I

Adv.ntage/

NESTING

Disadvantages

• information hiding

• visibility control

• type declarations in

one plw:e

* enlarged code

• more rteompilations

• harder to trace problems

through nested

levels

* clm't easily tell when a

unit of code called

from .....................................

* type d ecJar$tlo_ in one

place mean_ problems

for rexme

* harder maintenance

* debugger required

• larger u_alt sizes

inhibit code reading

* harder to re_e part of

the system

LIBRARY UNITS

Advan*.ages

• fewer recompilations

• easier unit testing

• smaller _mp6nents

• smaller 61es

• smaller compilation units

• less code duplication

• eas|er mgintenance

* "with* clauses show source

of other code units used

* easier reuse

• easier configuration control

Di_sdvan_ges

• no information hiding

• complex ]ibrary-struCture

1.2 The balance between nesting and library units is an

important implementation issue, not a desien isaac.

The issue of whether to use library units or nested

units first arises in the design phase. At least this is the

case if it is assumed that the design documents r_flcct

this _pect of implementation (i.e., the design documents indicate in some way when nesting is intended vs.

when library units should be used). %Vhile it is

appropriate for the design to show dependencies, these

should not dictate implementation, as far as the library

unit/nesting question js _conc_rn_d: The team consideied the decisi6_s c0ncerniag nestlngllibrary units to

be an implementation issue.

5207

The library ufiitsin the Ada project went dow_

about 3 to 4 levels,while nesting went down many levels below that. Another view of the system shows the

Ada project had 124 packages and 55 iibr_,'y units.

During implementation most team members felt an

appropriate balance had been reached between nesting

levels and number of library units. However, in retrospect, several felt the nesting had been overdone.

4-26

I

W

==I

I

I

m

=

I

m

I

J

D
w

1.3 11appearl best to use Library_niLJ at l_o_tdolcm to

the sabsvstem level, and nesting at lo_r levels tohcre

Lhcrc /s minimal interaction among a small number o/

modules

Experiences with unit testing seem to indicate that

library, units should at least go down 1,o the subsystem

level. This makes testing easier. Below this level the

benefits of nesting sometimes become too important to

ignore. This is one heuristic which could be used to

help determine when the transition from library units to

nested units should occur.

Aa additional way to determine when the transition should occur is to examine the degree of interaction

between pieces. For modules which interact heavily,

library units are preferred. At the point where the

interaction drops off, using nested units is preferable.

Sections with nested code are easier to deal with when

they are small.

1._; In mapping design to code, caution should be _cd in

applying too rigorous a set of rules for visibil,'ty control.

In an attempt to control visibility, two features

appear to have been too rigorously applied. The first

feature is nesting. The design of the Ado project

seemed to suggest a particular nesting implementation.

But this created many objects within objects yielding a

high degree of nesting. The second way to control visibility is through the use of -,any "¢all-through"s (a proreduce whose only function is to call another routine).

"Cail-through's were used to group appropriate pieces

together exactly as represented in the design. They can

be implemented via nesting or library units. Faithfulnero to the design structure was maintained this way.

The design had no--primitive objects with specific

operations. These objects were implemented as packages. To put the specific operations (subprograms) into

the objects (packages) the team used "call-through"s.

Thus a physical piece of code was created for every

object in the design. "Call-through"s are one of the

reasons for the expanded code in the Ado project when

compared to the FORTRAN version. It is estimated

that out of the 13SK LOC making up the Ado system,

22K LOC (specifications and bodies) are because of

"call-through"s. While "call-through"s provide a good

way to collect things into subsystems, these should be

limited to only two or three levels in the future.

If the implementation were to be done over now,

many of the existing "call-through"s would be eliminated. Instead of creating actual code to correspond

with every object in the design, some objects in the

design would remain "logical objects". No actual packages would exist: instead, a logical object would be

made up of a collection of lower level objects.

2. Code Reading

Code reading is generally done with unit testi,g.

The developer doing the code reading is not the orle

5207

who developed the code. Comments are returned to the

original developer. After code reading and unit testing,

the unit is put under configuration control.

£.1 Code readin O helps in lralnin¢ people to use Ado

Besides helping to find errors, rode reading has.the

5car fit of increasing the proficiency of team members in

Ado. Individuals can see new ways to handle the algorlthms being encoded. Code reading also allows another

person besides the original developer to understand a

given part of the. project. This insight should help

understanding and lead to better so[utlons of problems

in the future.

E.2 Code reading helps isolate style and lol6c errors.

The m_st common errors found in code reading

with Ado were style errors. The style errors involved

adding or deleting comments, format changes, and

changes to debug code {not left in the final product).

Other types of errors found are initialization errors, and

problems with incompatibilities between design and

code. This can be due to either a design error or a ending error.

Because the Ado compiler exposes many errors not

exposable by a FORTRAN compiler, code reading Ado

has a different flavor than code reading FORTRAN.

For example, the Ado compiler exlx_ses such errors as

(1) wrong data types, {2) call sequencing errors, (3) variable errors-- either the variable is declared and never

used, or it is'used without being declared. So, one

seasoned FORTRAN developer working on the Ado project noted that code reading is more interesting in FORTRA2q, since there were more interesting errors found in

code reading FORTRAN, not found in reading Ado

code. In general, logic errors are bard to find in this

application domain, but enough logic errors are found to

make code reading worthwhile.

Some of the difficulty of code reading with Ado on

this project was due to the heavy nesting and the

number of "call-through" units. Code reading would

have been helped by a flatter implementation. The

SEPARATE facility makes it necessary to look in many

places at once to follow the code. However, code reading in Ado was easier than in FORTRAN because the

code wa_ more English-like, and hence, more readable.

Often the reused FORTRAN code is an older variety

without the structured constructs available in later versions.

Code reading tended to miss errors that spanned

multiple units. This would be expected with any implementation language as well. One example was a problem where records were skipped when they were being

output. The debugger actually found the problem.

Despite the implementation language, code reading

appears to be important for highly algorithmic routines.

4-27
Croups of routinesthat are used only to callothers may

be checked to make sure the design'spurity is maintained.

3. Unit Testing

5'I Unit testingtunsfaund to be harder uKth _4da then

unth FORTRAN.

The FORTRAN units arc already relatively isolated; this makes unit t_stlng easy. Only the global

COMMONs need to be added to do the unit tests. On

the other hand, the Ada units require a lot of "with'd

in" code, and are much more interdependent. Another

very differentAda projecthad perhaps even more interdependence between its modules than the Ada project

did. That team aLso found the interdependence made

unit testingvery di_cult. More interdependence exists

between Ada units because thereare more relationsto

express in Ads- There are textualinclusion (nesting),

wlth-ing in (libraryunits),and invocation. FORTRAN

only has invocation.

8._ The introduction of Ada as the implementation

language changed the unit testing methods dramatically.

Unit testing with Ada was done very differently.

Since one unitdepends on many others, it is usually

hard to test a unit in isolation,so thiswas generally not

done. The Ada pieces were integratedup to the package level,and then unit testingwas done. Then testing

was done with groups of unitsthat logicallyfittogether,

rather than actual unit testing. The integrated units

are t_ted, choosing only a subset of possible patl:m at a

time. The debugger is used to look at a specific unit,

since the test drivers cannot "see" the nosed ones.

With Ada projectsa debugger becomes essential.This

is in contrast to the usual development in FORTRAN

where no integrationoccurs at alluntilafterunit testing.

This shows that the biggest difference between the

way FORTRAN and Ada projects are done at this point

in development is incremental integration. This actually represents a change in the development lifecyele of

an Ada product; integration and unit testing axe alternately done rather than finishing unit testing before

integration.

8.8 The library unitnesting level issue directly affects

the difficulty o/unit testing.

The greater the nesting level, the more di_cult

unit testing ks, since the lower level units in the subsy, stem are not in the scope of the test driver. This is the

primary reason a debugger becomes a required testing

aid with Ada projects. For this reason, more library

units and less nesting would have made testing easier.

Library units have to go down to a level in the design

that makes testing more feasible. With the Ada project

that would have meant taking librar3: units down to a

lower level in tile design, if the project were to be done

over.

5207

Two other ways to deal with the nesting during

unit test were tried and were not very succmmful. One

solution pulls an inner package out, and includes the

types and "wlth'd in" modules the outer package used

in order to execute the inner one. This is ditlqcult to do

for each unit. The Other solution is to modify the

specifications of the outer package so that nested packages can be "seen" by the test driver. This solution

requires lots of recompilation. With more library units,

there would be less recompilation, because there would

be fewer changes of specifications. Again however, the

best way to test was to use the debugger on unaltered

code.

8.2 The importance o/ unit testing seems to be more

related to appllcatian area than to implementation

tongue, e: 7=i ? ?

Whether the implementation is in FORTRAN or

Ada, does not seem as important as whether the application has lots of c_alcul_atlons or has lots of data manipulations. Unit testing seemed more valuable with

scientific applications; perhaps because calculation errors

show up when only a small amount of Iocalized code is

executed. But data manipulation errors require more of

the system ___b__e operating before it is known if errors

are present.

4. Use of Ada'a $_i_|Feature-s

4.1 Separation of specifications and bodies is quite

beneficial and easy to implement.

The team entered the specifications first, whenever

possible, before the rest of the code. This gave a high

level view of the system early in the development.

Another benefit is that this helped clarifythe interfaces

earl>'. Separating the specificationsand bodies also

reduces the amount of recompilation required when

changes are made.

___ Generics we refalrly easy to implement and they

reduce the amount of code requ;rid.

The only problems encountered were with correct

compilation of the generics in some cases,due to compiler bugs in an early version of the compiler, rather

than incorrect code. As Ada matures, this will not be a

problem at all.

,(8 Using to0 many tYPes increases coding d,ff, eulty

The strong typing was very difficult to get used to,

when one is accustomed to weakly typed languages such

FORTRAN. It was easy to create too many new

types as well.

Often a brand new type was created with a strict

range appropriate for one portion of the application.

Then in other areas where subtypes could have been

used, the range on the original type was found to bc too

restrictive, so another brand ne_ type was created

instead to handle the new situatiot_. Then a whole new

4-28

J

U

mm

.o

mm

w,

==

M

m

W

U

i

g

m

l

=

J

=

I

==
set of operations had to be created as well for the additional new type. Next time the team would recommend

creating a more general new type, and using many

differentsubtypes of the original type, rather than

creatingmore new types. In thisway operationscan be

reused and there are far fewer main types to keep track

of. Designers need to spend time developing familiesof

typesthat inheritpropertiesfrom one another.

The strong typing presented some problems when

testing-units, though it prevents some kinds of errors,

also. Itwas harder to write testdriversthat could deal

with all the types in the units being tested. It was also

harder to do the I/O, since so many types had to be

dealt with.

_._ Ta_kif_ tma diffic_ 0 to code and test, holocoer, this

meemm due to concurrency m genera/ and not Ada

.,¢c,f_.uy.

Tasks were used in the user interface part of the

project. The user was given many options which made

the interactions between the tasks of the sul_tem

very difficultto plan and execute correctly.

It was harder to code tasks from the design than it

was to code other types of units. However, this is not

reallydue to Ads, but rather itis the nature of concurrency problems. The language made the use of taskiug easier,and encouraged the developers to use tasking

more than they would have otherwise. The dynamic

relationships of concurrency cannot be represented in

the design (termination, rendezvous, multiple threads of

control). Correctness was very difficult to assure, as is

usual with these kinds of problems, and deadlock was

hard to avoid. Functional testing was done, which is

the usual type in this environment.

The major problem the developers had was with

exceptions. These are no worse with tasking than they

are with any other progrmm unit, however.

J.5 Ezccption hand/or8 Aa_c to be coded care/all F.

The key problem with exceptions is deciding the

best way to handle them. Errors and the sources of

errors can be hard to find if the exception handlers are

not coded carefully. Suppose a particular procedure will

call another unit, expecting some function to be performed, and certain kinds of data to be returned. If an

exception is raised and handled in the called unit, and it

is non-specific for the problem raising the exception

(e.g., "when others") , the caller gets control back

without the required function being performed. But the

exception was handled and data was returned, so the

call looks successful. Yet as soon as the caller tried to

use the data from the routine where the exception was

raised and handled, it fails. Because of propagation, it

can be very di_cult to trace back the error to the original source of the problem.

S_veral members of the team would recommend

incorporating the way exceptions are to be handled into

the design, rather than leaving this until implementation. Put into the design (I) what exception would be

raised, (2) where it will be handled, and (3) what should

happen.

Ada Features'

implementation

ease benefit

tasking

generics +

strong typing 0

exception

handling 0

nesting +

separate

spees/bodies ++

+

++

0

+

++

* This figure represents a subjective assessment

based on team member interviews

Summary

We have learned several important things about

four major areas in implementation. There are many

advantages to using library units, though nesting can

have its usefulness at some point below the subsystem

level. Code reading helps train people in Ads, and helps

to isolate style and logic errors. Unit testing was substantially changed by using Ads: the first stages of

integration often began before unit testing proceeded.

Some Ads features are quite powerful and should be

• carefully used.

It is important to remember that these results are

derived from one specific environment. We must be

very careful when extrapolating to other environments.

There are also many questions still left to be answered.

Studies of this project will continue, and other Ads projects are being started. These will help us evaluate the

effects on longer term issues such as reuse and maintainability of the Ads projects. We believe this project is

a good beginning to a better understanding of Ada use

in production environments.

Acknowledgements

The Ads experiment is managed by Frank

McGaxry of NASA/GSFC. The authors would like to

thank him and the Ada team for their cooperation and

assistance.

5207

4-29
ORIGINAL PAGE IS

OF POOR QUALITY

Referenc_

[Agresti 85]

Agr_ti W., "Ada Experiment: Lessons Learned

(Training/Requirements Analysis Phase)", Goddard

Space Flight Center, Greenbelt, g_ 20771, August

I085.

IGodfrey, Brophy 87J

SEL-87-004, "Assessing the Ada Design Process and

Its [mplicatiom: A Case Study", Godfrey S., and

Brophy C., Goddard Space Flight Center, Greenbelt, MD 20771, July 1987.

[McGtrry, Agresti 88] .

"Me_uring Ada for Software Development in the

Software Engineering Laboratory", Hawaii International Conference on Systems Science, January,

1088.

[McGarry, Nelson 85]

McGarry F., and Nelson R., "An Experiment with

Ada - The GRO Dynamics Simulator Project

Plan," Goddard Space Flight Center, Greenbelt,

MID 20771, April 1985.

[McGarry, Page et al. 83J

SEL-81-205, "Recommended Approach to Software

Development", McGarry F., Page J., Esllnger S.,

Church V., and Merwarth P., Goddard Space

Flight Center, Greenbelt, NqD 20771, April 1983.

[Murphy, Stark 85]

SEL-85-002, "Ada Training Evaluation and Reeommendatlon_ from the Gamma Ray Observatory Ada

Development Team", Murphy R., and Stark M.,

Goddard Space Flight Center, Greenbelt, _,_D

20771, October 198.5.

Biographies

Carolyn E. Brophy is a graduate research assistant at the University of Maryland, CollegePark. Her

research interests=are _fi _ftware engineering, and sl]e is

workiag with the NASA Goddawd SoRware Engineering

Laboratory. Ms. Brophy received a B.S. degree from

the University of Pittsburgh in biology and pharmacy.

She is a member of ACM. ..........

Sara H. Godfrey is with Goddard Space Flight

Center in Greenbelt, Maryland, where she has been

working with the NASA Goddard Software Engineering

Laboratory. She received a B.S. degree from the

University of Maryland in mathematics. (picture missing) ....

WiJllam W. Agresti is with Computer Science5

Corporation in Silver Spring, Maryland. His applied

research and development projects support the Software

Engineering Laboratory at NASA's Goddard Space

Flight Center. His research interests are in software

process engineering, and he recently completed the

tutorial text, New Paradiqms for Software Development,

for the W-EE Computer Society, From 1973-83 he held

various faculty and administrative positions at the

University of Michigan-Dearborn. He received the B.S.

degree from Case \Vestern Reserve University, the M.S.

and Ph.D. from New York University.

Victor R. Basill is Professor and Chalrma_fi

of the Computer Science Department at the University of Maryland, College Park, Maryland. He wa.s

involved in the design and development of several

software projects, including the SIMPL family of

programming languages. He is currently measuring

and evaluating software development in industrial

and government settings and has consulted with many

agencies and organizations, including IBM, GE,

CSC, GTE, MCC, AT&T, Motorola, liP, NTIL,

NSWC, and NASA

W

W

ml

m

I

ml

tll

I

q

I

a

NB

m

II

J

I

5207

4-30

m

I

i
He is one of the founders and principals]n the Software Engineering Laboratory,a jointventure between NASA Goddard Space Flight Center, the Universityof

Maryland and Computer Sciences Corporation,established in IQ76. He has been

working on the development of quantltat;ve approaches for software management,

engineering and quality assurance by dove.toping models and metrics for the

software development process and product.

Dr. Basili has authored over 00 papers. In 1_82, he received the Outstanding Paper Award from the IEEE Transactions on Software Engineering for hispaper on the evaluationof methodologies.

He was Program Chairman for several conferences including the 6th International Conference on Software Engineering. He serveson the editorialboards of

the Journal o.t' Systems and Software and the IEEE Transactions on Software

Engineering and is currently Editor-in-Chlef of TSE. He is a member of the Board

of Governors of the IEEE Computer Society.

5207

4-31
OBJECT-ORIENTED PROGRAMMING IN SMALLTALK AND ADA

Ed Seidewitz

Code 554 / Flight Dynamics Analysis Branch

Goddard Space Flight Center

Greenbelt MD 20771

(301) 286-7631

Presented at the

1987 Conference on Object-Oriented Programming Systems, Languages and Applications

October 1987

Abstract 1. Introduction

Though Ada and Modula-2 are not objectoriented languages, an object-oriented

viewpoint is crucial for effective use of their

module facilities. It is therefore instructive to

compare the capabilities of a modular language

such as Ada with an archetypal object-oriented

language such as Smalltalk. The comparison in

this paper is in terms of the basic properties of

encapsulation, inheritance and binding, with

examples given in both languages. This

comparison highlights the strengths and

weaknesses of both types of languages from an

object-oriented perspective. It also provides a

basis for the application of experience from

Smalltalk and other object-oriented languages

to increasingly widely used modular languages

such as Ada and Modula-2.

Procedural programming techniques concentrate

on functions and actions. Object-oriented

techniques, by contrast, attempt to clearly

model the problem domain. The designers of

Simula recognized the attractiveness of this

concept for simulation and included specific

constructs for object-oriented programming

[Dahl 68]. Since then, several programming

languages have been designed specifically for

-general-purpose object-oriented programming.

The archetypal example is, perhaps, Smalltalk

because the language is structured so completely

around the object concept [Goldberg 83].

Ada* [DOD 83] and Modula-2 [Wirth 83] are

not designed to be object-oriented

programming languages. However, they do

have certain object-oriented features which are

descendants of Simula donstructs. Further,

object-oriented concepts have become

extremely popular for design of Ada programs

(e.g., see [Booch 83]). This paper compares and

contrasts the strict object-oriented capabilities

of Smalltalk with the object-oriented features

of Ada. The comparison is in terms of the

basic object-oriented properties of

encapsulation, inheritance anti binding. I have

attempted to keep the main body of the paper

fairly objective, reserving my more

judgemental comments for the conclusion.

*Ada is a registered trademark of the US

Government (Ada Joint Program Office)

I

I

I

i

l

I

I

W

I

i

w

I

_I

I

I

I

m

I

I

5207

4-32 i

I
w

L__

w

2. Encapsulation

An object consists of some private data and a

set of operations on that data. The intent of an

object is to encapsulate the representation of a

problem domain entity which changes state over

time. Abstraction deals with how an object

presents this representation to other objects,

suppressing nonessential details. The stronger

the abstraction of an object, the more details

are suppressed by the abstract concept. The

principle of information hiding states that such

details should be kept secret from other objects,

so as to better preserve the abstraction modeled

by the object. Both Smalltalk and Ada directly

support these basic encapsulation concepts for

objects. In Smalltalk these features are the

central structure of the language while in Ada

they are added to a core language of

ALGOL/Pascal heritage.

In Smalltalk, objects are always instances of a

class which represents a set of problem domain

entities of the same kind. All instances of a

class provide the same interface (set of

operations) to other objects. A class thus

represents a single abstraction. The class

definition provides implementations for each of

the instance operations (methods in Smalltalk)

and also defines the form of the internal

memory of all instances.

A Smalltalk method is called by sending a

message to the object, such as:

MyFinances receive: 25.50

The protocol of an object is the set of all

messages that may be received by the object. A

class itself has a protocol which usually includes

a few messages to request creation of instances,

e.g. "Finances new". Note that protocols are

not really a part of the Smalltalk language

proper, but are documentation of the

abstraction represented by a Smalltalk class.

The basic object=oriented construct in Ada is

the package. Unlike Smalltalk, objects can be

defined directly in Ada without having any

class. Further, Ada requires the definition of

the interface of an object separately from the

implementation of the object. This is done in a

package specification. Ada uses a more

traditional procedure call syntax for object

operations.

Ada is a strongly typed language, so the type of

every operation argument and return value must

be declared. A package specification provides

enough declarative information for compiletime syntax and type checking. Additional

operation descriptions, such as in the Smalltaik

protocol, can be provided by comments. Other

code refers to package operations using a

qualified name, e.g., "Finances.Receive". The

package body gives the implementation of the

package.

Example 1 -- Finances

Class Finances is a simple class of objects which

represent financial accounts of income and debt

(all examples are simplified and adapted from

[Goldberg 83]). The protocol for this class is:

Finances class protocol

instance creation

initialBalance: amount

Begin a financial account

with "amount" as the

amount of money on

hand.

new Begin a financial account

with 0 as the amount of

money on hand.

transactions

receive: amount

Finances instance ISrotocol

Receive an amount of

money.

spend:amount Spend an amount of

money.

inquiries

cashOnHand

totaiReceived

Answer the total amount

of money currently on

hand.

Answer the total amount

of money received so far.

5207

4-33
totalSpent Answerthe totalamount

of money spent so far.

The implementation of the Finances class must

include a method for each of the messages in

the protocol. It also defines the flames of a Set

of instance variables which represent the

internal data of each _class instance. The

instance variables and the implementations of

the methods are hidden from users of instances

of the class. In the Smalitalk-80 system, the

various parts of a class definition are accessed

through an "interactive system br0wsei_" The

textual descripti6n used here is based on the

one used in [Goldberg 83]. The definition of

class Finances is:

class name Finances

superclass Object

instance variable names income

debt

class methods

instance creation

tnitlalBalance: amount

"super new setlnitialBalance: amount

new

"suPer new setlnitialBalance: 0

instance methods

transactions

receive: amount

income <- income + amount

spend: amount

debt <- debt + amount

inquiries

cashOnHand

^income - debt

totalRecelved

^ income

totalSpent

"debt

private

setlnltiaiBaiance: amount

income <- amount.

debt <- 0

Note that "super new" refers to the system

method to create a new instance, """ indicates

returning a value and "<-" indicates assignment.

Some examples of use of this class are:

MyFinances <- Finances initialBalance: 500.00.

MyFinances sp_302.50. = ....

MyFinances spend: foodCost + salesTax.

MyFinances receive: payr

tax <- taxRate * (MyFinances totalReceived),

The specification for an Ada package Finances

corresponding to the above SmalItalk protocol

is: "

package Finances is

type MONEY is FLOAT;

== Initialization

procedure Set (Balance : in MONEY);

-= Transactions

procedure Receive (Amount : in MONEY);

procedure Spend (Amount : in MONEY);

-= Inquiries

function Cash On Hand return MONEY;

function Total Received return MONEY;

function Total Spent return MONEY;

1

end Finances;

The above specification for Finances really does

not define a complete object in the Smalltalk

sense. This is because a package is a static

program module, and cannot be passed around

as data. For an object to be passed as data in

Aria it must have a type. A type is analogous to

a Smalltalk class in that it represents a set of

objects with the same set of operations and

internal data. An object type is called a private

type in Ada because the representation of the

internal data is hidden. The specification for a

private type FINANCES is:

m

m

W

11

D

m

u

u

u

u

g

u

5207

4-34
package FinanceHandler is

type FINANCES is private;

type MONEY is FLOAT;

-- Instance creation

function Initial (Balance : MONEY)

return FINANCES;

-- Transactions

.procedure Receive

( Account : in out FINANCES;

Amount : In MONEY );

procedure Spend

( Account : In out FINANCES;

Amount : In MONEY);

-- Inquiries

function Cash On Hand

( Account" FINANCES )

return MONEY;

function Total Received

( Account : FINANCES )

return MONEY;

function Total_Spent

( Account : FINANCES )

return MONEY;

private

type FINANCES is

record

Income : MONEY := 0.00;

Debt : MONEY := 0.00;

end record;

end Finance_Handler;

Private types must be defined within packages.

Package FinanceHandler specifies each of the

operations on objects of type FINANCES, while

the type itself defines the internal data for each

object. The private part of the package

contains the definition of type FINANCES in

terms of other Ada type constructs. In this

case, objects of type FINANCES are effectively

declared to have two instance variables, as in

the Smalltalk example. (The private part of a

package is logically part of the package

implementation, not the specification. It is

included in the specification only so that the

compiler can tell from the specification alone

how much space to allocate for objects of

private types.) The package FinanceHandler is

in some ways similar to the metaclass of the

Smalltalk class Finances. In Smalltalk, a

metaclass is the class of a class. Both the

metaclass and the handler package provide a

framework for the definition of a class, and

they also allow for the definition of class

variables and class operations.

Since the declaration of instance variables is in

the private part of the specification of

Finance_Handler, the package body only needs

to define implementations for each of the

specified operations:

package body FinanceHandler is

-- Instance creation

function Initial (Balance : MONEY)

return FINANCES is

begin

return

( Income ffi> Balance,

Debt => 0.00 );

end FinanceHandier;

-- Transactions

procedure Receive

( Account : in out FINANCES;

Amount : in MONEY) is

begin

Account.Income := Account.Income

+ Amount;

end Receive;

procedure Spend

( Account : in out FINANCES;

Amount : in MONt_Y ) is

begin

Account.Debt := Account.Debt

+ Amount;

end Spend;

-- Inquiries

function Cash On Hand

( Account" FINANCES )

return MONEY is

begtn

return

Account.Income - Account.Debt;

end Cash On Hand;

5207

4-35
function Total Received

( Account : FINANCES )

return MONEY is

begin

return Account.Income;

end TotalReceived;

function Total_Spent

( Account : FINANCES )

return MONEY is

begin

return Account.Debt;

end Total_..Spent;

end Finance_Handler;

Each FINANCES operation explicitly includes

an Account of type FINANCES as one of its

parameters. The instance variables of an

Account are then accessed using a qualified

notation such as "Account.Income". This access

to instance variables is only allowed within the

body of package Finance Handler. Some

examples of the use of type FINANCES are:

declare

My_Finances

: Finance Handler.FINANCES

:= Finance Handler.Initial

(Balance => 500.00);

begin

Finance_Handler.Spend

( Account => My_Finances,

Amount => 32.50 );

Finance_Handier_pend

( Account => My_Finances,

Amount => Food Cost + Sales Tax );

Finance Handler.Receive

( Account => My Finances,

Amount => Pay );

Tax := Tax Rate

* Finance Handler.Total Received

(My_Finances);

end;

Packages in Ada allow the definition of objects

as program modules or the definition of classes

as private types. Packages cannot themselves be

passed as data, but the instances of private

types can. It is also possible in Ada to define

4-3

5207

classes of objects which cannot be passed as

data. This is done using a generic package

which serves as a template for instances of the

class. For example, the earlier specification for

package Finances can be made generic by

simply adding the keyword generic at the

beginning:

generic

package Finances is

end Finances;

Other packages can then be declared as

instantiations of the generic package. For

example:

declare

package M_,_Finances is

new Finances;

begin

My_Finances.Receive (Amount => Pay);

Cash := My_Finances.Cash On Hand;

end;

I will have more to say later on other important

roles of generics in Ada.

3. Inheritance

A class represents a common abstraction of a set

of entities, suppressing their differences. At a

lower level of abstraction, some entities may

differ from others. A subclass represents a

subset of the entities of a class. A subclass

inherits general abstract properties from its

superclass, defining only the specific

differences which appear at its lower level of

abstraction. This technique of subclass

inheritance allows the incremental building of

application=specific abstractions from general

abstractions.

Smalltalk directly supports the concept of

subclassing and inheritance. In Smalltalk every

class has a superciass, except for the system

class Object which describes the similarities of

atl objects. Instances of a subclass are the same

= _

um

W

J

W

N

Ill)

== !

n

Ul

D

Ill

j

M

I "
as instances of the superclass except for

differences explicitly stated in the subclass

definition. The allowed differences are the

addition of instance variables, the addition of

new methods and the overriding of superclass

methods. An instance of a subclass will

respond to at least all of the same messages as

instances of its superclass, though not

necessarily in exactly the same way.

Ada does not provide direct support for

subclassing or inheritance. However, the

concept of inheritance can be used profitably

within Ada, in some ways more generally than

in Smalltalk. When defining a subclass in Ada,

it is still necessary to declare all operations of

that subclass, even those inherited from a

superclass. Thus the specification of a subclass

package will include all the operations of the

superclass and possibly some additional ones.

(This also results in a hiding of the use of

inheritance reminiscent of the discussion in

[Snyder 86].) In the body of the subclass

package, inherited operations must be

implemented as call-throughs to the operations

of the superclass.

Example 2 -- Deductible Finances

The class DeductibleFinances is a subc}ass of

the Finances class of Section 2. Instances of

DeductibleFinances have the same functions as

instances of Finances for receiving and

spending money. However, they also keep

track of tax deductible expenditures. The

definition of DeductibleFinances specifies one

new instance variable, four new instance

methods and overrides two class methods:

class name

superclass

instance variable names

DeductibleFinances

Finances

deduc.tibleDebt

class methods

instance creation

initialBalance: amount

"(super initialBalance: amount) zeroDeduction

new

"super new zeroDeduction

instance methods

transactions

spendDeductible: amount

self spend: amount deducting: amount.

spend: amount deducting: deductibleAmount

super spend: amount.

deductibleDebt <- deductibleDebt

+ deductibleAmount

inquiries

totaiDeduction

"deducfibleDebt

private

zeroDeduction

deductibleDebt <- 0

Note that sending a message to "self" results in a

call on one of an object's own methods, while

sending a message to "super" results in a call on

one of the methods of the superclass Finances.

Now consider an Ada type which defines a

subclass of the FINANCES type of Section 2:

with FinanceHandler;

package Deductible_FinanceHandler is

type DEDUCTIBLEFINANCES is private;

subtype MONEY is

FinanceHandler.MONEY;

t

-- Instance creation

function Initial ( Balance • MONEY )

return DEDUCTIBLEFINANCES;

-- Transactions

procedure Receive

(Account:in out DEDUCTIBLE FINANCES;

Amount" in MONEY );

procedure Spend

( Account" in out DEDUCTIBLE FINANCES;

Amount' in MONEY;

Deductible Amount " in MONEY := 0.00 );

procedure Spend Deductible

( Account" in out DEDUCTIBLEFINANCES;

Amount" in MONEY );

5207

4-37
-- Inquiries

function Cash On Hand

( Account : DEDUCTIBLEFINANCES )

return MONEY;

function Total Received

( Account : DEDUCTIBLEFINANCES )

return MONEY;

function Total_Spent

( Account : DEDUCTIBLEFINANCES )

return MONEY;

function Total Deduction

( Account : DEDUCTIBLEFINANCES )

return MONEY;

private

type DEDUCTIBLE_FINANCES is

record

Finances : FinanceHandler.FINANCES;

Deductible Debt : MONEY := 0.00;

end record;

end Finance_Handler;

Package Deductible_Finance_Handler has the

new operations SpendDeductible and

TotalDeductions, and it has a modified Spend

operation. The Spend procedure has a

Deductible Amount parameter with a default

value of 0.00.

DEDUCTIBLEFINANCES implements

inheritance from FINANCES by using the

instance variable Finances of type FINANCES.

Inherited operations are then implemented as

call-throughs to operations on Finances:

package body DeductibleFinanceHandler is

-- Instance creation

function Initial ( Balance • MONEY )

return DEDUCTIBLEFINANCES is

begin

return

( Finances => FinanceHandier.Initial(Balance),

DeductibleDebt => 0.00 );

end Initial;

5207

-- Transactions

procedure Receive ......

( Account" In out DEDUCTIBLEFINANCES;

Amount" in MONEY ) is

begin

-- INHERITED --

Finance Handler.Receive -

( Account => Account.Finances,

Amount => Amount );

end Receive;

procedure Spend

( Account • In out DEDUCTIBLEFINANCES;

Amount" in MONEY;

DeductibleAmount • in MONEY := 0.00 ) is

begin ................

FinanceHandler .Spend

( Account => Account.Finances,

Amount => Amount );

Account.Deductible Debt

:,i Account.Deductible Debt

+ DeductibleAmount;

end Spend;

procedure SpendDeductible

( Account : tn out DEDUCTIBLE_FINANCES;

Amount : In MONEY ) is

begin

Spend

( Account : => Account,

Amount => Aa3ou_;

Deductible Amount => Amount );

end Spend Deductible;

-- Inquiries

function Cash On Hand

( Account : DEDUCTIBILE FINANCES )

return MONEY is

begin

-- INHERITED --

return FinanceHandler.Cash On Hand

(Account.Finances);

end Cash On Hand;

function Total Deductions

(Account: DEDUCTIBLE FINANCES)

return MONEY is

begin

return Account.Deductible Debt;

end TotalDeductions;

end DeductibleFinanceHandler;

4-38

I

m

w

m

z

m

i

um

i

a

==,

m = w

III

I

l
Unlike Smalltalk, implementing inheritance in

Ada requires an extra level of operation call.

Also, in Ada the subclass does not have direct

access to the instance variables of the

superclass. The superclass package presents the

same abstract interface to subclass packages as

to any other code. This tightens the

encapsulation of the superclass abstraction. It

also allows easy extension to multiple

inheritance where a subclass may inherit

operations from more than one superclass.

Multiple inheritance simply requires multiple

superclass instance variables with inherited

operations calling-through to the appropriate

superclass operations. In this case the new class

is really a composite abstraction formed from

more general component classes.

The main drawback of this approach is that the

Ada typing system does not recognize

subclassing. In Ada all private types are

distinct. Even though the type

DEDUCTIBLE FINANCES is logically a

subclass of type FINANCES, the type

DEDUCTIBLE FINANCES is not a subtype of

type FINANCES. It is not possible, for

instance, to pass an instance of type

DEDUCTIBLE FINANCES to a procedure

expecting an argument of type FINANCES.

The Ada compiler would see this as a type

inconsistency. A partial solution to this

involves the use of the Ada generic facility, and

will be discussed later in Section 4. However,

the problem cannot be fully overcome in Ada,

and [Meyer 86] clearly shows that true

inheritance is more powrful than genericity.

4. Binding

The Smalltalk message passing mechanism

operates dynamically. When a message is sent

to a Smalltalk object, the method to respond to

that message is looked-up at run-time in the

object's class (and possibly superclasses).

Further, Smalltalk variables are not typed, so

they may contain objects of any class. Thus it

is generally not possible to determine statically

exactly what method in what class will respond

to a message. Messages are dynamically bound

to methods at run-time. If an object cannot

respond to a message, there is a run-time error.

The use of dynamic binding gives the

programmer great freedom to create general

5207

4-39

code. Any object can be used in an instance

variable or as an argument in a message as long

as it can respond to the messages sent to it.

Another use of dynamic binding in Smalltalk is

with the "pseudo-variable .... self" which is used

by an object to send messages to itself. When a

message is sent to an object, "self" is set to the

object to which the message is sent. The

dynamic binding of messages sent to "self"

allows a class to call on methods that are really

defined in a subclass.

Unlike Smalltalk, Ada is a strongly typed

language. This means that all variables and

parameters must be declared to be of a single

specific type. This allows an Ada compiler to

check statically that only values of the correct

type are being assigned to variables and used as

arguments. The Ada compiler can also always

determine exactly what operation from what

package (if any) is being invoked by a given

call. Operation calls are thus statically bound to

the proper operation. Undefined operation calls

are always discovered at compile-time.

A way around this involves the use of generics.

In addition to their role in creating classes of

packages, generics also allow a package to be

parameterized with type and subprogram

parameters. This feature can be used to declare

a package which can use any class with certain

needed operations. Generic facilities can also

be used to allow a class to defer the

implementation of some operations to

subclasses.

Example 3 -- S_mple Space

The class SampleSpace represents random

selection without replacement from a co|Mction

of items. It has the following protocol:

SamoleSvace class protocol

instance creation

data: aCollection Create an instance such

that aCollection is the

sample space.
SamDleSpace instance t)rotocol

accessing

next

next: anlnteger

Answer the next element

chosen at random from

the sample space,

removing it from the

space.

Answer an ordered

collection of anlnteger

number of selections

from the sample space.

testing

lsEmpty Answer whether any

items remain to be

sampled.

size Answer the number of

items remaining to be

sampled.

This protocol does not specify exactly what

kind of collectionmust be used for the sample

space. The classdefinitionis:

class name SampleSpace

superclass Object

instance variable names data

rand

class methods

instance creation

data: aCollectlon

"super new setData: aCollection.

instance methods

accessing

next

t item l

self isEmpty if True:

[self error 'no values exist in the sample space'].

item <- data at:

(rand next * data size) truncated + 1.

data remove: item.

" item

5207

4-40

next: anInteger

I aCoilection I .........

aCoilection_ .... -......

<- OrderedCollection new: anlnteger.

anlnteger timesRepeat:

[aCollection addLast: self next].

"aCollection

testing

lsEmpty

"self size= 0

size

^data size

private

setData: aCollection

data <- aCollection.

rand <= Random new

Note that local variables in methods are listed

between vertical bars at. the beginning of the

method. Also, the definition of SampleSapce

uses an instance of the Smalltalk system class

Random to generate_ random numbers. In the

methods for "next" and "size", SampleSpace

sends the messages 'at:", "size" and "remove:" to

the instance variable "data" which holds the

collection of sample space items. This means

that any object which can respond to "at:", "size"

and "remove:" can serve as the collection. This

object could be an instance of a Smailtalk

system class such as Array, or it could be an

instance of a user-defined class. An example of

the use of SampleSpace i_ shuffling a deck of

cards:

class name CardDeck

superclass Object

instance variable names cards

shuffle

I sample I _: _....

sample <- SampleSpace data: cards.

cards <- sample next: cards size

An-Ada generic Sample_SPace package needs a

COLLECTION type and At, Size and Remove

L--

w

R

m

iii

!I

II

I!

II

Ill

I!

II

Jl

I

!11

m

II

11

!11

III "
...,-

operations. A specification for this package is:

generic

type COLLECTIONTYPE is private;

type ELEMENTTYPE is private;

with function At

( Collection: COLLECTION_TYPE;

Index : POSITIVE )

return ELEMENT__TYPE;

with function Size

( Collection : COLLECTION_TYPE )

return ELEMENT._TYPE;

with procedure Remove

( Collection : In out COLLECTIONTYPE;

Element : in ELEMENT_TYPE );

package Sample_Space is

Empty : exception;

type ELEMENT LIST is

array (NATURAL range <>)

of ELEMENT__TYPE;

-- Initialization

procedure Set

( Data : in COLLECTION=TYPE );

-- Accessing

function Next return ELEMENT_TYPE;

function Next ( Number : NATURAL )

return ELEMENT_LIST;

-- Testing

function IsEmpty return BOOLEAN;

function Size return NATURAL;

end Sample_Space;

Package Sample_Space uses the generic facility

both to parameterize itself and to allow a class

of objects (as discussed in Section 2). It would

also have been possible to define a generic

Sample Space Handler package with a

SAMPLE SPACE type. This would have

allowed sample spaces to be passed as data, an

ability which is not really needed for the

present example.

The body of Sample_Space is:

with Random;

package body Sample_Space is

-= Instance variable

Sample_Data : COLLECTIONTYPE;

-= Initialization

procedure Set

( Data : COLLECTION_TYPE ) is

begin

SampleData :., Data;

end Set;

-- Accessing

function Next return ELEMENT TYPE Is

Item : ELEMENTTYPE;

begin

if Is Empty then

raise Empty;

end if;

Item "- At ( Sample Data, Index =>

NATURAL((Random.Value*Size)+l ) );

Remove

( Collection ffi> SampleData,

Element => Item );

return Item;

end Next;

function Next ( Number : NATURAL )

return ELEMENT LIST is

List : ELEMENT_LIST(I .. Number);

begin

for I in ! .. Number loop

List(I) := Next;

end loop;

return List;

end Next; i

-- Testing

function IsEmpty return BOOLEAN is

begin

return (Size ffi 0);

end IsEmpty;

function Size return NATURAL is

begin

return Size(Sample_Data);

end Size;

end Sample_Space;

The Sample_Space package body assumes the

availability of a package Random to generate

random numbers. Sample_Space could then be

4-41

5207
used to shuffle

CARDDECK:

an instance of private type

with Sample Space;

package body Card_Deck_Handler Is

package Sample is new Sampie_..Space

( COLLECTION_TYPE -> CARD_DECK,

ELEMENTTYPE -> CARD_TYPE,

At -> Card,

Size -> Deck_Size,

Remove -> Remove Card );

i

procedure Shuffle

( Cards : in out CARD__DECK ) is

begin

Sample.Set (Data ffi> Cards),

Cards :- CARDDECK

(Sample .Next(DeckSize(Cards)));

end Shuffle;

end Card_Deck_Handler;

Generic package SampleSpace is a template

for a general class of sample spaces. Since a

COLLECTIONTYPE must be specified when

Sample_Space is instantiated, each instance of

this class can only handle a single type of

collection for sampling. Thus an Ada compiler

can still perform static type checking for each

instantiation of generic packages.

The dynamic binding and lack of typing in

Smalltalk allow an instance of a subclass to be

used anyplace an instance of its superclass may

be used. As mentioned at the end of Section 3

the Ada type system does not allow this because

it views all private types as distinct and

incompatible, The above generic technique can

help with this problem, also. A generic package

(or other program unit) which is parameterized

by the types and operations it needs will be able

to use any type with the necessary operations.

Thus if the private type representing some class

can be plugged into a generic, then a subclass

type can also be plugged into that same generic.

However, the generic must be instantiated

separately for each type. There is no easy way

5207

in Ada have a true polymorphic procedure, that

is, a single procedure With an argument which

accepts values of different types.

5. Conclusion

Smalltalk and Ada are based on quite different

philosophies. Smalltalk is designed to make it

easier to program and to incrementally build

and modify systems. Ada, on the other hand,

purposefully places certain additional

obligations on the programmer so that the final

system will be more reliable and more

maintainable. The Ada philosophy takes a

much more life-cycle-oriented approach,

recognizing that most costly phase of software

development is maintenance, not coding.

If the languages have such different bases, then

why consider using object-oriented ideas for

Ada? The answer is that object-oriented

concepts really apply to more than just

programming. In Ada circles,these concepts

are usually applied to design [Booch 83,

Seidewitz 86a, Seidewitz 86b]. The objectoriented viewpoint is crucial to designing for

effect use of Ada's package facility.Further,

the object-oriented approach can be a general

way of thinking about software systems which

can be applied from system specification

through testing. This fitsin quite well with the

Ada life-cyclephilosophy [Booch 86, Stark 87].

Still,Ada has some unfortunate drawbacks for

object-oriented programming, especiallyin its

lack of support for inheritance. As an objectoriented programming language Smalitalk is in

many ways clearly superior to Ada. However,

as a life-cycle software engineering language

Ada has great advantages. "Static strong typing

is crucial to increasing the reliability of

software. Even with a good testing

methodology, large amounts of code will not be

thoroughly tested because it is only executed in

rare combinations of situitions. But when a

system is running continuously for years, any

errors that remain in these sections of code will

almost certainly occur. This is especially true

for the embedded real-time systems which were

Ada's original mandate. In Aria, all sections of

code are checked by the compiler, and many

errors can be caught before the testing phase

due to static type checking and static operation

binding.

4-42

--4

qle

I

I

I

I

Z

I

I

I

I

I

I

I

I

_mm

I

I

M

I
L_

It is possible to support inheritance and even

polymorphism within a statically typed language

(as in, for example, Eiffel [Meyer 86, Meyer

87]). Inheritance might be added to Ada

without too much change to the design of the

language. Incorporation of polymorphism

would be much more difficult, and probably

require a philosophical change in the Ada

language design. However, even with these

deficiencies for object-oriented programming,

Ada still provides a useful vehicle for applying

object-oriented concepts throughout the

software development life-cycle.

Much of the above discussion also applies to

other modular languages such as Modula-2

(though Modula-2 does not directly support

genericity). As these languages become more

and more widely used it will be increasingly

important to apply to them the experience in

object-oriented software development gained

from Smalltalk and other object-oriented

languages.

References

[Booth 83]

Grady Booch. Software I_ngin¢¢ring wi_h Ada,

Benjamin/Cummings, 1983.

[Booch 86]

Grady Booch. "Object-Oriented Development,"

IEEE Transactions on Software Engineerinf,

February 1986.

[Dahl 68]

O-J Dahl. Simula 67 Common Base Langoag¢,

Norwegian Computing Center, Oslo, Norway,

1968.

[DOD 83]

US Department of Defense, Reference Manual

for the Ada Pro_rammin_ Language,

ANSI/MIL-STD- 1815A- 1983.

[Goldberg 83]

Adele Goldberg and David Robson. $malltalk80: The Language a0d its Implementation.

Addison-Wesley, 1983.

[Meyer 86]

Bertrand Meyer. "Genericity versus

Inheritance," OOPSLA '86 Conferen¢_

Proceedings, SIGPLAN Notices, November

1986.

[Meyer 87]

Bertrand Meyer. "Eiffel: Programming for

Reusability and Extendability," SIGPLAN

_, February 1987.

[Seidewitz 86a]

Ed Seidewitz and Mike Stark. "Towards an

Object-Oriented Software Development

Methodology," Prg_, of the 1st Intl. Conf, 9,

Ads Avvlications for the Sva¢ Station, June

1986.

[Seidewitz 86b]

Ed Seidewitz and Mike Stark. General Obiec_-

Oriented Software DevelovmgnL Goddard

Space Flight Center, SEL-86-002, August 1986.

[Snyder 86]

Alan Snyder. "Encapsulation and Inheritance in

Object-Oriented Programming Languages,"

OOPSLA '86 Conference Proceedings,

_IQPLAN NoticeL November 1986.

[Stark 87]

Mike Stark and Ed Seidewitz. "Towards a

General Object-Oriented Ada Life-Cycle,"

Proc. Qf the Joint 4th Washington Ada

Svmo0_ium / Fifth N_L ¢0nf, 9n Ada

Technology, March 1987.

[Wirth 83] i

Niklaus Wirth. Pro_rammin_ in Modula-2,

Springer-Verlag, 1983.

5207

4-43
g

JR

u

iii

II

II

g

J

U

J

m

IEI

u

ml

i

m

m

II

g

U

II "
STANDARD BIBLIOGRAPHY OF SEL LITERATURE
Uj

,

w

lw

_W

Ull

: :::L7zi__±

J

lul

7

imW
±

u

STANDARD BIBLIOGRAPHY OF SEL LITERATURE

The technical papers, memorandums, and documents listed in

this bibliography are organized into two groups. The first

group is composed of documents issued by the Software Engineering Laboratory (SEL) during its research and development

activities. The second group includes materials that were

published elsewhere but pertain to SEL activities.

$ED-QRIGINATED DOCUMENTS

SEL-76-001, Proceedinas From the First Summer Software Enqineerinq Workshop, August 1976

SEL-77-002, ?roceedinas From the Second Summer Software En c

gineering Workshop, September 1977

SEL-77-004, A Demonstration of AXES for NAVPAK, M. Hamilton

and S. Zeldin, September 1977

SEL-77-005, GSFC NAVPAK Desiqn Specifications Lanauaaes

StudY, P. A. Scheffer and C. E. Velez, October 1977

SEL-78-005, Proceedinas From the Third Summer Software Enai_

neerinq Workshop, September 1978

SEL-78-006, GSFC Software Enqineering Research Requirements

Analysis StudY, P. A. Scheffer and C. E. Velez, November 1978

SEL-78-007, Applicability of the Ravleiah Curve to the SEL

Environment, T. E. Mapp, December 1978

SEL-78-302, FQRTRAN Static Source Code AnalYzer Program

(SAP) User's Guide (Revision 3), w. J. Decker and

W. A. Taylor, July 1986

SEL-79-002, The Software Enaineerina Laboratory: Relationship Eauations, K. Freburger and V. R. Basili, May 1979

SEL-79-003, Common Software Module Repository (CSMR) System

Description and User's Guide, C. E. Goorevich, A. L. Green,

and S. R. Waligora, August 1979

SEL-79-004, Evaluation of the Caine, Farber, and Gordon Proqr%m Desiqn Languaae (PDL) in the Goddard Space Flight Center (GSFC) Code 580 Software Desiqn Environment,

C. E. Goorevich, A. L. Green, and W. J. Decker, September

1979

9913

B-I
SEL-79-005, Proceedinas From the Fourth Summer Software Enaineerina WorkshoD, November 1979

SEL-80-002, Multi-Level Expression Desiqn L_nquaqe7

R_quirement Levei (MEDL-R5 System Evaiuati6n, W. j. Decker

and C. E. Goorevich, May 1980

SEL-80-003, Mgl_imission Modular Spacecraft Ground SUDDort

Software System (MMS/GSSS) State-of-the-Art Computer Systems/

Compatibility Study, T. Welden, M. McClellan, and

P. Liebertz, May 1980

SEL-80-005, A Stu4y Qf the Musa Reliability Model,

A. M. Miller, November 1980

SEL-80-006, Proce_4inq_ From the Fifth Annual Software Enaineerinq Workshop, November 1980

SEL-80-007, An Appr_i$_l Qf Selected Cost/Resource Estimation Model s for Software Systems, J. F. Cook and

F. E. McGarry, December 1980

SEL-81'008, C6s_and Reliabiii£v EStimat_0n Models (CAREM)

_ser's Guide, J. F. Cook and E. Edwards, February 1981

SEL-81-009, Software En_inee_no Lab0r-at0rv Prourammer Workbench Phase i Evaluation, W. J. Decker and F. E. McGarry,

March 1981 ......

SEL-81-011, _va!uating Software Development by Analysis of

Chanoe Data, D. M. Weiss, November 1981

SEL-81-012, The Ravleiqh Curve As a Model for Effort Distribution Over the Life of Medium Scale Software Systems, G. O.

Picasso, December 1981 :_ _ ....... _ _

SEL-81-013, Procee_inqs From the Sixth Annual Software Enoineerinu Workshop, December 1981

= _ _ i v _

SEL-81-014, Automat@d Collection of Software Enqineerinq

Data in the Softwar% Enqineerinq L_boratorv (SEL),

A. L. Green, W. J. Decker, and F. E. McGarry, September 1981

SEL-81-101, Guide to Data Collection, V. E. Church,

D. N. Card, F. E. McGarry, et al., Augusto1982

SEL-81-!02, Software Engine%rinq Laboratory ($EL) Data Base

Qrqaniz_tion and User's Guide Revision i, P. Lo and

J

m

w

g

_I

g

g

==m

J

_ I

i

U

g

D

J

J

U

9913

B-2

U
m

SEL-81-104, The Software Enqineerinq Laboratory, D. N. Card,

F. E. McGarry, G. Page, et al., February 1982

SEL-81-106, Software Enqineerinq Laboratory (SEL) Document

Library (DOCLIB) System Description and User's Guide,

W. Taylor and W. J. Decker, May 1985

SEL-81-107, Software Enqineerinq Laboratory (SEL) Compendium

of Tools, W. J. Decker, W. A. Taylor, and E. J. Smith,

February 1982

SEL-81-110, Evaluation of an Independent Verification and

Validation (IV&V) Methodoloqv for Fliqht Dynamics, G. Page,

F. E. McGarry, and D. N. Card, June 1985

SEL-81-203, Software Enqineerinq Laboratory (SEL) Data Base

Maintenance System (DBAM) User's Guide and System Description, P. Lo, June 1984

SEL-81-205, Recommended Approach to Software Development,

F. E. McGarry, G. Page, S. Eslinger, et al., April 1983

SEL-82-001, Evaluation of Manaaement Measures of Software

Development, G. Page, D. N. Card, and F. E. McGarry,

September 1982, vols. 1 and 2

SEL-82-003, Software Enaineerinq Laboratory (SEL) Data Base

ReDortina Software User's Guide and System Description,

P. Lo, August 1983

SEL-82-004, Collected Software Enqineerina Papers:

ume i, July 1982

VolSEL-82-007, Proceedinas From the Seventh Annual Software

_nqineerina Workshop, December 1982

SEL-82-008, Evaluatinq Software Development by Analysis of

Chanqes: The Data From the Software Enqineerina Laboratory,

V. R. Basili and D. M. Weiss, December 1982

SEL-82-I02, FORTRAN Static Source Code Analyzer Proqra_

(SAP) System Description (Revision i), W. A. Taylor and

W. J. Decker, April 1985

SEL-82-I05, Glossary of Software Enaineering Laboratory

Terms, T. A. Babst, F. E. McGarry, and M. G. Rohleder,

October 1983

w

9913

B-3

w
SEL-82-606, Annotated Biblioqraphv of Softwar_ Enqineerinq

Laboratory Literature, S. Steinberg, November 1988

SEL-83-001, An Approach to Software Cost Estimation,

F. E. McGarry, G. Page, D. N. Card, et el., February 1984

SEL-83-002, Measures and Metrics for Software Dev_lopment,

D. N. Card, F. E. McGarry,_G: Page, et el., March 1984

SEL-83-003, Collected Software Enqineerinq Papers: Volume II, November 1983

eEL-83-006, Monitorinq Software Development Throuqh Dynamic

Variables, C. W. Doerflinger, November 1983 r

SEL-83-007, Proceedings From the Eiuhth Annual Software Engineerinq Workshop, November 1983

eEL-84-001, Manaqer's Handbook for Software Development,

W. W. Agresti, F. E. McGarry, D. N. Card, et el., April 1984

SEL-84-002, Configuration Manaqement and Control: Policies

_nd Procedures, Q. L. Jordan and E. Edwards, December 1984

SEL-84-003, Investiqation of SpecificationMeasures for the

So ftw_are Engineerinu Laboratory (SEL), W. W. Agresti,

V. E. Church, and F. E. McGarry, December 1984

SEL-84-004, Pr0ceedinqs From the Ninth Annu_I Software _nqineerinq Workshop, November 1984

SEL-85-001, A Comparison of Software Verification Techniques, D. N. Card, R. W. Selby, Jr., F. E. McGarry, et el.,

April 1985

SEL-85-002, A4_ Traininq Evaluation and Recommendations From

the Gamma Ray Observatory Ada Development Team, R. Murphy

and M. Stark, October 1985

SEL-85-003, Collected Software Enqineerinq Papers: Volume III, November 1985

SEL-85-004, Evaluations of Software Technoloqies: Testinq.

CLEANR_M, and Metrics, R. W. Selby, Jr., May 1985

SEL-85-005, Software Verification and Testina, D. N. Card,

C. Antle, and E. Edwards, December 1985

SEL-85-006, Proceedinqs From the Tenth Annu_! Software Enqiz

neerinu workshop, December 1985

9913

B-4

i

I

m

l

U

m

m

m

==_

a

mm

m

l

m

J

W

g

M

M
SEL-86-001, PrQqrammer's Handbook for Fliqht Dynamics Softw_re Development, R. Wood and E. Edwards, March 1986

SEL-86-002, General Object-Oriented Software Development,

E. Seidewitz and M. Stark, August 1986

SEL-86-003, Fliaht DYnamics System Software Development Environment Tutorial, J. Buell and P. Myers, July 1986

SEL-86-004, Collected Software Enqineerinq Papers;

um_ IV, November 1986

VolSEL-86-005, Measurina Software Desiqn, D. N. Card, October

1986

SEL-86-006, Proceedinas From the Eleventh Annual Software

Enaineerinq Workshop, December 1986

SEL-87-001, Product Assurance Policies and Procedures for

Fliaht Dynamics Software Development, S. Perry et al., March

1987

SEL-87-002, Ada Style Guide (Version i.i), E. Seidewitz

et al., May 1987

SEL-87-003, Guidelines for Applvinq the Composite Specification Model (CSM), W. W. Agresti, June 1987

SEL-87-004, Assessinq _h@ Ada D@$iqn Process and Its ImD!_-

cations; A Case Study, S. Godfrey, C. Brophy, et al.,

July 1987

SEL-87-005, Fliaht Dynamics Analysis System (FDAS) Build 3

User's Guide, S. Chang et al., October 1987

SEL-87-006, Fliaht Dynamics Analysis System (FDAS) Build 3

System Description, S. Chang, October 1987

SEL-87-007, ADDlication Software Under the Fliqht Dynamics

Analysis System (FDAS) Build 3, S. Chang et al., October 1987

SEL-87-008, Data Collection Procedures for the Rehosted SEL

Database, G. Heller, October 1987

SEL-87-009, Collected Software Enaineerinq Papers:

S. DeLong, November 1987

Volume V,

SEL-87-010, Proceedinas From the Twelfth Annual Software En-

_in_rinq Workshop, December 1987

9913

B-5
SEL-88-001, System Testinq of a Production A4_ Project:

GRODY Study, J. Seigle and Y. Shi, November 1988

The

SEL-88-002, Collected Software Enaineerina Papers:

ume VI, November 1988 .....

VolSEL-RELATED LITERATURE

Agresti, W. W., Definition of Specification Measures for the

Software Enqine_rinq L_boratorv, Computer Sciences Corporation, CSC/TM-84/6085, June 1984 + -

4Agresti, W. W., V. E. Church, D. N. Card, and P. L. Lo,

"Designing With Ada for Satellite Simulation: A Case Study,"

Proceedinq_ of _+ First International Symposium on Ada for

the NASA Sp_ Station, June 1986 ..........

2Agresti, W. W., F. E. McGarry, D. N. Ca;dL et al., "Measuring Software Technology," Pr0qram Transformation and Proqramminq Environments. New York: Springer-Verlag, 1984

iBailey, J. W., and V. R. Basili, "A Se£_M4del for Software Development Resource Expenditures," Proceedinq_ of the

Fifth International Conference on Software Enaineerina.

New York: IEEE Computer Society Press, 1981

IBasili, V. R., "M0deiS and Metrics f0r Software Management and Engineering," ASME Advances in Computer Technology,

January 1980, 4oI,/_i .... + ....._

Basili, V. R., Tu_ori_l on MD4@!_ and Metrics for Software

Management and Enqineerina. New York: IEEE Computer Society

Press, 1980 (also designated SEL-80-008) _+

3Basili, V. R., "Quantitative Evaluation of Software Methodology," Proceedinas of the First Pan-Pacific Computer Conference, September 1985

IBasili, V. R., and J. Beane, "Can the Parr Curve Help

With Manpower Dfs£r_b6£_on a_d Resource_Es£imation Problems?," Journal of Systems and Software, February 1981,

vol. 2, no. 1

iBasili, V. R., and K. Freburger, "Programming Measurement

and Estimation in the Software Engineering Laboratory,"

Journal o£Svstems and Software, February 1981, vol. 2, no. 1

3Basili, V. R., and N. M. Panlilio-Yap, "Finding Relationships Between Effort and Other Variables in the SEL, "_

Proceedinqs of the International Computer S f_are and_Applications Conference, October 1985

9913

B-6

I

W

m

=

J

_+_

g

W

m

m

J

m

W

m

-+-- -

I

_w
4Basili, V. R., and D. Patnaik, A Study on Fault Prediction

an_ Reliability Assessment in the SEL Environment, University

of Maryland, Technical Report TR-1699, August 1986

2Basili, V. R., and B. T. Perricone, "Software Errors and

Complexity: An Empirical Investigation," Communications of

the ACM, January 1984, vol. 27, no. 1

iBasili, V. R., and T. Phillips, "Evaluating and Comparing

Software Metrics in the Software Engineering Laboratory,"

Proceedinqs of the ACM SIGMETRICS Symposium/Workshop: Qua!-

itv Metrics, March 1981

3Basili, V. R., and C. L. Ramsey, "ARROWSMITH-P--A Prototype Expert System for Software Engineering Management,"

Proceedinas of the IEEE/MITRE Expert SYstems in Government

_, October 1985

Basili, V. R., and R. Reiter, "Evaluating Automatable Measures for Software Development," Proceedinas of the Workshop

on Quantitative Software Models for Reliability, Complexity,

and Cost. New York: IEEE Computer Society Press, 1979

5Basili, V. and H. D. Rombach, "Tailoring the Software

Process to Project Goals and Environments," Proceedings of

the 9th International Conference on Software Engineering,

March 1987

5Basili, V. and H. D. Rombach, "T A M E: Tailoring an Ada

Measurement Environment," Proceedinas of the Joint Ada Conference, March 1987

5Basili, V. and H. D. Rombach, "T A M E: Integrating Measurement Into Software Environments," University of Maryland,

Technical Report TR-1764, June 1987

6Basili, V. R., and H. D. Rombach, "The TAME Project:

Towards Improvement-Oriented Software Environments," IEEE

Transactions on Software Enqineerina, June 1988

2Basili, V. R., R. W. Selby, and T. Phillips, "Metric Analysis and Data Validation Across FORTRAN Projects," IEEE

Transactions on Software Enaineerinq, November 1983

3Basili, V. R., and R. W. Selby, Jr., "Calculation and Use

of an Environments's Characteristic Software Metric Set,"

Proceedinqs of the Eiqhth International Conference on Software Enqineerinq. New York: IEEE Computer Society Press,

1985

9913

B-7
Basili, V. R., and R. W. Selby, Jr., ComDarinq the Effectiven@ss of Software Testinq Strateqies, University of Maryland•

Technical Report TR-1501, May 1985

4Basili, V. R., R. W. Selby, Jr., and D. H. Hutchens, "Ex _

perimentation in Software Engineering•" IEEE Transactions on

_Qftware Enqineerinu, July 1986

5Basili• V. and R. Selby, "Comparing the Effectiveness of

Software Testing Strategies," IEEE Transactions on Software

Enaineerina (in press)

2Basiii, V. R., and D. M. Weiss, _ Methodoloqv for Collectinq

Valid Software Enqineerina Data, University of Maryland, Technical Report TR-1235 December 1982 : :_: __ ;7 _ _

3Basili, V. R., and D. M. Weiss, "A Methodology for Collecting Valid Software Engineering Data," _EEE Transactions on

Software Enaineerina, November 1984

1Basili, V. R., and M. V. Zelkowitz, "The Software Engineering Laboratory: Objectives," Proc_@dinas of the Fifteenth Annual Conference on Computer Personnel Research,

August 1977

Basili, V. R., and M. V. Zelkowitz, "Designing a Software

Measurement Experiment," Proceedinqs of the Software Life

Cycle Manaqement Workshop, September 1977

1Basili, V. R., and M. V. Zelkowitz, "Operation of the Software Engineering Laboratory, " Proceedinqs of the Second Software Life Cycle Manaqement Workshop, August 1978

1Basili, V. R., and M. V. Zelkowitz, "Measuring Software

Development Characteristics in the Local Environment," Computers and Structures, August 1978, vol. 10

Basili, V. R., and M. V. Zelkowitz, "Analyzing Medium Scale

Software Development•" Proceedinqs of the Third Int_na-

_iQn_l Conference on Software Enaineerinq. New York: IEEE

Computer Society Press, 1978

5Brophy, C., W. Agresti, and V. Basili, "Lessons Learned

in Use of Ada-Oriented Design Methods," Proceedinus of the

Joint Ada Conference, March 1987 ...............

6Brophy, C. E., S, Godfrey, W. W. Agresti, and V. R. Basili,

"Lessons Learned in the Implementation Phase of a Large Ada

Project," Proc_dinas of the Washinqton Ada T_chnical Con-

__e=!_D_c__,March 1988

u

g

l

Z

I

[]

u

J

W

9913

B-8
w

3Card, D. N., "A Software Technology Evaluation Program,"

Annals do XVIII Conqresso Nacional de Informatica, October

1985

5Card, D. and W. Agresti, "Resolving the Software Science

Anomaly," Th@ Journal of Systems and Software, 1987

6Card, D. N., and W. Agresti, "Measuring Software Design

Complexity," The Journal of Systems and Software, June 1988

4Card, D., N., V. E. Church, and W. W. Agresti, "An Empirical Study of Software Design Practices," IEEE Transactions on Software Enaineerina, February 1986

5Card, D., F. McGarry, and G. Page, "Evaluating Software

Engineering Technologies," _EE Transactions on Software

Enqin_rina, July 1987

3Card, D. N., G. T. Page, and F. E. McGarry, "Criteria for

Software Modularization," Proceedinqs of the Eiqhth International Conference on Software Enqineerina. New York: IEEE

Computer SocietyPress, 1985

iChen, E., and M. V. Zelkowitz, "Use of Cluster Analysis

To Evaluate Software Engineering Methodologies," Proceedinas of the Fifth International Conference on Software

E/ig_i_i_. New York: IEEE Computer Society Press, 1981

4Church, V. E., D. N. Card, W. W. Agresti, and

Q. L. Jordan, "An Approach for Assessing Software Prototypes," ACM Software Enqineerina Notes, July 1986

2Doerflinger, C. W., and V. R. Basili, "Monitoring Software

Development Through Dynamic Variables," Proceedinas of the

$@venth International Computer Software and ADDlications

Conference. New York: IEEE Computer Society Press, 1983

5Doubleday, D., "ASAP: An Ada Static Source Code Analyzer

Program," University of Maryland, Technical Report TR-1895,

August 1987 (NOTE: 100 pages long)

6Godfrey, S. and C. Brophy, "Experiences in the Implementation of a Large Ada Project," Proceedinas of the 1988

Washinqton Ada Symposium, June 1988

Hamilton, M., and S. Zeldin, A Demonstration of AXES for

NAVPAK, Higher Order Software, Inc., TR-9, September 1977

(also designated SEL-77-005)

Jeffery, D. R., and V. Basili, "Characterizing Resource

Data: A Model for Logical Association of Software Data,"

University of Maryland, Technical Report TR-1848, May 1987

9913

B-9
6jeffery, D. R., and V. R. Basili, "Validating the TAME

Resource Data Model," Proceedinqs Of th_ Tenth International

Conference on Software Enqineerinq, April 1988

5Mark, L . and H . D. Rombach, "A Meta Information Base for

Software Engineering," University of Maryland, Technical

Report TR-1765, July 1987

6Mark, L. and H. D. Rombach, "Generating cu_stomized Software Engineering Information Bases from Software Process and

Product Specifications," Proceedinqs of the 22nd Annual

Hawaii International Conference on Svs£ern sciences, January

1989

5McGarry, F. and W. Agrgst!_ "Measuring Ada for Software

Development in the Software Engineerlng Laboratory (SEL),"

Proceedinqs of the 21st Annual Hawaii International Conference on System Sciences, January 1988

3McGarry, F. E., J. Valett, and D. Hall, "Measuring the

Impact of Computer Resource Quality on the Software Development Process and Product," Proceedinq_ of the Hawaiian International Conference on System Sciences, january i985

3page, G., F. E. McGarry, and D. N. Card, "A Practical Experience With Independent Verification and Validation,"

Proceedinqs of the EiqhthInternation_l Computer Software

_nd Applications Conference, November 1984

5Ramsey, C. and V. R. Basili, "An Evaluat_ion of _xpert Systems for Software Engineering Management," University of

Maryland, Technical Report TR-1708, September 1986

3Ramsey, J., and V. R. Basili, "Analyzing the Test Process

Using Structural Coverage," P_oceedinqs of _he Eiahth International Conference on Zoftware Enqineerina. New York:

IEEE Computer Society Press, 1985

5Rombach, H. D., "A controlied Experiment on the Impact of

Software Structure on-Maintainability, _ IEE_ Transactions on

Software Enaineerinq, March 1987

6Rombac_H_?_D., and v. R_ _Basil_'_"Quantitative Assessment

of Maintenance: An Industrial Case Study," Proceedinqs from

th_ CQnf_rence on Software Maintenance, September 1987

6R0mbich,'_H._D_,_an_'_. '_ark, "So_ware Process and Product Specifications: A Basis for Generating Customized SE

Information Bases," Proceedinqs of the 22nd Annual Hawaii

Int@rnational Conference on System Sciences, January 1989

l

I

mm

i

m

m

I

m

m

I

i

l

m

9913

B-10 m

u
5Seidewitz, E., "General Object-Oriented Software Development: Background and Experience," Proceedinqs of the 21St

Hawaii International Conference on System Sciences, January

1988

6Seidewitz, E., "General Object-Oriented Software Development with Ada: A Life Cycle Approach," Pr0¢eedinqs of the

CASE Technoloqv Conference, April 1988

6Seidewitz, E., "Object-Oriented Programming in Smalltalk

and Ada," Proceedinas of the 1987 Conference on ObiectQri_nted Proaramminq Systems, Lanquages, an_ Applications,

October 1987

4Seidewitz, E., and M. Stark, "Towards a General ObjectOriented Software Development Methodology," Pr0ceedinqs of

the First International Symposium on A4a fqr the NASA SPace

Station, June 1986

Stark, M., and E. Seidewitz, "Towards a General ObjectOriented Ada Lifecycle, '° proceedinas of the Joint Ada Conference, March 1987

Turner, C., and G. Caron, A Comparison of RADC %nd NASA/SEL

Software Development Data, Data and Analysis Center for

Software, Special Publication, May 1981

Turner, C., G. Caron, and G. Brement, NASA/$EL Data Compeni_, Data and Analysis Center for Software, Special Publication, April 1981

5Valett, J. and F. McGarry, "A Summary of Software Measurement Experiences in the Software Engineering Laboratory,"

pr0¢eedinqs 0f th_ 21st Annual Hawaii International Conference on System Sciences, January 1988

3weiss, D. M., and V. R. Basili, "Evaluating Software Development by Analysis of Changes: Some Data From the Software Engineering Laboratory," IEEE Transactions on Software

Enqine_rinq, February 1985

5WU, L., V. Basili, and K. Reed, "A Structure Coverage Tool

for Ada Software Systems," Proceedinas of the Joint Ada ConI

f@rence, March 1987

IZelkowitz, M. V., "Resource Estimation for Medium Scale

Software Projects," Proceedinas of the Twelfth Conference on

the Interface of Statistics and Computer Science. New York:

IEEE Computer Society Press, 1979

9913

B-II
2Zelkowitz, M. V., "Data Collection and Evaluation for Experimental Computer Science Research," Empirical Foundations

for Computer and Information Science (proceedings),

November 1982

6Zelkowitz, M. V, "The Effectiveness of Software Prototyping: A Case Study," Proceedinqs of the 26th Annual Technical Symposium of the Washington, D. C., Chapter of the ACM,

June 1987

6Zelkowitz, M. V., "Resource Utilization During Software

Development," Journal of Systems and Software, 1988

Zelkowitz, M. V., and V. R. Basili, "Operational Aspects of

a Software Measurement Facility," Proceedinqs of the Soft,

ware _fe Cycle Manaaemen£ Workshop, September i977

NOTES:

IThis article also appears in SEL-82-004, Collected Software Enaineerina Papers: volume I, July 1982.

2This article also appears in SEL-83-003, Collected Softw%re Enaineerinq P_pers: Volume II, November 1983.

3This article also appears in SEL_85-003, Collected Software Enqineerina Papers: Volume III, November 1985.

4This article aiso appears in SEL'86"004, Coliected Software Enqineerinq Papers: Volume IV, November 1986.

5This article also appears in SEL-87-009, Collected Soft -_

war_ Enqineerinq P%pers: Volume V, November 1987._ ........

6This article also appears in SEL-88-002, Collected Softw_re Enaineerinu Papers: Volume VI, November 1988.

z

m

m

I

g

l

m

I

J

i

J

J

m

m

W

w

W

9913

B-12