PlanforSoftwareAspectsofCertificationfortheGuidanceandControl

SoftwareProject

KellyJ.Hayhurst

NationalAeronauticsandSpaceAdministration
LangleyResearchCenter
Hampton,Virginia23681

This document was produced as part of a software engineering case study conducted at NASA
Langley Research Center. Although some of the requirements for the Guidance and Control
Software application were derived from the NASA Viking Mission to Mars, this document does not
contain data from an actual NASA mission.

ii

Preface
TheNASALangleyResearchCenterhasbeenconductingaseriesofsoftwareerrorstudiesinaneffortto
betterunderstandthesoftwarefailureprocessandimprovedevelopmentandreliabilityestimationtechniquesfor
avionicssoftware.TheGuidanceandControlSoftware(GCS)projectisthelateststudyintheseries(ref.2).This
project involvesproduction ofguidance andcontrol software forthepurpose ofgatheringfailure data from a
crediblesoftwaredevelopmentenvironment. Toincreasethecredibilityandrelevanceofthisstudy,guidelines
used in the development of commercial aircraft were adopted. The use of the Requirements and Technical
ConceptsforAviationRTCA/DO178Bguidelines,"SoftwareConsiderationsinAirborneSystemsandEquipment
Certification,"isrequiredbytheFederalAviationAdministration(FAA)fordevelopingsoftwaretobecertifiedfor
useincommercialaircraftequipment(ref.1).
ThisdocumentisonepartofthelifecycledatarequiredtofulfilltheRTCA/DO178Bguidelines.Thelife
cycledataareusedtodemonstratecompliancewiththeguidelinesbydescribingtheapplicationoftheprocedures
andtechniquesusedduringthedevelopmentofflightsoftwareandtheresultsofthedevelopmentprocess.Forthe
GCSproject,thelifecycledataconsistsofthefollowing:

PlanforSoftwareAspectsofCertification

SoftwareDevelopmentStandards

SoftwareRequirementsDocument

SoftwareDesignDescription

SoftwareSourceCode

ExecutableObjectCode

SoftwareVerificationPlan

SoftwareVerificationProceduresandCases

SoftwareVerificationResults

SoftwareQualityAssurancePlan

SoftwareQualityAssuranceRecords

ProblemandActionReports

SoftwareConfigurationManagementPlan

SoftwareConfigurationManagementRecords

SoftwareConfigurationIndex

SoftwareAccomplishmentSummary

AGCSimplementation(codewhichfulfillstherequirementsoutlinedintheSoftwareRequirementsData)
runsinconjunctionwithasoftwaresimulatorthatprovidesinputbasedonanexpectedusagedistributioninthe
operational environment, provides response modeling, and receives data from the implementation. For the
purposes of the project, a number of GCS implementations are being developed by different programmers
accordingtothestructuredapproachfoundintheDO178Bguidelines.TheGCSsimulatorisdesignedtoallowan
experimentertorunoneormoreimplementationsinamultitaskingenvironmentandcollectdataonthecomparison
of the results from multiple implementations. Certain constraints have been incorporated in the software
requirementsduetothenatureoftheGCSproject.

Contents
1.INTRODUCTION.....................................................................................................................................................
1.1OVERVIEWOFTHEGCSPROJECT.......................................................................................................................
1.2BACKGROUND......................................................................................................................................................
2.OVERVIEWOFTHEGUIDANCEANDCONTROLAPPLICATION...........................................................
2.1SOFTWAREOVERVIEW........................................................................................................................................
3.CERTIFICATIONCONSIDERATIONS...............................................................................................................
4.SOFTWAREDEVELOPMENTPLAN..................................................................................................................
4.1ORGANIZATIONALRESPONSIBILITY.....................................................................................................................
4.2LIFECYCLEPROCESSES......................................................................................................................................
4.3SOFTWARELIFECYCLEDATA............................................................................................................................
5.PROJECTMILESTONESANDSCHEDULE......................................................................................................
6.CONCLUSION..........................................................................................................................................................
REFERENCES................................................................................................................................................................

iii

1. Introduction
As stated in section 11.1 of the Requirements and Technical Concepts for Aviation RTCA/DO178B
guidelines, "Software Considerations in Airborne Systems and Equipment Certification," (ref. 1) the Plan for
SoftwareAspectsofCertificationforaprojectistheprimarymeansusedbythecertificationauthority,namelythe
FederalAviationAdministration(FAA),fordeterminingwhetheranapplicantisproposingasoftwarelifecycle
that is commensurate with the rigor required for the level of software being developed. To this extent, this
documentcontainsanoverviewoftheGuidanceandControlSoftware(GCS)Projectincluding:

anoverviewoftheguidanceandcontrolapplication,

statementofcertificationconsiderations,

discussionofthesoftwaredevelopmentplan,includingthesoftwarelifecycleprocessesand
correspondingdata,and

theprojectmilestonesandschedule.
Inanefforttoincreaseourunderstandingofsoftware,NASALangleyResearchCenterhasconducteda

seriesofexperimentsoverthepasttwentyyearstogeneratedatatohelpcharacterizethesoftwaredevelopment
process (ref. 2). With an increased understanding of the failure behavior of software, improved methods for
producingreliablesoftwareandassessingreliabilitycanbedeveloped.Thecurrentexperiment,theGCSproject,
wasstartedoriginallyin1985attheResearchTriangleInstitute(RTI)(ref.3)to:(1)collectdataonthefaultsthat
occur during the software life cycle, (2) collect data on faults that occur in operational guidance and control
software,and(3)makeobservationsontheeffectivenessoflifecycleprocessesthatcomplieswiththeDO178B
guidelines. Todothis,theGCSprojectinvolvesthedevelopmentoftwoseparateimplementationsoftheGCS
wherethelifecycleactivitiescomplywiththeRTCADO178Bguidelines.
Thisdocumentpresentsanoverviewofthesoftwarelifecycleactivitiesforthisprojectanddiscusseswhy
various development decisions were made, especially with respect to the experimental nature of this project.
Detailsconcerningtheintegraldevelopmentprocessesarecontainedinthe SoftwareVerificationPlan, Software
ConfigurationManagementPlan,and SoftwareQualityAssurancePlan. Thefollowingsectiongivesageneral
overviewoftheGCSproject.

1.1 Overview of the GCS Project

FortheGCSproject,aGCSimplementationisdefinedtobesourcecodewhichfulfillstherequirements
outlinedinthe GuidanceandControlSoftwareDevelopmentSpecification (ref.4),commonlyreferredtoasthe
GCS specification. The development of two implementations of the GCS will be start from a common
specificationofthesoftwarerequirementsandproceedindependentlythroughthedesign,code,andintegration
processes. AGCSimplementationwillruninconjunctionwithasoftwaresimulatorthatprovidesinputtothe

implementation based on an expected usage distribution in the operational environment, provides response
modelingfortheguidanceandcontrolapplication,andreceivesdatafromtheimplementation.TheGCSsimulator
isdesignedtoallowanexperimentertorunoneormoreimplementationsinamultitaskingenvironmentandcollect
dataonthecomparisonoftheresultsfrommultipleimplementations.Certainconstraintsareincorporatedinthe
softwarerequirementsandprojectstandards(especiallystandardsregardingcommunicationprotocol)duetothe
natureoftheGCSproject.

1.2 Background
ThefirsttaskinthestartoftheGCSprojectin1985wastodevelopthesoftwarerequirementsdocumentfor
theguidanceandcontrolapplication.Theoriginalsoftwarerequirementsfortheguidanceandcontrolapplication
werereverseengineeredfromasoftwareprogramwritteninthelate1960'stosimulatetheVikinglandervehicle
approachingthesurfaceoftheplanetMars(ref.5).EngineersatRTIproducedtheoriginalrequirementsdocument
fortheguidanceandcontrolsoftware,calledtheGuidanceandControlSoftwareDevelopmentSpecification.
Sincetheprojectstartedin1985,theDO178Aguidelines(ref.6)wereoriginallyusedontheprojectasa
modelforthesoftwaredevelopmentprocess.AtRTI,threedifferentprogrammer/analystteamswereassignedto
develop GCS implementations. Because the GCS specification had already been generated, the DO178A
guidelinesweretobeappliedtothedevelopmentprocessstartingwiththedesignofthesoftwareimplementations
fromtheexistingspecification.ThedevelopmentofthreeseparateimplementationsoftheGCSfollowingtheDO
178AguidelineswasstartedatRTI,alongwiththedocumentationofthesoftwaredevelopmentprocessrequiredby
the DO178A guidelines The software development processes for the GCS project included the following
processes:

softwaredesign,

softwarecoding,and

integration.
AllthreeRTIdevelopedimplementationsoftheGCSwentthroughthedesignandcodingprocessesand

wereatvariousstagesoftheintegrationprocesswhentheyweredeliveredtoNASAinthespringof1992.After
consultationwiththeFAA,adecisionwasmadetoextensivelyreviewandrevisetheGCSspecificationandrestart
thesoftwaredevelopmentprocessundertheDO178Bguidelines,whichwerereleasedinDecember1992.Upon
deliverytoNASA,newprogrammerandverificationanalystteamswereassignedalongwithsupportfromnew
System Analysis, Software Quality Assurance, and Configuration Management personnel. However, due to
resourcelimitations,onlytwooftheimplementationsarebeingdevelopedatLangleyResearchCenter.
Due tothetransitioning ofthe project from RTI toNASA along withthe new focus on the DO178B
guidelines,thedecisionwasmadetorevisitsomeoftheoriginaldevelopmentactivities. Thefollowingarethe
softwaredevelopmentprocessesfortheinhouseGCSproject:

transitionalsoftwarerequirementsdevelopment(focusingonthereviewandmodificationoftheexisting
softwarerequirementsdocument),

transitionalsoftwaredesign,(wheretheexistingdesignforeachGCSimplementationdevelopedatRTI
willbemodifiedtomeettherevisedsoftwarerequirements)

softwarecoding,

integration.
ThefollowingchapterprovidesanoverviewoftheGCSapplication,includingabriefdescriptionofthe

software functions. A full account of the software requirements can be found in the Guidance and Control
SoftwareDevelopmentSpecification,whichservesastheSoftwareRequirementsDatafortheGCSproject.

2. Overview of the Guidance and Control Application

According to DO178B, the software requirements process uses the system requirements and system
architecturetodevelopthehighlevelrequirementsforthedesiredsoftware.Correspondingly,DO178Bstatesthat
the PlanforSoftwareAspectsofCertification shouldprovideanoverviewofthesystem. FortheGCSproject,
however,thereisnorealsystemtobedevelopednordocumentationofrealsystemrequirements.TheGCSproject
issolelyaresearchefforttoinvestigatethefaultsthatoccurinthedevelopmentandoperationofsoftware,avionics
applicationsinparticular.TheGCSimplementationswillonlybeexecutedinasimulatedoperationalenvironment
tocollectsoftwarefailuredata.Consequently,theGCSprojectstartedwiththedefinitionofsoftwarerequirements
foraspecificcomponentofaguidanceandcontrolsystem,namelytheterminaldescentphase. Withoutsystem
requirements,certainassumptionsmustbemadeinthedevelopmentofthesoftwarerequirements.Withoutsystem
requirements,therealsoisnosystemsafetyassessmentwhichisanimportantaspectofanydevelopmentprocess
thatneedstocomplywiththeDO178Bguidelines.Lackofsystemrequirementsalsoimpactstheextenttowhich
theprojectwillcomplywiththeDO178Bguidelinessincenotracescanbemadefromthesoftwarerequirements
backtothesystemrequirementsandsafetyassessment.

2.1 Software Overview

The definition of the software requirements for the GCS project focuses ontwo primary needs for the
software:(a)toprovideguidanceandenginecontrolofthelandervehicleduringitsterminalphaseofdescentonto
theplanet'ssurfaceand(b)tocommunicatesensoryinformationtoanorbitingplatformaboutthevehicleandits
descent. The lander vehicle to be controlled includes a guidance package containing sensors which obtain
informationaboutthevehiclestate,aguidanceandcontrolcomputer,andactuatorsprovidingthethrustnecessary
formaintainingasafedescent.Thevehiclehasthreeaccelerometers(oneforeachbodyaxis),oneDopplerradar
withfourbeams,onealtimeterradar,twotemperaturesensors,threestrappeddowngyroscopes,threeopposed
pairsofrollengines,threeaxialthrustengines,oneparachutereleaseactuator,andatouchdownsensor. The

vehiclehasahexagonal,boxlikeshapewiththreelegsandasurfacesensingrodprotrudingfromitsundersurface.
Figure 1 shows a sketch of the lander vehicle during the terminal phase of descent, and Figure 2 shows an
engineeringdrawingofthevehiclefromthreeperspectives.

Figure1.TheLanderVehicleDuringDescent

Use Word 6.0c or later to

view Macintosh picture.

Figure2.EngineeringIllustrationoftheLanderVehicle

Use Word 6.0c or later to

view Macintosh picture.

Ingeneral,theGCSisdesignedtocontrolaplanetarylanderduringitsfinaldescenttotheplanetssurface.
Afterthelanderhasdroppedfromorbit,thesoftwarewillcontroltheenginesofthevehicletothesurfaceofa
planet.TheinitializationoftheGCSstartsthesensingofvehiclealtitude.Whenapredefinedengineignition
altitudeissensedbythealtimeterradar,theGCSbeginsguidanceandcontrolofthelander. Theaxialandroll
engines are ignited; while the axial engines are warming up, theparachute remains connected tothe vehicle.
During this engine warmup phase, the aerodynamics of the parachute dictate the trajectory followed by the
vehicle.Vehicleattitudeismaintainedbyfiringtheenginesinathrottleddowncondition.Oncethemainengines
becomehot,theparachuteisreleasedandtheGCSperformsanattitudecorrectionmaneuverandthenfollowsa

controlledaccelerationdescentuntilapredeterminedvelocityaltitudecontouriscrossed.TheGCSthenattempts
tomaintainthedescentofthelanderalongthispredeterminedvelocityaltitudecontour.Thelanderdescendsalong
thiscontouruntilapredefinedengineshutoffaltitudeisreachedortouchdownissensed.Afterallenginesareshut
off,thelanderfreefallstothesurface.
Figure3showsthephasesoftheterminaldescenttrajectoryofthelander.Withthecontrollawsspecifiedin
thesoftwarerequirements,theprobabilitythatthelanderwillsafelylandontheplanetssurfaceshouldbeatleast
0.95;thatis,givenalargenumberofsimulatedtrajectories,thelandershouldsuccessfullyland(asopposedto
crashing)ontheplanetssurfaceatleast95%ofthetime.
Thefollowingsectionconcernsthecertificationaspectsregardingthisguidanceandcontrolapplication.
Figure3.ATypicalTerminalDescentTrajectory

Use Word 6.0c or later to

view Macintosh picture.

3. Certification Considerations
ThetwoprimaryfunctionsoftheGCSare:(1)toprovideguidanceandenginecontrolofthelandervehicle
duringitsterminalphaseofdescentontotheplanet'ssurfaceand(2)tocommunicatesensoryinformationtoan
orbitingplatformaboutthevehicleanditsdescent.AlthoughthereisnotasystemsafetyassessmentfortheGCS
project,itisassumedthatthelossofeitherofthesefunctionscouldcauseorcontributetoacatastrophicfailure
conditionforthevehicle.Consequently,theguidanceandcontrolapplicationasdefinedintheGCSspecification
isconsideredtobeLevelAsoftware,requiringthehighestlevelofefforttoshowcompliancewiththecertification
requirements.SincetheGCSisassumedtobeLevelA,(asopposedtoalowerlevelrequiringlessefforttoshow
compliance),nojustificationforthisratingisprovided.

4. Software Development Plan

As discussed in chapter 1, the software development processes for the GCS project consist of the
requirements,design,code,andintegrationprocesses,wheretheprojectartifactsfromtherequirementsanddesign
processesaremodificationsofartifactsproducedduringtheoriginaleffortatRTI. Ingeneral,thedevelopment
processesfollowamodifiedwaterfalllifecyclemodelasshowninFigure4.Inthisfigure,theplanningprocessis
shownatthetoplevel,andthisprocessfeedsintotherestofthelifecycleactivities.Then,thesoftwarequality
assurance(SQA)processmonitorstherestofthelifecycleprocesses,andtheconfigurationmanagementprocess
controlstheartifactsproduced. Foreachofthefourdevelopmentprocesses,thereissomelevelofverification
activities.Notethattheverificationactivityintherequirementsprocessonlyconsistsofaninformalreviewofthe
softwarerequirementsdocument,largelybecausethereisnosystemrequirementsdocumentorsafetyassessment
fortheproject. Aftertherequirementsprocess,theremainderofthelifecycleactivitiesareintendedtocomply
withDO178B.
Thefollowingsectiondescribestheorganizationalresponsibilitiesforalllifecycleactivitiesandprovides
moredetailsonthelifecycleprocessesandproducts.

4.1 Organizational Responsibility

The GCS project involves two independent teams, where each team, consisting of a programmer and
verificationanalyst,istaskedtodevelopasingleGCSimplementationaccordingtotheDO178Bguidelines.The
two GCS implementations have been assigned planetary names: Mercury and Pluto. In addition to the
programmer andverification analyst teams,other project personnel areassignedtheroles ofSoftware Quality
Assurance(SQA)representative,SystemAnalyst(responsibleforthesoftwarerequirements),andConfiguration
Manager.Duetoresourcelimitations,thesoftwareintegralprocessesofSoftwareConfigurationManagementand
SQAwillbeadministeredindependentlyacrosstheimplementations,butthesystemsandindividualsusedtocarry

outtheseprocesseswillbethesame.Forexample,oneconfigurationmanagementsystemwillstorealldataitems
forallimplementations,onepersonwilldoconfigurationmanagementforallimplementations,andonepersonwill
doSQAforallimplementations.Further,therewillnotbeacertificationliaisonprocessfortheGCSproject.Table
1liststhepersonnelassignedtotheGCSproject.
Figure4.LifeCycleActivitiesFlowfortheGCSProject
Use Word 6.0c or later to

view Macintosh picture.

Notethatinarealdevelopmentproject,theSQArepresentativewouldbedifferentthattheproject leaderand
wouldreport toadifferent management organization. However,duetopersonnel transfersandlimitationson
projectresources,thesamepersonultimatelywasrequiredtoperformbothroles.
Table1givesageneral overviewoftheresponsibilitiesofsixmajorproject roles. SincethetwoGCS
implementations are toproceed independently through the development process, special constraints have been

placed onthelevel ofcommunicationallowedamongtheproject participants. Inparticular,theprogrammers

should not communicate with each other about their implementations, and the verification analysts are not
permittedtodiscussspecificdetailsabouttheirimplementations.The SoftwareDevelopmentStandards contains
moredetailsonthecommunicationprotocolforallprojectparticipants.
Table1.GCSProjectPersonnelandOrganization

ProjectRole

Responsible
Personnel

Organization

Responsibility

ProjectLeader

KellyHayhurst

SystemValidation
MethodsBranch
(NASALaRC)

ManagingalloftheactivitiesoftheGCSproject,
includingprovidingplanning,technicaldirection,and
coordinationwithrespecttoalllifecycleprocesses,
collectingandanalyzingdata,andschedulingthemajor
milestonesoftheprojecttomeetthegoalsoftheproject.

SQArepresentative

KellyHayhurst

ConfigurationManager

LauraSmith

SystemValidation
MethodsBranch
(NASALaRC)

BerniceBecher

SystemValidation
MethodsBranch
(Lockheed)

MercuryProgrammer

AndyBoney

ComputerScience
Corp.

PlutoProgrammer

PaulCarter

ComputerScience
Corp.

MercuryAnalyst

DebbieTaylor

ComputerScience
Corp.

PlutoAnalyst

RobAngellatta

SystemValidation
MethodsBranch
(Lockheed)

SimulatorOperator

BerniceBecher

SystemAnalyst

Providingconfidencethatthesoftwarelifecycle
processesproducesoftwarethatconformstoits
requirementsbyassuringthatprojectactivitiesare
performedincompliancewithDO178Bandproject
standards,asdefinedintheplanningdocuments.
Providingconfigurationmanagementofalllifecycle
data(documentation,design,code,testcases,and
simulator)associatedwiththedevelopmentoftheGCS
implementations.inaccordancewiththeDO178B
guidelinesandprojectstandards.
Providingexpertiseregardingthesoftwarerequirements
fortheguidanceandcontrolsystem(describedinthe
GCSspecification)toprojectparticipants,and
maintainingtheGCSspecificationinaccordancewith
theDO178Bguidelinesandprojectstandards.

Programmers
Independentlydevelopingoneimplementationofthe
guidanceandcontrolsoftwareaccordingtotheGCS
specification,DO178B
guidelines,andtheSoftwareDevelopmentStandards.
Thisincludesthegenerationofthedetaileddesign
description,sourcecode,andexecutableobjectcode.

VerificationAnalysts
Definingandconductingalloftheverificationactivities
associatedwiththedevelopmentofoneGCS
implementationaccordingtothe
GCSspecification,DO178Bguidelines,andthe
SoftwareDevelopmentStandards.

Developing,maintaining,anddocumentingtheGCS
simulator.Also,assistsinrunningexperiments.

10

4.2 Life Cycle Processes

Atahighlevel,thesoftwarelifecycleprocessesfortheGCSprojectconsistof: thesoftwareplanning
process,thesoftwaredevelopmentprocesses,andtheintegralprocesses. Thesoftwareplanningprocessdefines
and coordinates the software development processes and the integral processes. The software development
processes are made up of the software requirements, software design, software coding, and the integration
processes;thoseprocessesthatdirectlyproducethesoftwareproduct.Theintegralprocessessurroundthesoftware
development processestoensurethecorrectness,control,andintegrityofthesoftware products. Theintegral
processesarethesoftwareverification,configurationmanagement,andqualityassuranceprocesses.Table2shows
theobjectivesforeachofthelifecycleprocessesbasedonthetablesinAnnexAofDO178B.
Table2.ActivitiesandProductsoftheLifeCycleProcesses
ProcessObjectives

MajorActivities

Products

PlanningProcess
DefineDevelopmentand
IntegralProcesses

Reviseprojectplanningdocumentsfrom
RTItocomplywithDO178B

transitioncriteria

PlanforSoftwareAspectsofCertification
SoftwareDevelopmentStandards
SoftwareVerificationPlan

lifecycle

SoftwareConfigurationManagementPlan

projectstandards

SoftwareQualityAssurancePlan

DevelopmentProcess
Definehighlevel
requirements

ModifyGCSspecification(highlevel
requirements)

RevisedGCSspecification(includingany
derivedrequirements)

Definelowlevel
requirements&software
architecture

Update(RTIgenerated)detaileddesign
descriptions(usingTeamwork)

DetailedDesignDescriptionforMercury
andPluto(beforeDesignReview)

Developsourcecode

CleanlycompiledversionofMercuryand
Plutosourcecode(beforereview&
testing)

DevelopSourceCode
GenerateExecutableObject
Code
Identifyderivedrequirements
SoftwareQualityAssurance
Process

Reviewallprocessesandproductsfor
Assurethatdevelopmentand
compliance
integralprocessescomply
withplansandstandards
Participateindesign,code,andtestcase
reviews
ConductConformityReview
Conductsoftwareconformityreview

11

SQARecordsfromallreviewsforeach
implementation

Table2.(cont.)ActivitiesandProductsoftheLifeCycleProcesses
ProcessObjectives

MajorActivities

Products

VerificationProcess
ReviewHighlevel
requirements

ConductTeamDesignInspection

Reviewlowlevel
requirements&software
architecture

VerificationProcedures
DevelopandperformRequirementsbased
testingatfourlevels:unit,subframe,
PostDesignReviewDesignDescription
frame,andtrajectory.
forMercuryandPluto

Reviewsourcecode
Testcoverageofallsoftware
requirements(100%
requirementscoverageis
achieved)
Testcoverageofsoftware
structure(multiple
condition/decisioncoverage
isachieved)

ConductTeamSourceCodeInspection

TraceabilityMatrixforsoftware
requirements

Conductanalysisofsourcecode(after
requirementsbasedtesting)todetermine
ifMC/DCisachieved

VerificationResultsforMercuryandPluto
DesignReviews(includingDesignto
RequirementsTrace)

PerformStructurebasedtestingas
necessarytoachieveModified
Condition/DecisionCoverage.

CodereviewedversionofMercuryand
Plutosourcecode
VerificationResultsforMercuryandPluto
Reviews(includingCodetoRequirements
Trace)
RequirementsbasedTestCases
StructurebasedTestCases
MercuryandPlutoversionsthat
completedrequirementsbasedtesting
MercuryandPlutoversionsthat
completedstructurebasedtesting
VerificationResultsforMercuryandPluto
Testing(includingTestcaseto
RequirementsTrace)

ConfigurationManagement
Process
Provideidentificationforall
configurationitems
Providechangecontrol
system
Providearchiveandretrieval
services

Definelabelingsystemforall
configurationitems
Establishachangecontrolsystemusing
theCodeManagementSystem(CMS)

ConfigurationManagementIndex
LifeCycleEnvironmentConfiguration
Index
ConfigurationManagementRecords

DevelopaProblemandActionReporting CompletedProblemandActionReports
SystemforDevelopmentProducts(CC1)
CompletedSupportDocumentation
andSupportDocumentation(CC2)
ChangeReports
Defineandimplementproceduresfor
archiveandretrieval
Documentandcontrolsoftware
developmentenvironment

12

Aswithalllifecyclemodels,theremustbesomecriteriatoindicatewhentoprogressfromoneprocessto
the other. The primary transition criteria for the development processes is based on the completion of the
verificationofthemainproductsofthoseprocesses.Table3givesthetransitioncriteriafortheGCSdevelopment
processes.
Table3.TransitionCriteriafortheSoftwareDevelopmentProcesses

DevelopmentProcess

Inputs

TransitionCriteriatoNextProcess

Requirements

GCSspecificationfromRTI

Informalreviewofversion2.2oftheGCS
specificationandapprovalbytheprojectleader.

Design

version2.2oftheGCS
specification

CompletionofallproblemreportsfromtheDesign
Review.(SQAapprovalisrequiredforcompletion
ofproblemreports.)

Code

DesignDescription

CompletionofallproblemreportsfromtheCode
Review.

SourceCode

Review,approval,andsuccessfulexecutionofall
requirementsbasedtestcases

Integration

Requirementsbased
Testing

Structurebased
Testing

ExecutableObjectCode
RequirementsbasedTest
cases

Review,approval,andsuccessfulexecutionofall
structurebasedtestcases.

4.3 Software Life Cycle Data

TheprimeobjectiveofthesoftwaredevelopmentprocessesfortheGCSprojectistoindependently(within
theconstraintsoftheproject)developtwoimplementationsoftheGCSandallcorrespondinglifecycledatain
compliance with the DO178B guidelines. The detailed plans for achieving this objective are given in the
following documents: Software Verification Plan, Software Configuration Management Plan, and Software
QualityAssurancePlan.EachoftheseplanningdocumentsmustcomplywiththeDO178Bguidelinesandwill
specifythefollowinginformation:

theinputstothatprocess,includingfeedbackfromotherprocesses,

theintegralprocessactivities,

theavailabilityoftools,plans,methods,andprocedures.

13

Thestandardsforthedevelopmentproducts(requirements,design,andsourcecode)andtheother
project documentationaregiveninthe SoftwareDevelopment Standards. The SoftwareDevelopment
Standards also contains adescription of toolsand methods tobe used during development including
requirements and design methods and programming language. Other fundamental information about
project procedures (such as configuration management and problem reporting) are addressed in the
Software Development Standards so that the document can serve as a single handbook for project
participants.
BecausebothGCSimplementationsaretofollowthesamedevelopmentandintegralprocesses,
only one set of planning documents (Plan for Software Aspects of Certification (which includes the
SoftwareDevelopmentPlan),SoftwareVerificationPlan,SoftwareConfigurationManagementPlan,and
Software Quality Assurance Plan) will be developed for the project along with a single Software
ConfigurationIndex.Mostoftheremaininglifecycledatawillbeimplementationspecific.Table4shows
theresponsiblepartyforthelifecycledatathatcorrespondswitheachprocess.
Table4.OrganizationalResponsibilitiesfortheSoftwareLifeCycleActivities
SoftwareLifeCycleProcessActivities
SoftwarePlanning

SoftwareLifeCycleData
PlanforSoftwareAspectsofCertification

Organizational
Responsibility
ProjectLeader

Software Development Standards, including the

SoftwareRequirementsStandards,SoftwareDesign
Standards,andtheSoftwareCodeStandards
SoftwareAccomplishmentSummary
SoftwareDevelopment
TransitionalSoftwareRequirements

GCSSpecification(SoftwareRequirementsData)

SystemAnalyst

TransitionalSoftwareDesign
DesigningtheMercuryImplementation

DesignDescriptionforMercury

DesigningthePlutoImplementation

DesignDescriptionforPluto

MercuryProgrammer
PlutoProgrammer

SoftwareCoding
CodingtheMercuryImplementation

SourceCodeforMercury

CodingthePlutoImplementation

SourceCodeforPluto

MercuryProgrammer
PlutoProgrammer

Integration
Generating Executable Object Code for ExecutableObjectCodeforMercury
Mercury
GeneratingExecutableObjectCodeforPluto

MercuryProgrammer

ExecutableObjectCodeforPluto

PlutoProgrammer

SoftwareVerificationPlan

Mercury&Pluto
Analyst

Integral
SoftwareVerification

SoftwareVerificationProcedures&Requirements
basedTestCases
VerifyingtheMercuryImplementation

StructurebasedTestCasesforMercury
SoftwareVerificationResultsforMercury

14

MercuryAnalyst

VerifyingthePlutoImplementation

StructurebasedTestCasesforPluto

PlutoAnalyst

SoftwareVerificationResultsforPluto
ConfigurationManagement

SoftwareConfigurationManagementPlan
Software Configuration Index (including the Life
CycleEnvironmentConfigurationIndex)

Configuration
Manager

ProblemReportsforMercuryandPluto
SupportDocumentationChangeReports
SoftwareConfigurationManagementRecords
SoftwareQualityAssurance

SoftwareQualityAssurancePlan
SoftwareQualityAssuranceRecords

15

SoftwareQuality
Assurance
Representative

5. Project Milestones and Schedule

Withinarealsoftwaredevelopmentprojectthecertificationauthoritywouldbeinvolvedinthedevelopment
activities,atleasttotheextentofhavingvisibilityintothedevelopmentprocessesastheyprogress.Becausethe
GCS project is a research effort, the resources necessary to provide interaction between the project and the
certificationauthorityarenotavailable. Further,becausethisprojectisnotconfinedbyconstraintsplacedona
typical development project that must meet real production deadlines, a hard deadline schedule will not be
producedforthisproject.However,theprojectdoeshavemilestonesbasedonthedevelopmentprocessesanda
proposedscheduleofthemajorprojectactivities.Table5givesthemajorprojectmilestonesandTable6givesthe
projecthistoryandproposedschedule.
BecausethereisnocertificationliaisonprocessfortheGCSproject,allprojectlifecycledataasshownin
Table4willbemadeavailabletothecertificationauthorityatthecompletionofalldevelopmentprocesses.The
SQArepresentativewillconductasoftwareconformityreviewuponprojectcompletionpriortosubmissionfor
certification.

Table5.GCSProjectMilestones

ProjectPhase

MilestoneswithineachPhase

RequirementsPhase

Releaseversion2.2oftheGCSspecificationtotheprogrammers

DesignPhase

Complete GCS designs to comply with version 2.2 of the GCS

specification

ConductDesignReviews

CompleteallmodificationstothedesignidentifiedinDesignReviews

Initiatedevelopmentofrequirementsbasedtestcases

Developsourcecode

ConductCodeReview

CompleteallmodificationstothecodeidentifiedinCodeReview

Completerequirementsbasedtesting

CompleteanalysisforMultipleCondition/DecisionCoverage

CompleteStructurebasedtestingasneeded

CodePhase

IntegrationPhase

16

Table6.GCSProjectHistoryandSchedule

HistoricalEvents:
DeliveryofGCSlifecycledatafromResearchTriangleInstitute

Date
5/92

Meeting with the FAA (DeWalt and Saraceni) to determine direction for
project

9/20/92

Reviewoflifecycledata(todetermineextentofmodificationsnecessaryby
LaRC)

9/92

ProposedScheduleofEvents:
CompleteModificationoftheGCSspecification(release2.2)

11/93

CompleteModificationandVerificationofGCSDesigns

6/94

CompleteDevelopmentandVerificationofSourceCode

10/94

CompleteDevelopmentofRequirementsbasedTestCases

8/94

CompleteRequirementsbasedTesting

12/94

CompleteStructurebasedTesting

12/94

6. Conclusion
ThisdocumentgivesallprojectparticipantsandthecertificationauthorityanoverviewoftheGuidanceand
Control Softwareproject andthecorrespondingsoftware lifecycleprocessesandproducts. Thisdocument is
intendedtobeusedinconjunctionwiththeothermajorplanningandstandardsdocument( SoftwareDevelopment
Standards,SoftwareVerificationPlan,SoftwareConfigurationManagementPlan,andSoftwareQualityAssurance
Plan)toprovidethebasisforallprojectactivitiesincompliancewithDO178B.

17

References
[1] RTCASpecialCommittee152. SoftwareConsiderationsinAirborneSystemsandEquipmentCertification.
TechnicalReportRTCA/DO178B,RequirementsandTechnicalConceptsforAviation,December1992.
[2] GeorgeB.Finelli.Resultsofsoftwareerrordataexperiments.InAIAA/AHS/ASEEAircraftDesign,Systems
andOperationsConference,Atlanta,GA,September1988.
[3] Janet R. Dunham and George B. Finelli. RealTime Software Failure Characterization, COMPASS'90:
ProceedingsoftheFifthAnnualConferenceonComputerAssurance,June1990.
[4] B.EdwardWithersandBerniceBecher.GuidanceandControlSoftwareDevelopmentSpecification,NASA
ContractorReport(Tobepublished)
[5] NeilA.Holmberg,RobertP.Faust,andH.MiltonHolt. Viking75SpacecraftDesignandTestSummary,
VolumeILanderDesign,NASAReferencePublication1027,LangleyResearchCenter,1980.
[6] RTCASpecialCommittee152. SoftwareConsiderationsinAirborneSystemsandEquipmentCertification.
TechnicalReportRTCA/DO178A,RadioTechnicalCommissionforAeronautics,March1985.