Guidance on Selecting Life Cycle and Development Approach

Developed by: LaRC Software Engineering Process Group (SEPG)

1.1 Purpose
! "#is docu$ent provides guidance on selecting bot# t#e
life cycle and t#e develop$ent approac# for software
being developed at t#e %&S& Langley Researc# Center
(LaRC)! 't supple$ents t#e Langley (anage$ent Syste$
(L(S) software procedures (particularly L(S)CP)
*+,!-: Class &. / and &ll Safety)Critical Software.
L(S)CP)*+,!0: Class C Software. and L(S)CP)*+,!+:
Class D Software) by providing additional infor$ation
t#at Software (anagers $ay find useful!
1.2 Generic Phase Model
! "#e standard way of presenting a life cycle is as a
se1uence of p#ases. w#ere eac# one co$pletes before t#e
ne2t one starts. t#oug#. in practice. p#ases $ay overlap!
Eac# p#ase #as a defined set of outputs as well as p#ase
transition criteria against w#ic# ac#ieve$ent can be
$easured! "#us. software life cycle p#ases provide a
natural set of $ilestones along a pro3ect4s develop$ent!
During and at t#e end of eac# p#ase. progress can be
$onitored. ris5s can be identified. and esti$ates can be
generated! &ll of t#ese ite$s can be used to build and
refine t#e plans for t#e ne2t p#ase as illustrated by 6igure
!
t190a
CONTROLS
NEXT
PHASE
CURRENT PHASE
PRODUCES
INPUTS
ALSO THE BASIS FOR MONITORING PROGRESS
REVIEW
REVIEW
DRAFT
OUTPUTS
OUTPUTS
PLANS
DRAFT
PLANS

Figure 1 Ge!eri" P#a$e M%&e'
70,7890*9!doc of 7
1.3 Selecting the Life Cycle Phase Option
! 6or pro3ects developing safety)critical or Class & t#ru C
software. t#e L(S procedures re1uire t#e pro3ect to
define and docu$ent a software lifecycle! "#e following
guidance for lifecycle selection and tailoring is adapted
fro$ 'EEE:E'& 77,*!,. Standard for Information
TechnologySoftware Life Cycle Processes ;<! 6igure 7
describes t#e full life cycle p#ases (=ptions & and /) as
listed in 'EEE:E'& 77,*!, ;< and basic tailoring options
(C and D)! "#e software life cycle begins w#en eit#er a
software pro3ect4s >Syste$ Re1uire$ents> (i!e!. =ption &)
or >?ser Re1uire$ents> (=ption /) beco$e available! 6or
e2a$ple. one $ig#t receive a re1uest (?ser Re1uire$ent)
to upgrade e2isting software. or one $ig#t receive a
re1uest (Syste$ Re1uire$ent) for t#e develop$ent of
new software to be included in a larger parent pro3ect! 'n
eit#er case. t#e Software (anager ensures t#at t#e
re1uire$ents given to t#e software develop$ent tea$ are
docu$ented and contain t#e re1uired content as specified
in t#e Software Re1uire$ents Specification in L(S)CP)
*+,!+. L(S)CP)*+,!0. or L(S)CP)*+,!- (%ote t#at
L(S)CP)*+,!+ does not specify specific content for t#e
Software Re1uire$ents Specification)!
7! 'n $any instances. software life cycle p#ases can be
co$bined! 6or e2a$ple. use of a C="S grap#ics pac5age
or a C="S database tool $ay si$plify t#e software
design p#ase! 'n t#is case. t#e Software Re1uire$ents.
&rc#itectural Design. and Detailed Design p#ases could
be co$bined into one design p#ase (i!e!. see 6igure 7.
=ption C)! 'n anot#er e2a$ple. a trade)off analysis $ig#t
conclude t#at t#e use of a >virtual code> based C="S tool
suc# as Lab@iew can satisfy t#e $a3ority of t#e re1uester
re1uire$ents! 'n t#is case. $ultiple software p#ases
(Software Re1uire$ents. &rc#itectural Design. Detailed
Design. Code and "est. and 'ntegration) $ay be co$bined
as s#own in =ption D (t#e $ini$u$ life cycle)!
-! "#e Software (anager $ay use t#e basic life cycle
options in 6igure 7 and t#e following e2planatory te2t as
guides in tailoring t#e software life cycle p#ases to t#e
specific pro3ect! &lt#oug# it is not fully illustrated in
6igure 7. all four life cycle p#ased options can begin wit#
eit#er t#e Syste$s Re1uire$ents &nalysis p#ase or t#e
?ser Re1uire$ents p#ase. depending on w#et#er or not
t#ere is an enco$passing syste$s)level pro3ect!
70,7890*9!doc 7 of 7
Software Life Cycle Phases
User
Requirements
Software
Requirements
Analysis
Software
Architectural
Design
Software
Detailed
Design
Software
Coding and
Testing
Software
Integration
Software
Qualifcation
Testing
System
Requirements
Analysis
System
Architectural
Design
System
Integration
System
Qualifcation
Testing
Software
Installation
Software
Acceptance
Software
Operations
Software
Maintenance
Design
A
!
C
D
System Life Cycle Phases
Life Cycle Options
Software
Installation
Software
Acceptance
Software
Operations
Software
Maintenance
Software
Installation
Software
Acceptance
Software
Operations
Software
Maintenance
Software
Qualifcation
Testing
Software
Qualifcation
Testing
User
Requirements
User
Requirements
Coding and
Testing
Coding and
Testing
6igure 7! Software life)cycle p#ase options!
Descriptions of software life)cycle p#ase options in 6igure 7:
Option A: "#e software pro3ect is part of an enco$passing syste$ pro3ect wit# syste$
re1uire$ents! "#ese syste$ re1uire$ents (as L(S)CP)*+,!0 and L(S)CP)*+,!-!specifies) are
Aflowed downB to software level re1uire$ents and additional software re1uire$ents are AderivedB
in t#e process! 'n =ption &. t#e software supplier supports $any of t#e syste$ level activities
t#roug#out t#e life)cycle p#ases!!
Option : "#e software pro3ect is not part of an enco$passing syste$ pro3ect and starts wit# t#e
sub$ission of user re1uire$ents! Cowever. t#e pro3ect is large or co$ple2 and re1uires t#e rigor of
t#e full life cycle! ("#e Auser re1uire$entsB are called Acusto$er and ot#er sta5e#older
re1uire$entsB in L(S)CP)*+,!+. L(S)CP)*+,!0 and *+,!-!)
Option C: "#e software pro3ect is initiated by t#e sub$ission of syste$ or user re1uire$ents!
"#ese re1uire$ents are co$plete. not co$ple2. and can be $apped directly into a single level of
design to define t#e structure of t#e code! /ecause t#ere is no need to distinguis# between t#e
logical or abstract software re1uire$ents $odel and t#e p#ysical or concrete design $odel
generated as part of t#e arc#itectural design in t#is e2a$ple. so$e p#ases (Software Re1uire$ents
&nalysis. Software &rc#itectural Design. and Software Detailed Design) are co$bined into a single
design p#ase! &lso. t#e use of ob3ect)oriented $et#ods can $ini$iDe t#e distinction between t#ose
p#ases!
Option !: "#e software pro3ect is initiated by t#e sub$ission of syste$ or user re1uire$ents!
Eit#er t#e software is very si$ple and is co$prised of no $ore t#an a few co$ponents. so t#at
translation of re1uire$ents into code is straig#tforward. or $odifications to e2isting code are
si$ple and do not re1uire c#anges in t#e corresponding software design!
70,7890*9!doc - of 7
%ote: "#e 'EEE docu$ent. Developing a Software Project Life Cycle Process ;7< also provide
guidance on defining a life cycle for a pro3ect!
0! 'n 6igure 7. Software 'nstallation. &cceptance. and
=perations p#ases are s#own as das#ed bo2es because
t#ey $ay be o$itted if not appropriate (e!g!. if t#e
software is not being transferred outside t#e developing
organiDation or to a different environ$ent for operations.
or if an operations p#ase is not applicable)! 'n so$e cases.
software is created wit# no intention of reuse or
$aintenance! 6or t#is reason. t#e $aintenance p#ases are
also s#own as das#ed bo2es!
+! & nu$ber of factors influence t#e c#oice of life cycle.
including siDe. class. and t#e develop$ent approac#! "#e
full life cycle is usually adopted for large software
pro3ects and is strongly reco$$ended for $ediu$
software pro3ects! 6or s$aller software pro3ects. p#ases
can be co$bined to suit t#e si$plicity of t#e wor5 being
underta5en! &lt#oug# t#e life cycle c#oice is based on
$any considerations. a fuller life cycle option $ay be
re1uired by t#e re1uester or t#e parent pro3ect! "#e p#ases
in 6igure 7 are illustrated using a EwaterfallF approac#!
=t#er approac#es are discussed in section 0!
9! "#e software life cycle p#ases s#own in 6igure 7 are
briefly described below! (%ote: t#e descriptions below are
su$$aries of te2t in 'EEE:E'& 77,*!,. Standard for
Information TechnologySoftware Life Cycle Processes
;<!)
Syste" #e$uire"ents Analysis: "#e specific intended use of t#e syste$ to be developed is
analyDed to specify syste$ re1uire$ents! "#e Syste$ Re1uire$ents Specification describes:
functions and capabilities of t#e syste$G business. organiDational and user re1uire$entsG safety.
security. #u$an)factors engineering. interface. operations. and $aintenance re1uire$entsG and
design constraints and 1ualification re1uire$ents!
Syste" Architectural !esign: "#e top)level arc#itecture of t#e syste$ is establis#ed! "#e
arc#itecture identifies ite$s of #ardware. software. and $anual)operations! 't ensures t#at all
syste$ re1uire$ents are allocated a$ong t#e ite$s!
Soft%are #e$uire"ents Analysis: "#e software re1uire$ents are docu$ented! "#ese software
re1uire$ents are t#e interpretation of t#e syste$ or user re1uire$ents t#at t#e software tea$ uses
to begin develop$ent! "#ey include: functional and capability specifications (including
perfor$ance. p#ysical c#aracteristics. and environ$ental conditions)G interfacesG 1ualification
re1uire$entsG safety and security specificationsG data definitions and database re1uire$entsG user
operation and e2ecution re1uire$entsG and $aintenance re1uire$ents! 'n so$e cases. t#e software
re1uire$ents and t#e syste$ or user re1uire$ents $ay be one and t#e sa$e!
Soft%are Architectural !esign: "#e Software Re1uire$ents are transfor$ed into an arc#itecture
(and integration plan) t#at describes t#e top)level structure and identifies t#e software co$ponents!
Eac# re1uire$ent for t#e software is allocated to one or $ore software co$ponents and is furt#er
refined to facilitate detailed design!
Soft%are !etailed !esign: & detailed design for eac# software co$ponent is developed! Software
co$ponents are deco$posed into lower level software units t#at can be coded. co$piled. and
tested! "#e software re1uire$ents are allocated fro$ t#e software co$ponents to t#e software
70,7890*9!doc 0 of 7
units! Detailed designs of t#e interfaces e2ternal to t#e software. between t#e software
co$ponents. and between t#e software units are also docu$ented!
Soft%are Coding and &esting: "#e software units and databases are developed. coded. co$piled.
tested. and docu$ented!
Soft%are 'ntegration: "#e software units and software co$ponents are integrated in accordance
wit# t#e Software Design Docu$entG t#e aggregate is tested to ensure t#at it satisfies t#e software
re1uire$ents!
Soft%are (ualification &esting: "#e i$ple$entation of eac# software re1uire$ent is tested for
co$pliance and to ensure t#at t#e integrated software is ready for delivery to t#e user or syste$!
Syste" 'ntegration: "#e software configuration ite$s are integrated wit# t#e #ardware ite$s and
$anual operations! &s t#ey are integrated. t#e aggregates are tested against t#eir re1uire$ents!
Syste" (ualification &esting: '$ple$entation of eac# syste$ re1uire$ent is tested for
co$pliance and to ensure t#at t#e syste$ is ready for delivery!
Soft%are 'nstallation: "#e software is installed and t#e installation is validated to ensure t#at
software code and databases initialiDe. e2ecute. and ter$inate as specified!
Soft%are Acceptance Support: &cceptance testing and review of t#e software are perfor$ed!
Soft%are Operations: 6or eac# release. t#e software product undergoes operational testing to
satisfy t#e specified criteria prior to t#e release of t#e software product for operational use! "#e
syste$ is operated in its intended environ$ent according to t#e user docu$entation! &ssistance
and consultation are provided to t#e users as re1uested! ?ser re1uests for corrections and
$odification are forwarded to t#e $aintenance processes!
Soft%are Maintenance: Proble$ reports. $odification re1uests. or re1uests to $igrate software to
a new operational environ$ent are analyDed. options for i$ple$enting t#e $odifications are
considered. and approvals for t#e selected $odifications are soug#t! "#e affected docu$entation
and software units are identified and t#e appropriate life cycle p#ases listed above are used to
i$ple$ent t#e $odification! H#en appropriate. software retire$ent is also perfor$ed!
*! 't is reco$$ended t#at t#e Software (anager docu$ent
t#e following ite$s in t#e Software (anage$ent Plan
(S(P): t#e pro3ect control $etrics to be collected for eac#
life cycle p#ase. t#e collection process. and t#e
responsibilities for collection and analysis! ("#ese $etrics
are in addition to t#ose collected on t#e Langley Software
(etrics Collection Syste$ and are used specifically for
pro3ect trac5ing and control!)
! 6or furt#er guidance on life cycle approac#es. see t#e Manager's and!oo" for Software
Development ;-<!
70,7890*9!doc + of 7
1.2 Selecting the Soft%are !e)elop"ent Approach
! "#e basic software develop$ent life cycles p#ases are
s#own in 6igure 7 as a se1uential (i!e!. waterfall)
approac#. but usually pro3ects are developed using
variants of t#is approac#! "#e following paragrap#s
provide guidance on c#oosing an appropriate software
develop$ent approac#. based on pro3ect siDe. co$ple2ity.
and ris5!
7! *aterfall !e)elop"ent Approach: 'n t#e waterfall
software develop$ent approac#. 6igure -. eac# p#ase is
co$pleted before t#e ne2t is started! Eac# p#ase produces
products t#at are used in t#e ne2t p#ase! "#is software
develop$ent approac# is appropriate only for very low
ris5. s$all pro3ects w#ose re1uire$ents are well
docu$ented and understood! 't is not appropriate for
larger pro3ects or for pro3ects w#ere all t#e re1uire$ents
are not 5nown prior to design or w#ere t#e re1uire$ents
are li5ely to c#ange!

Waterfall Development Approach
Systems
Engineering
Requirements
Analysis
Design
Test
Code
Maintenance
Integration
70,7890*9!doc 9 of 7
6igure -! "#e waterfall develop$ent approac#!
-! 'ncre"ental !e)elop"ent Approach: "#e incre$ental
software develop$ent approac# 6igure 0. is an adaptation
of t#e waterfall approac#! 't is used for larger pro3ects
and pro3ects in w#ic# t#e re1uire$ents $ay c#ange!
?nder t#e incre$ental develop$ent approac# t#e w#ole
pro3ect is bro5en into a series of s$aller deliverables
called builds! Software p#ases are repeated for eac#
build! "#e earlier builds can be used to i$ple$ent t#e
$ore stable re1uire$ents! "#ey can also be used to deal
wit# t#e $ore significant ris5s early in t#e pro3ect and
t#us increase t#e probability of pro3ect success by
eli$inating t#e ris5s before t#ey beco$e proble$s! 'n
addition. t#e #ig#er priority re1uire$ents can be
i$ple$ented in t#e earlier builds! "#erefore. if t#e pro3ect
runs over budget and develop$ent $ust be ter$inated
before all t#e re1uire$ents are i$ple$ented. only t#e
lowest priority functionality is sacrificed! 't also provides
t#e opportunity to deliver li$ited functionality early in t#e
pro3ect! "#is approac# also #elps si$plify t#e integration
p#ase because only subsets of t#e software are being
integrated at any one ti$e and w#en errors occur it is
easier to pinpoint t#eir location! "#e errors are usually in
t#e new software set 3ust integrated into t#e syste$ or in
t#e interface wit# t#e new set!
70,7890*9!doc * of 7

Incremental Development Approach
Systems
Engineering
Rqmts.
Analysis
Software Implementation Maintenance
Build 1
Build 2
Build 3
Design Code Test Integrate
Design Code Test Integrate
Design Code Test Integrate
6igure 0! "#e incre$ental develop$ent approac#!
70,7890*9!doc I of 7
0! +)olutionary !e)elop"ent Approach: "#e evolutionary
develop$ent approac#. 6igure +. is $uc# li5e t#e
incre$ental in w#ic# $ultiple builds are perfor$ed!
Cowever. in t#e later builds. re1uire$ents can be added
based on re1uester feedbac5 on t#e earlier builds! "#e
re1uire$ents evolve and are updated as better
understanding of t#e re1uester needs is ac#ieved and
issues are resolved! "#is develop$ent approac# is used
for $ore co$ple2 syste$s w#ere all t#e re1uire$ents are
not 5nown up front!

Evolutionary Development Approach
Systems
Engg
Rqmts.
Analysis
Software Implementation Maintenance
Build 1 Design Code Test Integrate
Build 2 Design Code Test Integrate
Rqmts
Analysis
Build 3 Design Code Test Integrate
Rqmts
Analysis
6igure +! "#e evolutionary develop$ent approac#!
70,7890*9!doc 8 of 7

+! Spiral !e)elop"ent Approach: Ris5 $anage$ent
largely drives t#e spiral software develop$ent approac#.
6igure 9! 't recogniDes t#ere $ay be $any uncertainties in
t#e pro3ect and wor5s to reduce t#e probability of
negative i$pacts due to t#ose uncertainties! "#e spiral
develop$ent approac# is a furt#er refine$ent of t#e basic
waterfall approac#! 't starts wit# a series of learning
cycles t#at begin wit# defining t#e ob3ectives and t#en
perfor$ing a ris5 identification and analysis to uncover
areas of greatest uncertainty in t#e pro3ect! "#e nu$ber of
iterations t#roug# t#e cycle varies based on t#e
uncertainty of t#e proble$! Si$ple proble$s ta5e one
pass and loo5 very $uc# li5e t#e standard waterfall
approac#! (ore co$plicated proble$s $ay involve
several passes t#roug# t#e cycle to resolve uncertainty to
an acceptable level! Ris5 $anage$ent is perfor$ed to
identify and analyDe ris5s! Ris5 $itigation plans identify
corrective actions to be ta5en to reduce t#e probability
and i$pact of t#e ris5s! "#e $itigation plans are
$onitored to deter$ine if t#ey re$oved or reduced t#e
ris5s as planned! "#e spiral life cycle approac# is
appropriate for large. co$ple2 syste$s wit# very
significant ris5s and syste$s w#ere all t#e re1uire$ents
are not 5nown at t#e beginning of t#e pro3ect!
70,7890*9!doc , of 7

Determine
objectives,
alternatives,
constraints


Spiral Development Approach
Evaluate alternatives,
Identify & resolve risks
Plan next phases
Develop & verify
next level product
Risk
Analysis
Risk Mitigation
Concept of
operation
Requirements
analysis
Design
Implementation
and
test
6igure 9! "#e spiral develop$ent approac#!
9! Agile Soft%are !e)elop"ent Approach: a group of
software develop$ent $et#ods based on iterative and
incre$ental develop$ent. w#ere re1uire$ents and
solutions evolve t#roug# collaboration between self)
organiDing. cross)functional tea$s! 't pro$otes adaptive
planning. evolutionary develop$ent and delivery. a ti$e)
bo2ed iterative approac#. and encourages rapid and
fle2ible response to c#ange! 't is a conceptual fra$ewor5
t#at pro$otes foreseen interactions t#roug#out t#e
develop$ent cycle! "#e &gile (anifesto;< introduced
t#e ter$ in 7,,! See
#ttp:::en!wi5ipedia!org:wi5i:&gileJsoftwareJdevelop$ent
for $ore infor$ation and diagra$s on &gile Software
Develop$ent! &lso see
#ttp:::www!scru$alliance!org:learnJaboutJscru$ and
#ttp:::en!wi5ipedia!org:wi5i:6ile:Scru$Jprocess!svg for
$ore about scru$ fra$ewor5!
*! C#aracteristics of t#e pro3ect (e!g!. cost. siDe. type.
70,7890*9!doc of 7
co$ple2ity. ris5. conse1uences of failure. lifespan. etc!)
s#ould be ta5en into consideration w#en deter$ining t#e
degree of verification and validation activities for a given
pro3ect!
1.3 #eferences
1 'EEE:E'& Standard 1((0)0*199+, IEEE-EIA Sta!&ar&, I!&u$tr. I/0'e/e!tati%! %1 I!ter!ati%!a'
Sta!&ar& ISO-IEC 1((0)2 1993, Sta!&ar& 1%r I!1%r/ati%! Te"#!%'%g.4S%1t5are Li1e C."'e
Pr%"e$$e$
( 'EEE Standard. ,*0)7,,9. Developing a Software Pro3ect Life Cycle Process. 7,,9! (URL2
#tt0$2--$ta!&ar&$!a$ag%6- 7
8 (anager4s Candboo5 for Software Develop$ent. Revision . (?RL: #ttp:::sw)
eng!larc!nasa!gov:process:docslistnew!cf$)
9 Reco$$ended &pproac# to Software Develop$ent. Revision -. (?RL: #ttp:::sw)
eng!larc!nasa!gov:process:docslistnew!cf$)
70,7890*9!doc 7 of 7