evolving the reuse process at the flight dynamics division...
TRANSCRIPT
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
SEW21GSS.DOC 2 February 25, 1997
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
SEW21GSS.DOC 3 February 25, 1997
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
SEW21GSS.DOC 4 February 25, 1997
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
SEW21GSS.DOC 5 February 25, 1997
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
SEW21GSS.DOC 6 February 25, 1997
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,
SEW21GSS.DOC 7 February 25, 1997
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.
SEW21GSS.DOC 8 February 25, 1997
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
SEW21GSS.DOC 9 February 25, 1997
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
SEW21GSS.DOC 10 February 25, 1997
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
SEW21GSS.DOC 11 February 25, 1997
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
SEW21GSS.DOC 12 February 25, 1997
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.
SEW21GSS.DOC 13 February 25, 1997
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
SEW21GSS.DOC 14 February 25, 1997
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?
SEW21GSS.DOC 15 February 25, 1997
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
SEW21GSS.DOC 16 February 25, 1997
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
SEW21GSS.DOC 17 February 25, 1997
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
SEW21GSS.DOC 18 February 25, 1997
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