Evolving the Reuse Process at the Flight Dynamics Division...

SEW21GSS.DOC 1 February 25, 1997

Evolving the Reuse Process at the Flight Dynamics Division(FDD) Goddard Space Flight Center

S. Condon,1 C. Seaman,2 V. Basili,2 S. Kraft,3 J. Kontio,2 Y. Kim2

1 Computer Sciences Corporation, Lanham-Seabrook, Maryland2 Computer Sciences Dept., University of Maryland, College Park, Maryland3 Goddard Space Flight Center, Greenbelt, Maryland

AbstractThis paper presents the interim results from theSoftware Engineering Laboratory's (SEL) ReuseStudy. The team conducting this study has,over the past few months, been studying theGeneralized Support Software (GSS) domainasset library and architecture, and the variousprocesses associated with it. In particular, wehave characterized the process used to configureGSS-based attitude ground support systems(AGSS) to support satellite missions at NASA'sGoddard Space Flight Center. To do this, webuilt detailed models of the tasks involved, thepeople who perform these tasks, and theinterdependencies and information flows amongthese people. These models were based oninformation gleaned from numerous interviewswith people involved in this process at variouslevels. We also analyzed effort data in order todetermine the cost savings in moving fromactual development of AGSSs to support eachmission (which was necessary before GSS wasavailable) to configuring AGSS software fromthe domain asset library.

While characterizing the GSS process, webecame aware of several interesting factorswhich affect the successful continued use ofGSS. Many of these issues fall under thesubject of evolving technologies, which werenot available at the inception of GSS, but arenow. Some of these technologies could beincorporated into the GSS process, thus makingthe whole asset library more usable. Othertechnologies are being considered as analternative to the GSS process altogether. Inthis paper, we outline some of issues we will beconsidering in our continued study of GSS andthe impact of evolving technologies.

1. IntroductionSince 1985 the Software EngineeringLaboratory (SEL) has been evolving methods ofsoftware reuse through a series of studies,experiments, pilot projects, and full-fledgeddevelopment projects at the Flight DynamicsDivision (FDD) of NASA’s Goddard SpaceFlight Center (GSFC). The SEL adopted Ada83for these experiments and projects at a timewhen C++ was still relatively unknown. Fromthis Ada work, the SEL determined that object-oriented (O-O) technology was providing thebest reuse benefits within the FDD.

Around 1989-90 the Ada/O-O experiencemerged with an FDD-wide initiative to developa "configurable" flight dynamics attitudesupport system. The result evolved into theGeneralized Support Software (GSS) DomainEngineering Process. By means of this process,the FDD has shifted from developingapplications to configuring applications out ofgeneralized, reusable assets. The term "assets"encompasses design specifications, codecomponents, tools, and standards. To date, eightapplications, supporting two NASA satellitemissions, have been configured from the GSSasset library and delivered to acceptance testing.

A SEL Reuse Study team was tasked to analyzethe GSS process, determine the cost and qualityof the resulting systems, document and evaluateits strengths and weaknesses, and proposemodifications to it. This paper presents thepreliminary results of this SEL study.

The paper examines several relevant cost issues.It compares the cost of investment in the GSSasset library to the investment in previous FDDreuse libraries. It compares the deploymentcosts (design, configuration and testing) ofGSS-based applications to the development


costs of previous FDD applications andcontrasts the resulting cost savings with theinvestment cost in the GSS asset library. Thepaper also demonstrates that the GSS processhas resulted in a significant decrease in the timerequired to field a new application.

In addition to analyzing software metrics suchas effort and cycle time, the reuse study teaminterviewed numerous domain analysts, missionanalysts, component engineers, applicationconfigurers, and application testers who havebeen involved in the GSS process. The studyteam adopted Yu's Actor-Dependency (AD)formalism to model the dependence of variousGSS process actors on other actors andresources. In order to further understand morecomplex actors in this process, the team appliedYu's Agent-Role-Position (ARP) formalism tomake explicit the many different roles one actormay play in the process. (Reference 1)

2. History of FDD Reuse

2.1 Environment of the FDD & SELOver the past decade, the FDD of GSFC hasusually consisted of about 100 civil servantssupported by 300-400 CSC and subcontractorpersonnel. (In the last two years, NASA-widereductions in the workforce have reduced thesenumbers somewhat.) Of these personnel, about40% are software developers or testers. Another40% are operations personnel or FDD analysts.The analysts are the experts in orbitalmechanics, mathematics, or other technicaldisciplines who write the software requirementsfor FDD applications.

The mission of the FDD is to build, deploy, andmaintain space ground systems for NASAscience missions, with emphasis on earthorbiting satellites. Flight dynamics applicationsare essentially scientific data processingsystems: some are institutional (i.e., theysupport multiple missions) and others aremission-specific (i.e., a new one needs to bebuilt for each new spacecraft). Each FDDapplication supports some aspect of spacecraftflight dynamics via one of three domains: (1)attitude determination,4 (2) mission and 4 "Attitude" means the spatial orientation of aspacecraft

maneuver planning, or (3) orbit and navigation.This paper focuses on the evolution of softwarereuse within the attitude determination domainof the FDD.

The SEL is a virtual organization which consistsof civil servants from the software developmentgroup of the FDD, CSC contractors supportingthem, and representatives from the ComputerScience Department of the University ofMaryland at College Park. The SEL has been inexistence for over 20 years, during which time ithas guided, studied, documented, and nurturedsoftware experimentation within the FDD.(Reference 2)

2.2 History of S/W Reuse at the FDD &SEL Prior to GSSDuring the last dozen years, the SEL and theFDD have focused in particular on how toincrease software reuse levels, with theexpectation that this would reduce cost andcycle time. At the beginning of thisexperimentation, the FDD was developingsoftware applications in a FORTRANmainframe environment, achieving a modestlevel of reuse of very low level utilities.Through a series of studies, experiments, pilotprojects, and full-fledged development projects,the SEL and FDD began evolving methods ofsoftware reuse. Efforts were focused in theattitude determination domain, whose class ofmission-specific applications would benefitmost from increases in software reuse.

The SEL learned a great deal about using O-Oand Ada generics for one particular type ofapplication, a simulation test tool whosedevelopment was transferred from the IBMmainframe to an Ada-friendly platform, theDEC VAX. From these experiments andmission projects, the SEL determined that theuse of object-oriented principles, rather than theAda language itself, was providing the primaryreuse benefits within the FDD. (Reference 3)

The bulk of the FDD's mission-specificapplications, the AGSSs, however, continued tobe developed in FORTRAN on the IBMmainframe. The SEL was unable to transfer itsAda practices to the mainframe becauseadequate Ada tools for the mainframeenvironment were lacking. In lieu of this, theFDD applied some domain engineering


concepts to create two FORTRAN reuselibraries for developing AGSSs. One librarywas developed to support AGSSs for non-spinning satellites, and the other for spinningsatellites. The majority of satellites supportedby the FDD, traditionally, are non-spinning.The FDD had some success with the FORTRANreuse libraries, but the results were not truly“generalized” and the libraries grew with eachnew mission and became cumbersome tomaintain. Nonetheless, these were all valuableexperiences on which the FDD was able tobuild.

2.3 Motivation, Goals and Definition ofGSSConcurrent with the SEL-sponsoredexperiments in O-O, was a division-wide FDDinitiative to examine the possibility ofgeneralizing all flight dynamics software so thatin future all applications would be configuredrather than developed. The members of thisteam wrestled with what it means to "configure"an application, as opposed to "develop" anapplication, and came to the conclusion that itwas only possible if an FDD reuse library werebuilt around objects. This decision made the O-O experiments all the more important. Around1989-90 the Ada/O-O experience and the searchfor "configurable" flight dynamics softwareapplications merged and evolved into what wasto become the Generalized Support Software(GSS) Domain Engineering Process.

The GSS process relies upon the GSS AssetLibrary, a library of generalized, configurableapplication components developed by the FDDwith an object-oriented domain engineeringapproach. GSS specifications adhere to astandardized approach for specifying object-oriented classes. This standardization allows theuse of standard rules for the implementation ofeach class, including a generic detailed designfor each class and a system architecture thatallows classes to be configured into a programthat communicates with the FDD's UserInterface and Executive (UIX). By means of theGSS process, the FDD has shifted fromdeveloping applications to configuringapplications out of generalized, reusable assets.The term "assets" encompasses designspecifications, code components, tools, andstandards.

In 1992 the design of the GSS asset library gotinto full swing, followed in early 1993 bycoding of the assets, which were implementedin the Ada83 language and resided on a DECAlpha workstation. In February 1995 workbegan in earnest on configuring the firstapplication from this asset library. To date,eight applications, supporting two NASAsatellite missions, have been configured fromthe GSS asset library and delivered toacceptance testing. These applications run onHP or Sun workstations.

2.4 GSS as an Experience FactoryIn order to carry out process improvementswithin the FDD, the SEL functions as anexperience factory in relation to the project

organization. The project organization consistsof FDD mission analysts, applicationdevelopers, and application testers. The missionanalysts are the FDD personnel whose trainingand experience in orbital mechanics andmathematics qualifies them to write therequirements for FDD applications. As theproject organization goes about its business ofdeveloping applications, the experience factorycollects metrics and lessons learned from them.The experience factory staff stores these data ina database, analyzes the data, suggests andconducts additional experiments, and finallypackages these distilled project organizationexperiences into recommended best practices,estimation models, and software developmenttraining courses, which spread these process

ApplicationDevelopers

Experience Factory:Capture, Analyze, and Package

Experiences

ProjectOrganization:

DevelopApplications

MissionAnalysts

ApplicationTesters

Data BasePersonnel

Researchers

Packagers

metrics &lessonslearned

best practices,est. models,

training

Application

Figure 1: Traditional SEL Experience Factory


improvements throughout the FDD projectorganization. Figure 1 depicts this traditionalrelationship between the project organizationand the experience factory. A heavy dashed lineseparates the two groups. The light dotted lineseparating the mission analysts from thesoftware developers on the project organizationside reflects the fact that traditionally the SELhas not collected metrics from mission analystsin the FDD.

With the development of the GSS Asset Library,the boundaries and scope of the experiencefactory appear to have expanded. Newpersonnel, formerly part of the projectorganization, are now fulfilling experience-factory-type roles. Instead of supplying onlyprocess improvements to the FDD projectorganization, however, these people are alsosupplying product improvements to the FDD inthe form of generalized library assets.

Figure 2 depicts this new dimension to theexperience factory concept at the FDD. A fewformer mission analysts have become domainanalysts. They have designed the GSSarchitecture and written the GSS functionalspecifications for the library assets. At the sametime several applications developers havebecome component engineers and have codedthe classes and categories defined by the GSSfunctional specs. With these assets developed,the project organization then follows astreamlined process for application deployment.Under the new deployment process, a mission

analyst must write the GSS missionspecification that stipulates which GSS classes& categories are required for the application,which of the many parameters associated withthese assets are necessary for this application,and what values need to be assigned to theseparameters. This mission specification ispassed to an application configurer—application developers are no longer needed—and the configurer then instantiates thespecified objects from the generalized classesin the asset library and links them to form thedesired application. The application testersthen test the application and turn it over tooperations.

3. Characterization of theGSS ApplicationDeployment Process

A SEL Reuse Study team was tasked to analyzethe GSS configuration process, determine thecost and quality of the resulting applicationsystems, document and evaluate the strengthsand weaknesses of the process, and proposeimprovements to it. In this section, we describethe preliminary results of this study of the GSSconfiguration, or application deployment,process, which is used to define, configure, andtest an attitude support software application.Below, we describe the methods we used togather and analyze this process information. Inthe sections which follow, we first characterizethe configuration process quantitatively withrespect to its cost, schedule, and the errors in theresulting applications. We then present theprocess graphically and analyze its innerworkings.

To model the GSS configuration process, theteam began by studying documentation andholding informal discussions with managers,task leaders, and a few key technical personnel.At the same time we began to analyze SEL dataon effort, estimates, schedules, and softwarechanges related to the GSS asset library and tothe software applications that were configuredfrom it. As this metrics data analysis wasproceeding, we conducted numerous detailed,structured interviews with people playing avariety of roles related to GSS in order to obtaininformation of sufficient detail to model theconfiguration process.

ApplicationDevelopersConfigurers

Experience Factory:Asset Development

ProjectOrganization:ApplicationDeployment

GSS Asset LibraryFunctionalSpecifications

Class & Category Code

DomainAnalysts

ComponentEngineers

MissionAnalysts

ApplicationTestersConfigured

Application

MissionSpecs

Figure 2. GSS Component Development and Application Deployment Process


3.1 Analysis of Metrics Data

3.1.1 GSS CostsThere are two relevant costs to considerwhen evaluating the GSS project. One isthe cost associated with configuringapplications from GSS components.Figure 3 compares the cost of deployingGSS-based applications to costs in theprevious two eras, and demonstrates thatGSS-based applications can be deployedfor as low as 10% of the cost requiredduring the FORTRAN/Ada reuse era.

Prior to 1985 it cost 58,000 hours todevelop and test the attitude supportapplications for a typical FDD mission.Later, when the FDD was using Ada reuselibraries to develop simulators andFORTRAN reuse libraries to developAGSSs, this cost dropped to 30,000 hoursper mission. In both eras the developmentof the non-real-time system and theutilities required the most effort.

When it came time to support the firstmission with the GSS library, the simulatorwas configured first, and the real-timeportion of the AGSS was configuredsecond. In each case, the GSS asset librarywas still undergoing redesign and growth.The configurers were also evolving theconfiguration process. Consequently, thecost of deploying these first two

applications was more than it hadbeen in the FORTRAN/Ada reuseera. When the time came toconfigure the non-real-time portionof the AGSS and the utilities, theasset library and configurationprocess had stabilized. As a result,this cost only a fraction of thetypical cost from the previous era.With the second GSS-supportedmission, we see even more dramaticsavings. The simulator and thenon-real-time system plus utilitieseach cost on the order of 10% oftheir cost from the FORTRAN/Adareuse era. No real-time system wasrequired for this application.

(no R-Tsystem)

58

0

10

20

30

40

50

60

Pre-1985Reuse

ReuseEra

1st GSSMission

2nd GSSMission

Non-Real-Time System& Utilities Real-TimeSystem

Simulator

3630

2.5

a TP costs removed from application costs for first 2 eras; TPs unecessary in GSS era.b Library maintenance costs included in 2nd era; GSS mission costs include total of 10 Khr ofGSS overhead (library maintenance, etc.)

FORTRAN/Ada

Eff

ort

to

Imp

lem

ent

& T

est

(Th

ou

san

d o

f H

ou

rs) a,

b

Figure 3: Reduced Deployment CostsDue to GSS Process

0

20

40

60

80

100

120

FORTRAN Ada GSSReuseLibrary

Req'tsDev. &Test

?

95

36

40?

15

1985-1993 EraReuse Libraries

Eff

ort

to

Cre

ate

Reu

se L

ibra

ry(T

ho

usa

nd

of

Ho

urs

)

Figure 4: Library Investment Costs in Two Eras

Duration of AGSS Development

0

20

40

60

80

100

120

140

Max. Ave. Min.1st

Mission2nd

Mission

Du

rati

on

(des

ign

-acc

epta

nce

tes

t)

in w

eeks

FORTRAN/Ada Reuse Era GSS Era

Note: GSS era estimates assume project completions by 1/30/97

136

101

61

93

48

Figure 5: GSS Reduces Deployment Cycle Time


The other important cost to remember is theinitial cost of building the GSS library itself.These costs are shown in Figure 4 alongside thecosts to develop and test the FORTRAN andAda reuse libraries from the previous era. Forthe GSS asset library we know that the domainanalysts spent 36,000 hours defining therequirements and the logical design in the GSSfunctional specifications. The componentengineers spent 40,000 hours creating thephysical design and implementing, inspecting,and unit testing the generalized Ada83 classesand categories. We know the effort required todevelop and test the FORTRAN and Ada reuselibraries, but we do not know the hours spent onrequirements, since traditionally the SEL doesnot collect metrics from FDD mission analysts.Even so, we can see that the GSS library wasdeveloped for less than the combined cost ofdeveloping the FORTRAN and Ada reuselibraries, which it replaced.

Figures 3 and 4 further demonstrate that if theFDD continues to deploy GSS-basedapplications for 10% of the cost of thepreceding era, the FDD will recoup its entirelibrary investment cost of 76,000 hours by thefourth GSS supported mission.

3.1.2 Application Deployment Cycle TimeThe GSS process has resulted not only in a greatreduction in the cost of deploying anapplication, but also in a significant reduction inthe cycle time required to deploy an application.Figure 5 reveals that the time to field an AGSSduring the FORTRAN reuse era ranged from 61to 136 weeks, with an average of 101 weeks.The time required to design, configure, and testthe applications for the first GSS-supportedmission was a little less than the average for thepreceding era. The second project, however,was completed in less than half of the averagecycle time for the FORTRAN/Ada era. In fact,it took less time than any project in the previousera. It seems likely that project duration can befurther reduced with this reuse process.

3.2 Process DiagramsAfter gaining an initial understanding of theGSS environment and how it is used, the teamdeveloped a detailed interview guide andconducted structured interviews with most ofthe designers, developers, configurers, and

testers involved in the GSS processes. Once asufficient body of information had beencollected, we began to organize it by modelingthe relevant processes, in particular the GSSconfiguration process.

We chose to use Yu's Actor-Dependency (AD)model to portray the interactions, roles, anddependencies between the actors in the GSSprocesses. Figure 6 is an AD model reflectingthe same level of detail as depicted in Figure 2.The AD diagram reflects how each teamdepends on other teams. The types ofdependencies are

• resource dependencies (depicted by arectangle), which indicate that the dependerrelies on some artifact, document, orinformation from the dependee;

• task dependencies (depicted by a hexagon),which indicate that the depender relies onthe dependee to complete some defined setof steps. The dependee may or may not beaware of the goals of this task;

• goal dependencies (depicted by an oval),which indicate that the depender relies onthe dependee to achieve some well-definedgoal. The depender has a great deal offreedom to determine how to reach thatgoal; and

• soft goal dependencies (depicted by adistorted oval, i.e., a "peanut" shape), whichindicate that the depender relies on thedependee to achieve some goal which is notwell-defined, i.e. the depender anddependee may not agree on, and mustnegotiate, exactly how the goal is to besatisfied.

The following AD diagrams focus more on theGSS application configuration process and showthe relevant roles and dependencies at a lowerlevel of detail.

Figure 7 expands the complex social actors ofFigure 6 into their substructure of agents, roles,and positions. Agents are actual, physicalpeople and groups of people that actorsrepresent. Roles indicate what parts of theprocess an actor is involved in. Positions arethe organizational titles and jobs that an actorholds. Positions generally “cover” one or moreroles, while roles are “played” by an agent, whoalso “fills” one or more positions. In Figure 7,


only some of the relevant dependencies areshown and (for the most part) are not identifiedby type in order to simplify the diagram.

Figure 8 shows, at a high level, the sequences oftasks that must be completed in order toconfigure a GSS application, and the inputs and

outputs of those tasks. Tasks are represented asovals and artifacts (inputs and outputs) asrectangles. Many of the tasks refer to taskdependencies in Figure 6.


Cla

ssge

n

Use

r'sG

uide

GS

SFu

nctio

nal

Spe

cific

atio

n

Mis

sion

Spe

cific

atio

n

GS

SC

lass

es,

Cat

egor

ies

UIX

UIX

pre

-pr

oces

sor

UIX

para

med

itor

GS

SC

ON

reor

der

rese

quen

ce

writ

e_a

pp_

int

Ada

com

pile

r

files list

UIX

libra

ry

linke

r strip

_pa

rsde

lete

_par

sca

t_pa

rs

crea

tedi

spla

yD

B

crea

teco

nfig

.cfg

crea

telo

adm

odul

e crea

teop

er'l

para

-m

eter

DB

crea

teco

ntro

l par

a-m

eter

DB

.ove

rrid

efil

e run

scrip

t

mes

sage

DB in

put

files

conf

ig.c

fglo

adm

odul

eop

erat

iona

lpa

ram

eter

DB

cont

rol

para

met

er D

Bdi

spla

yD

B

mis

sion

expe

rtM

A

DA

CE

user

AT

AC

prov

ide

mis

sion

info

.

deci

de m

issi

onsp

ecifi

c co

deis

sues

prov

ide

GS

S s

pec

ans

wer

s

prov

ide

mis

sion

spe

c

a

nsw

ers

writ

e

spec

mod

spr

ovid

eG

SS

cod

e

a

nsw

ers

gene

rate

gene

raliz

edco

de

Test

Rep

orts

Use

r's G

uide

o

n tim

e

Act

or

AC

= A

pplic

atio

n

Con

figur

erA

T =

App

licat

ion

Te

ster

CE

= C

ompo

nent

E

ngin

eer

DA

= D

omai

n A

naly

stM

A =

Mis

sion

Ana

lyst

LE

GE

ND

:

Res

ourc

e

Task

Sof

t Goa

l

Dep

end

enci

es:

Goa

l

Dep

end

erD

epen

dee

help

runn

ing

a

pplic

atio

n

prov

ide

com

plet

e m

issi

on

spec

Figure 6. Actor-Dependency (AD) Model of GSS Application Deployment Process


CE

posi

tion

deve

lop

code

stds

deve

lop

desi

gnst

ds

disc

ussp

ecm

ods

deve

lop

code

gene

rato

r

prod

uce

clas

ses

writ

eco

dein

spec

tco

de

mod

ifyco

de

run

clas

sgen

prep

are

clas

sgen

inpu

t

answ

erco

dequ

estio

ns

writ

eC

RFs

stud

yG

SS

spec

s

Mar

kN

icho

lson

Pos

ition

Age

nt

Rol

e

Pos

ition

Cov

erag

e

Act

or

Res

ourc

e

AC

= A

pplic

atio

n

Con

figur

erA

T =

App

licat

ion

Te

ster

CE

= C

ompo

nent

E

ngin

eer

DA

= D

omai

n A

naly

stM

A =

Mis

sion

Ana

lyst

LE

GE

ND

:A

gent

s, ro

les,

and

pos

ition

s de

pict

the

in

tern

al s

truct

ure

of c

ompl

ex a

ctor

s

AT

posi

tionco

nduc

tte

st

writ

ete

stpl

an

eval

uate

test

resu

lts

stud

yus

er's

guid

econf

erw

ith AC

Ale

xN

guye

n

stud

ym

issi

onsp

ec

Cla

ssge

n

Use

r'sG

uide

GS

SFu

nctio

nal

Spe

cific

atio

n

Mis

sion

Spe

cific

atio

n

GS

SC

lass

es,

Cat

egor

ies

Jona

than

Glic

kman

Jim

Kas

t

Pat

Cro

use

Dav

eTr

acew

ell

Mis

sion

Exp

erts

MA

posi

tion

writ

em

issi

onsp

ec

spec

ifyne

eded

appl

'ns

spec

ifyne

eded

clas

ses

spec

ifypa

ram

eter

valu

esde

fine

disp

lays

& re

portsrevi

sem

issi

onsp

ec

stud

yS

/Cre

q'ts

answ

erM

. spe

cqu

est'n

s

defin

eO

PS

conc

ept

defin

eS

/Wre

q'ts

lear

nab

out

mis

sion

stud

yG

SS

spec

iden

tify

mis

sing

func

tiona

lity

Mik

eLa

mbe

rtson

conf

erw

ith m

issi

onex

pert

DA

posi

tion

defin

edo

mai

n &

s

ubdo

mai

ns

defin

e ar

ch.&

spe

c.st

ds.

writ

eG

SS

spec

s

defin

eca

tego

ries

& c

lass

es

writ

esp

ecm

ods

deci

dem

issi

onsp

ecifi

c co

de

isue

s

answ

erG

SS

spe

cqu

est'n

s

Bob

Stra

ng

AC

posi

tion

writ

eus

er's

guid

e

stud

ym

issi

onsp

ec

supp

ort

test

ers

answ

erap

plic

atio

nqu

estio

ns

conf

erw

ith C

Ein

vest

-ig

ate

and

fixer

rors

conf

erw

ith M

A

reso

lve

GS

S s

pec

ques

t'ns

stud

yG

SS

spec

s

conf

erw

ith D

A

refe

r DA

ques

t'ns

to C

E

Cla

reE

wal

d

conf

igur

eap

pl'n ru

n,de

bug

appl

'n

crea

te/

gath

erfil

es

UIX

UIX

pre

-pr

oces

sor

UIX

para

med

itor

GS

SC

ON

reor

der

rese

quen

ce

writ

e_a

pp_

int

Ada

com

pile

r

files list

UIX

libra

ry

linke

r strip

_pa

rsde

lete

_par

sca

t_pa

rs

crea

tedi

spla

yD

B

crea

teco

nfig

.cfg

crea

telo

adm

odul

e crea

teop

er'l

para

-m

eter

DB

crea

teco

ntro

l par

a-m

eter

DB

.ove

rrid

efil

eru

nsc

ript

mes

sage

DB in

put

files

conf

ig.c

fglo

adm

odul

eop

erat

iona

lpa

ram

eter

DB

cont

rol

para

met

er D

B

disp

lay

DB

Use

rpo

sitio

n

Jona

than

Glic

kman

stud

yus

er's

guid

e

criti

que

disp

lays

run

appl

'n

Test

Rep

orts

Figure 7: Agent-Role-Position (ARP) Model for GSS Application Deployment Process


Mission SpecGSS

Specs

Tasks

Products

.override file

parameter DBs

load module

display DB

run script

user’s guide

write .override

file

create parameter

DBscreate load

module components

create display

DBwrite run

script

write user’s guide

GSS library

AND

gather input files

input files

Debug

application ready to test dependency

or object problems

parameter problems

GSS spec

errors

GSS code

errors

modify code

modify spec

acceptance test

tested application

display problems

Figure 8: GSS Configuration Tasks


4. Recommendations forImprovements to the GSSConfiguration ProcessAs is often the case, organizational andtechnical details which were overlooked at theproject’s inception have come back in variousforms to threaten the full success of GSS.Despite dramatic reductions in applicationdeployment cost and cycle time, the GSSprocess has not won the full support of allgroups within the FDD. Although FDDmanagement mandated that software developersand analysts would jointly design the GSSprocess, the resulting process is today viewedby many as the child of the software developers,with less than full partnership from the analysts.

But this is more than merely a perception. Thecurrent GSS process provides a good tool thatallows traditional software developers toquickly configure flight dynamics softwareapplications. At the same time, however, thecurrent GSS process contains hurdles formission analysts, whom FDD managementwould like to see making more direct use of theGSS. This is because the GSS process and theGSS documentation are inherently moreunderstandable to the GSS developers andconfigurers than to the majority of FDD missionanalysts. As discussed later, the writing of theinitial mission specification in particular is atask logically performed by mission analysts,but at this time it requires a very technical levelof understanding of GSS. This level ofunderstanding is very difficult, and notnecessarily appropriate, for analysts to achieve.As a result of this, relatively few FDD analystsare currently involved in the GSS process.

As a result of our in-depth characterization ofthe GSS configuration process, we discoveredseveral opportunities for improvement. Some ofthese were synthesized from the comments ofseveral interviewees, while others came directlyfrom GSS developers, configurers, and testers.Most relate to the problem described above (ofthe barriers to use by analysts), but also wouldimprove the GSS process in other ways as well.

4.1 Storing application requirementsSeveral problems were cited that might beameliorated by storing the information

contained in the mission specification indatabase form. First of all, it would facilitatethe reuse of requirements, which is commonfrom one application to another. Instead ofmanually editing reused parts lists, display files,parameter files, etc., database operations couldbe used to modify these elements in thedatabase to help ensure consistency and avoiderrors.

Secondly, it has been stated as a goal of GSSthat eventually mission analysts should be ableto configure attitude software with little or nointervention from GSS developers. There areseveral barriers to achieving this goal, one ofwhich is that the writing of the missionspecification seems to require very specializedskills. This is more than a user interfaceproblem, but using a database format rather thana textual one may help.

Designing and maintaining a database formission and application requirements would notbe a simple task. It would require theborrowing or hiring of a specialist in databasedesign, and a careful analysis of the needs thatthe database is meant to satisfy. Because ofsome of the points discussed above, a databasesystem with an adequate user interface isespecially important. Also, it would be helpfulto be able to integrate this database with otherdatabases used in the environment, e.g.databases used to store new componentinformation.

4.2 Automatic generation ofconfiguration inputsAnother advantage of storing mission-specificinformation in a database is that it wouldfacilitate the automatic generation of some ofthe inputs to the GSS configuration. Generatingthese files at present is tedious and time-consuming. Writing the parts list in particularhas been described as a translation of themission specification from one notation toanother. Such a translation could be automatedif the mission specification were storedelectronically. Even better, the tools whichprocess the parts list could be rewritten so thatthey access the database directly. As mentionedlater, such a database could also facilitate theautomatic generation of some parts of the user’sguide. Also, it is conceivable that a database ofapplication requirements could also be used to


automatically generate the artifacts needed asinput to UIX (the user interface facility),including the display files, the parameter files,and the message files.

4.3 Support for learning GSSAs mentioned earlier, the specialized skillsrequired for writing mission specifications seemto be a barrier to making GSS usable by missionanalysts. Making the mission spec database-based rather than a textual document may helpsomewhat. However, it does not solve the rootproblem, which is that writing the missionspecification involves choosing the properconfiguration of GSS components for aparticular mission. This requires a level ofunderstanding of the GSS architecture that, upuntil now, mission analysts have been unable orunwilling to attain. This problem has bothorganizational and technical aspects. Analystswere not involved enough in the development ofGSS to give them any sense of ownership.Thus, they are not highly motivated to take thetime necessary to learn to use GSS. Motivationis further inhibited because, up until now, oneparticular analyst has been willing to take on thetask of writing mission specifications for allmissions using GSS-based software. From atechnical point of view, the currentdocumentation on GSS (the GSS functionalspecifications) are written by and for softwaredevelopers, not mission analysts. Their size andtechnicality are daunting, to say the least, andtheir organization is closely tied to theorganization of the software, which is notnecessarily the most logical from a user’s pointof view.

Thus, if GSS is to achieve the goal of beingfully usable by mission analysts, a serious effortmust be made to support learning. There is agrowing area of research and development insoftware engineering in object-orientedframeworks; for example, the SEL is studyinglearning and reading techniques for frameworks(Reference 4). GSS fits the definition of an O-Oframework, which is a domain-specificrepository of software classes which fit into acohesive architecture designed specifically forthe domain. To the best of our knowledge, GSSis the only O-O framework specific to the flightdynamics domain. However, much of what hasbeen learned about how to support the learning

of frameworks in other domains could beapplicable here. A number of strategies havebeen used: cookbooks of application templatesand variations, example applications,documented class hierarchies, etc. Oneapproach may be to develop a scenario-drivenoverlay for the GSS functional specificationswhich helps organize the specificationsaccording to user scenarios. Many of thesetechniques could be useful in helping missionanalysts understand GSS sufficiently to beginproducing their own applications.

Designing learning support materials for GSSwould involve some experimentation todetermine which strategies are most helpful formission analysts. This would require someinvestment of time and resources, and a seriouscommitment to finding an appropriate solutionfor the FDD domain and organization. It is alsocrucial that the support materials are designedfor the most part by mission analysts, notsoftware developers. The involvement ofmembers of the analyst branch of FDD isnecessary to ensure that the materials, and GSS,will be used in the future.

4.4 User’s GuideUser’s guides are required to be delivered to theacceptance testers with the application, but theyare usually not completed until well after thatpoint. Testers usually do not have themavailable in time to help with testing at all.Instead, they rely for the most part on themission specification. However, the testers didnot seem to see this as a big problem. Theconfigurers, on the other hand, were not highlymotivated to write user’s guides and it wastreated as a necessary but low-priority chore. Asuggested improvement, then, is first todetermine what information is really useful inthe user’s guide (for both testers and eventualusers), then to investigate the possibility ofautomatically generating parts of the user’sguide from the mission specification (this mightbe facilitated by the database suggested earlier),and finally, if necessary, assign a qualifiedtechnical writer to take on the writing of user’sguides, as a task apart from configuration of theapplication.


5. New Directions for ReuseStudyHaving characterized the GSS process, theReuse Study Team will concentrate in thecoming months on putting this process intoperspective, particularly with respect to itschanging technical and organizational context.First of all, a number of technological advanceshave taken place in software engineering sincethe inception of GSS. These advances may berelevant to how GSS is used in the future.Furthermore, some developments in themarketplace have produced alternativeapproaches to reuse. Some of these may beappropriately used instead of GSS in somecases. The focus of the Reuse Study Team inthe near term will be to study which of theseemerging technologies could best beincorporated into GSS and how, and under whatconditions GSS could be supplanted withtechnology that is now available elsewhere. Wehope to evolve guidelines to be used by FDDmission teams in choosing how best to producetheir software applications. In the sectionsbelow we outline some of the issues on whichwe will concentrate.

5.1 Evolving TechnologiesOver the years that the GSS has been evolving,many technologies have been evolving in themarketplace. Some of these technologiesrequire a second look to see how they compareto the GSS process today. It may be that theGSS process could benefit from incorporatingsome of these technologies.

5.1.1 Object OrientationThe GSS assets have been built from an object-oriented perspective since its inception. Inmany ways, the development of GSS was aheadof its time, in that tools and techniques fordeveloping object-oriented systems were notavailable when the GSS team needed them. Forexample, the only object-oriented programminglanguages that were available at the inception ofGSS were Ada83 and Smalltalk. Now, otherlanguages are available, such as C++ andAda95, along with supporting tools. We willconsider whether or not GSS suffered from nothaving these languages and tools available, andif any of the currently available languages and

tools might be useful in the future maintenanceof GSS. The software engineering field alsoknows more now about such topics as object-oriented design, testing, and maintenance. Newadvances need to be examined to determinetheir applicability to GSS.

5.1.2 Graphical User InterfacesA User Interface and Executive (UIX) wasdeveloped by a separate group of FDDdevelopers, in parallel with GSS, to provideGUI capability for GSS-based applications. Itwas decided to develop the GUI capability in-house because, at that time, no appropriate GUIpackages were available in the commercialmarket. That is no longer the case, so it isappropriate to compare UIX to what is currentlyavailable commercially, off-the-shelf (COTS).It may be cost-effective to replace UIX with amore user-friendly and robust GUI capabilitydeveloped elsewhere.

5.1.3 Other COTS ProductsTo support the GSS process, a number of toolshave been developed in-house, such as codegenerators and editors. Most of these weredeveloped in an ad hoc (as needed, as timepermitted) manner. As the sophistication andquality of currently available COTS productshas risen, we will investigate whether somecould be used to support the GSS process.Some COTS products may even be appropriateto replace the GSS process in some cases, asdiscussed below.

5.2 Alternative Reuse ProcessesFor several years, the FDD has been slowlydeveloping more and more software on UNIXworkstations and weaning itself from itstraditional reliance on the IBM mainframe. Inthe 1990s the FDD began to develop some of itsattitude support software for execution on UNIXworkstations rather than on the IBM mainframecomputer. For example, the AGSSs supportingthe three most recent operational satellites(SOHO, SWAS, and XTE) ran partly on theIBM mainframe and partly on the UNIXworkstations. Since the FORTRAN reuselibraries resided only on the mainframe, thesubsystems based on the workstations had to bewritten essentially from scratch. The GSS


strategic reuse library was designed entirely forUNIX workstations, and would have beenuseful for these subsystems, but it was not yetavailable.

The movement from the mainframe toworkstations received a big impetus near theend of fiscal year 1995, when FDD managementmandated that all software would be removedfrom the IBM mainframe computers by the endof fiscal year 1996. Consequently, much of theinstitutional and mission-specific FORTRANcode on the IBM mainframes needed to beported to workstations in a hurry.

It was initially decided that the mainframeportions of the three most recent operationalAGSSs would be re-implemented on theworkstations by configuring them from the GSSlibrary. In order to continue supporting theolder legacy missions, however, an alternativemethod was sought. Since these AGSSs werebuilt primarily from the FORTRAN reuselibraries and ran entirely on the mainframe, itwas decided to port these libraries to theworkstations.

The FORTRAN reuse library used forsupporting non-spinning satellites was rehostedby two mission analysts with considerablesupport from some COTS products. FORTRANsubroutines were edited using word processorsin order to conform to language restrictions ofthe COTS products. The analysts followedsome process shortcuts and made liberal use ofcertain language features provided by the COTSproducts. During this rehost, the libraryspecifications were not rigorously followed andwere not updated to reflect the rehosted versionof the library. Another FORTRAN reuselibrary, used to support spinning satellites, wasrehosted by software developers, using the sameCOTS products. However, they closelyfollowed the library specifications and madelittle attempt to take advantage of languagefeatures unique to the COTS products.

The analysts who rehosted the first libraryenjoyed using the COTS product anddemonstrated that the rehost could be donecheaply and quickly. They found that they hada lot of control over the process and were able,because of their position, and/or the features ofthe COTS products, to rapidly make changes tothe library during the rehost. As a result of theirfavorable experience, the rehosted libraries,

together with their COTS umbrella, are nowviewed as an alternative process for supportingnew FDD missions as well as legacy missions.

In addition to these COTS products used forrehosting attitude determination systems, thereare additional COTS products that can meetvarious other parts of typical FDD missionrequirements. Some of these products arealready being reviewed and adopted to supportmission/maneuver planning and orbit/navigationrequirements for upcoming FDD missions.

The Reuse Study Team has been charged withstudying the processes associated with themaintenance and reuse of GSS, as well as thosethat utilize the rehosted FORTRAN reuselibraries in the development of mission supportsoftware. Our work thus far has resulted in adetailed understanding of the GSS configurationprocess, described in the previous sections. Aswell, we have come to some understanding ofthe questions around which to focus thiscomparison. These questions represent somepoints of disagreement between COTS and GSSproponents, some concerns raised by developersand users of both approaches, and our ownanalysis of interview data. These questions arepresented in the sections below.

5.2.1 User InterfaceGSS uses a unified user interface called UIX forall applications. UIX was developed in-house,in parallel with GSS. This has caused someproblems in the testing of GSS, when errors turnout to be UIX errors, not errors in the GSS code.The use of UIX also requires the handling andformatting of a number of large files(parameters, displays, messages) in configuringan application, which can be tedious and error-prone.

Many COTS products provide their own GUIcapability, which is used to create a userinterface for each application. This interface isnot necessarily consistent.

How important is a unified user interface? Howdifficult would it be to unify all the COTS-baseduser interfaces?


5.2.2 Is Object-Oriented TechnologySuperior?The rehosted libraries are written in a procedurallanguage associated with the COTS productsused to support the rehost, in some cases fromscratch and in others converted fromFORTRAN code using a text editor. GSSapplications are mostly Ada83 with a smallamount of C code in some cases. Thus, the GSSlibrary is based on O-O concepts, whereas therehosted libraries, and their related applications,are not. Prior to GSS, the SEL determined thatthe use of Ada and O-O concepts in the FDDresulted in smaller systems to perform morefunctionality, while the FORTRAN reuselibraries continued to grow in size.

Since they are based on FORTRAN, will therehosted reuse libraries continue to have thesame disadvantages (in particular, code growth)as did the original FORTRAN libraries? If so,this makes the FORTRAN libraries a lessattractive choice compared to O-O Ada reuselibraries. Or is there some attribute of the COTSproducts or the rehosting process whichmitigates these disadvantages?

5.2.3 Software Engineering PracticesThe design of the rehosted libraries reliesheavily on the use of Global COMMON data.The software elements of the resultingapplications are very tightly coupled to thesedata structures. Also, as mentioned earlier, oneof the rehosted libraries has a code structurewhich mirrors the original FORTRAN structurevery closely. Some developers also expressedconcern that the rehosting efforts did not followstandard software engineering practices, such asinspections. On the other hand, it could beargued that rehosting does not warrant such ahigh process overhead because it is based onsoftware that has been in operation for a longtime.

GSS, on the other hand, was developed inaccordance with more modern O-O conceptsand practices. A rigorous software engineeringprocess was followed, including design andcode inspections and rigorous testing.

Does the use of O-O concepts and softwareengineering practices really make a difference inthis case? Or does the fact that the rehosted

software is based on such a time-tested librarymake up for its deficiencies in this area?

5.2.4 MaintenanceBoth FDD COTS users and GSS proponentsstress the advantages of their respectiveapproaches for maintenance. The systems basedon the rehosted libraries are argued to be easilyand quickly modified by someone who isfamiliar with the domain, but not necessarilywith software development. That is, an analystdoes not have to rely on a software developer tomake every change required. Using a GSS-based application, on the other hand, requires adelay whenever a change is requested, oftenuntil the next release of the GSS library. Thususing the MATLAB-based rehosted librariesprovides users much quicker turnaround time onmodifications of the application than does usingGSS.

GSS proponents argue, on the other hand, thatany system will degrade over time if it isallowed to be changed unsystematically byusers. Also, the structure of GSS was designedto facilitate change without adding complexityor large amounts of new code.

Is it more important for the user to have quickturnaround on requested changes, or to managethe evolving structure of the software? Is therea reasonable compromise between the two? Dothe COTS-based applications become moredifficult to maintain the larger the applicationis? Does the design of GSS really ensure that itwill not degrade over time?

Are developers and analysts using different timescales (i.e., "quick" is 1 hr. for an analyst, but 1day for a developer?)? Are developers andanalysts looking at different scopes of themodification process (i.e., a developer looks athow quick it is to change the code, whereas ananalyst looks at how long he has to wait to getthe revised)?

5.2.5 PerformanceThe applications based on the rehosted librariesare interpreted, not compiled. In some cases thesource code was automatically converted to C,then compiled. This compilation step improvesprocessing speed by a factor of two, but stillremains slower than traditional FDD


applications. How much slower are the COTS-based applications than GSS-based applications,and is this difference noticeable or important tousers?

5.2.6 ReliabilityThe AGSSs based on the rehosted libraries relyheavily on the intrinsic capabilities of theunderlying COTS software for performing anumber of mathematical manipulations. Caremust be given to separate out errors in theCOTS software from errors in the customdeveloped portions of the code. GSScomponents, on the other hand, have exhibitedvery low defect levels in acceptance testing. Noapplications of either approach, however, havebeen operational for long enough to assess fieldreliability.

What assurances do we have of the reliability ofCOTS products? How can it be assessed?

5.2.7 PortabilityThe applications based on the rehosted librariesare all designed to be part of a single systemusing the GUI provided by the COTS productused in the rehost. This makes porting thecomponents relatively easy for any targetplatform which supports that product. On theother hand, there were some difficulties recentlyin porting one of the GSS-based AGSSs fromthe HP to the Sun workstations because UIX(the user interface which GSS uses) had notpreviously been ported to the Sun.

How important a criteria is portability? Can UIXand GSS be made more portable in the future?

5.2.8 DocumentationDuring the porting of one of the FORTRANlibraries, the original FORTRAN code structurewas followed very closely. Thus, the originalspecifications for the FORTRAN software arestill valid for the rehosted version. However,none of the advanced features of the COTSproducts were used which would have allowed amore efficient restructuring of the code. Thesefeatures were used heavily in the porting of theother FORTRAN reuse library. As aconsequence, the code is more compact than itwas, but the original software specifications areno longer valid and no new specifications have

been written. The analysts who were responsiblefor porting the libraries believe that, to a certainextent, a separate specifications documentbecomes less necessary because in theprogramming language used (associated withthe underlying COTS products), the equationsare written exactly as they would be written inthe specification.

The design of the GSS system is documented inthe GSS functional specifications, but these are1600 pages long and, as mentioned earlier, are areal barrier to understanding the system for itseventual intended users, mission analysts.However, they seem to provide all relevantinformation necessary for maintaining the GSScomponents, and are written from a softwaredeveloper’s point of view.

Is either type of documentation sufficient foroperation and maintenance purposes? Is theCOTS-based code really self-documentingenough for maintainers to correctly makemodifications? Can users of GSS componentsand applications be taught to use the GSSspecifications effectively?

6. ConclusionsThis paper presents the interim results from theSEL’s Reuse Study. The team conducting thisstudy has, over the past few months, beenstudying the GSS domain asset library andarchitecture, and the various processesassociated with it. In particular, we havecharacterized the process used to configureGSS-based attitude ground support systems tosupport FDD missions. To do this, we builtdetailed models of the tasks involved, thepeople who perform these tasks, and theinterdependencies and information flowsbetween these people. These models werebased on information gleaned from numerousinterviews with people involved in this processat various levels. We also analyzed effort datain order to determine the cost savings in movingfrom actual development of AGSSs to supporteach mission (which was necessary before GSSwas available) to configuring AGSS softwarefrom the domain library.

While characterizing the GSS process, we alsobecame aware of several interesting factorswhich affect the successful continued use ofGSS. Many of these issues fall under the


subject of the evolving technologies, whichwere not available at the inception of GSS, butare now. Some of these technologies could beincorporated into the GSS process, thus makingthe whole asset library more usable. Othertechnologies are being considered as analternative to the GSS process altogether. Inthis paper, we outline some of issues we will beconsidering in our continued study of GSS andthe impact of evolving technologies.

7. References1. Yu, E., "An Organizational ModelingFramework for Multi-Perspective InformationSystem Design," [Conference currentlyunknown], 1993(?).

2. McGarry, F., R. Pajerski, G. Page, S.Waligora, V. Basili, M. Zelkowitz, An Overviewof the Software Engineering Laboratory,Software Engineering Laboratory, SEL-94-005,December 1994

3. Waligora, S., J. Bailey, M. Stark, Impact ofAda and Object-Oriented Design in the FlightDynamics Division at Goddard Space FlightCenter, Software Engineering Laboratory, SEL-95-001, March 1995

4. Basili, V., G. Caleiera, F. Lanubile, F. Shull,"Studies on Reading Techniques," Proceedingsof the Twenty-First Annual SoftwareEngineering Workshop, Greenbelt, MD,December 1996

8. Other SourcesBoland, D., L. Cisney, S. Godfrey, S. Green, T.Gwynn, J. Langston, Upper AtmosphereResearch Satellite (UARS) Attitude GroundSupport System (AGSS) Software DevelopmentHistory, Flight Dynamics Division/GSFC,FDD/552-90/092, November 1990

Briand, L., W. L. Melo, C. Seaman, V. Basili,"Characterizing and Assessing a Large-ScaleSoftware Maintenance Organization," ICSE'95,Seattle, WA, 1995.

Brown, C., R. Coon, J. Langston, D. Spiegel, T.Wood, Internatinal Solar Terrestrial Physics(ISTP) Program/Global Geospace Science(GGS) Project, WIND and POLAR SpacecraftFlight Dynamics Support System (FDSS)Software Development History, Flight

Dynamics Division/GSFC, 552-FDD-93/008R0UD0, March 1993

Condon, S., M. Regardie, M. Stark, S.Waligora, Cost and Schedule Estimation StudyReport, Software Engineering Laboratory, SEL-93-002, November 1993

Coon, R., J. Golder, S. Green, J. O'Neill,Internatinal Solar Terrestrial Physics(ISTP)/Collaborative SolarTerrestrial Research(COSTR) Initiative, Solar and HeliosphericObservatory (SOHO) Mission Attitude GroundSupport System (AGSS) Software DevelopmentHistory, Flight Dynamics Division/GSFC, 552-FDD-95/026R0UD0, November 1995

FDD analysts, developers, and testers,interviews with

FDD/GSFC, MTASS FDSS Overview,Revision 1, Update 1, October 1995

Green, D., T. Gwynn, G. Moschoglou, M.Regardie, L. Lindrose, A. Calder, S. Valett, X-Ray Timing Explorer (XTE) Submillimeter WaveAstronomy Satellite (SWAS) Utilities SoftwareDevelopment History, Flight DynamicsDivision/GSFC, 552-FDD-96/007R0UD0,October 1996


Gwynn, T., M. Mills, M. Regardie, T. Rogers,Submillimeter Wave Astronomy Satellite(SWAS)/X-Ray Timing Explorer (XTE) AttitudeGround Support System (AGSS) SoftwareDevelopment History, Flight DynamicsDivision/GSFC, 552-FDD-95/024R0UD0,September 1995

Kulp, D., P. Myers, M. Regardie, Total OzoneMapping Spectrometer-Earth Probe (TOMS-EP) Attitude Ground Support System (AGSS)Software Development History, FlightDynamics Division/GSFC, 552-FDD-94/031R0UD0, September 1994

MathWorks Web Site,http://www.mathworks.com/ andhttp://www.mathworks.com/matlab.html

NASA/GSFC Software Engineering Laboratory(SEL), The Generalized Support Software(GSS): A Description of Its Current SoftwareDevelopment Process, February 1996

Software Engineering Laboratory: data from itsdatabase

Spiegel, D., J. Doland, Fast Auroral SnapshotExplorer (FAST) Attitude Ground SupportSystem (AGSS) Software Developement History,Flight Dynamics Division/GSFC, 552-FDD-94/040R0UD0, September 1994

Evolving the Reuse Process at the Flight Dynamics Division...

Documents

Transcript of Evolving the Reuse Process at the Flight Dynamics Division...