Downloaded from THE JPL SOFTWARE DEVELOPMENT PROCESS DESCRIPTION

Transcription

1 Dwnladed frm JPL D Revisin D THE JPL SOFTWARE DEVELOPMENT PROCESS DESCRIPTION Prepared by: Miltn L. Lavin and Jeanne S. Makihara JPL Jet Prpulsin Labratry Califrnia Institute f Technlgy Paper cpies f this dcument may nt be current and shuld nt be relied n fr fficial purpses. The current versin is in the DMIE Infrmatin System at

2 Dwnladed frm CHANGE HISTORY Revisin D Effective date: Nvember 15, 1999 Additin f an abstract that cntains blded requirements and a brief explanatin f hw they are t be used. There are n changes t the requirements dcumented in Versin 3. Additin f a dcument map, accessible frm each page. Revisin C Effective Date: Octber 5, 1998 Separatin f guidance frm requirements. Expanded references t ther JPL prcesses. Descriptin f applicability f SDPD t R&D tasks. Integratin f requirements levied by NASA Plicy Directive (NPD) A and NASA Prcedures and Guidelines (NPG) A, as well as guidelines frm NASA Technical Standard (NTS) A and NASA Plicy Directive (NPD) primarily in regard t risk assessment, safety, and metrics. Remval f Rules, Practices and Cnventins sectin, with the guidance distributed elsewhere in the dcument, such as in the Implementatin sectin. Revisin f Appendix C t trace ISO 9001 requirements t specific SDPD requirements. Numerus changes thrughut the dcument, but primarily in requirements and guidance in Sectins 5 and 6, t ensure respnsiveness t ISO 9001, t clarify ambiguities, and t imprve readability. Revisin B Effective Date: December 19, 1997 Additin f a develpment plan template, a cst estimatin sectin, a prcess verview sectin, and minr changes thrughut the dcument. Revisin A Publicatin Date: April 29, 1997 (never issued as an fficial dcument) First cmplete draft cntaining an elabratin f life cycle activities and supprt activities, and emphasizing tailring individual effrts via a sftware develpment plan. SOURCE: Design, Build, Assemble, and Test (DBAT) Plicy ii

3 Dwnladed frm TABLE OF CONTENTS CHANGE HISTORY...ii SOURCE.. ii ABSTRACT OF REQUIREMENTS v 1.SCOPE AND OBJECTIVES APPLICABILITY INTENDED USE AND COMPLIANCE APPLICABILITY TO R&D TASKS SYNOPSIS OF SDPD REQUIREMENTS OVERVIEW OF SOFTWARE DEVELOPMENT PROCESS ACTIVITIES RELATIONSHIP TO OTHER JPL PROCESSES AND DOMAINS SDPD REVISIONS NOTATIONS REFERENCES DEFINITIONS AND ACRONYMS QUALITY SYSTEM FRAMEWORK SOFTWARE QUALITY POLICY ROLES AND RESPONSIBILITIES INTERNAL AUDIT QUALITY SYSTEM -- LIFE-CYCLE ACTIVITIES SOFTWARE METHODOLOGY CONTRACT REVIEW CUSTOMER S REQUIREMENTS SPECIFICATION DEVELOPMENT PLANNING QUALITY PLANNING DESIGN IMPLEMENTATION TESTING AND VALIDATION DELIVERY, INSTALLATION, AND ACCEPTANCE MAINTENANCE QUALITY SYSTEM -- SUPPORTING ACTIVITIES CONFIGURATION MANAGEMENT DOCUMENTATION AND DOCUMENT CONTROL QUALITY RECORDS MEASUREMENT TOOLS AND TECHNIQUES PURCHASING AND SUBCONTRACTS CUSTOMER-SUPPLIED PRODUCT/ REUSED SOFTWARE TRAINING REVIEWS COST ESTIMATION 42 iii

4 Dwnladed frm Appendices A. Develpment Plan Template B. Recmmended Prduct Dcumentatin C. Trace f ISO 9001 Requirements t the Sftware Develpment Prcess Descriptin iv

5 Dwnladed frm Table f Cntents Abstract ABSTRACT OF REQUIREMENTS This descriptin f JPL s Sftware Develpment Prcess Descriptin (SDPD) cntains general requirements, guidelines, and suggestins fr defining and managing a sftware-intensive prject 1, prject element, r task cnsistent with ISO 9001, as interpreted by ISO , Quality Management and Quality Assurance Standards Part 3: Guidelines fr the Applicatin f 9001 t the Develpment, Maintenance, and Supply f Sftware. The SDPD is cnsistent with NASA Plicy Directive (NPD) , NASA Sftware Plicies, which identifies cmpliance with ISO 9001 (as described in ) as acceptable evidence that this plicy directive has been implemented. A. Scpe and Objectives - Applicability The primary fcus f the SDPD is the develpment f sftware supplied t bth internal and external custmers in cnjunctin with the design and implementatin f missins, spacecraft, instruments, and grund systems fr JPL s NASA spnsr. Hwever, the methdlgy can be applied t wrk fr reimbursable spnsrs and t develpment f sftware used in JPL s institutinal and business systems infrastructure. The SDPD methdlgy als applies t firmware up t the pint where testing in a simulated hardware envirnment is cmplete. At that pint, the develpment f firmware is defined by the Electrnic System Develpment sub-prcess f Design, Build, Assemble, and Test (DBAT). The SDPD is intended t: Prmte the use f cmparable develpment practices acrss the Labratry within brad classes f sftware, Establish a baseline fr cntinual imprvement f JPL's sftware develpment prcesses, and Identify requirements fr cmpliance with JPL's implementatin f ISO B. Sftware Classes Dcumentatin, reviews, and critical develpment activities are identified fr the first three classes f sftware identified belw; nn-deliverable sftware (Class D) is nt addressed: Class A: Missin-Critical: Flight r grund sftware that is necessary either t assure missin success, r if it des nt functin as specified, that culd cause lss f spacecraft, seriusly degrade the attainment f primary missin bjectives, r cause injury t humans r flight hardware. Examples f serius degradatin f missin bjectives include lss f a missin-critical event, lss f science return frm multiple instruments, r lss f a large fractin f the engineering telemetry data. 1 Future uses f the term prject are intended t encmpass prject elements and tasks, even if nt explicitly stated. v

6 Dwnladed frm Table f Cntents Abstract Class B: Class C: Class D: Missin Supprt: Flight r grund sftware that is necessary fr the science return frm a single (nn-critical) instrument, r supprts the timely generatin f missin sequences, r is used t prcess r analyze missin data, r ther sftware fr which a defect culd adversely impact attainment f sme secndary missin bjectives r cause peratinal prblems fr which ptential wrk-arunds exist. Examples f Class B include sftware that supprts pre-launch integratin and test, missin data prcessing and analysis, analysis sftware used in trend analysis and calibratin f flight engineering parameters, r sftware emplyed by the Netwrk Operatins and Cntrl Center (which is redundant with systems used at the tracking cmplexes). Class B sftware must be develped carefully, but validatin and verificatin effrt is generally less intensive than fr Class A. Develpment Supprt: Sftware develped t explre a design cncept; r supprt sftware develpment functins such as requirements management, design, test and integratin, cnfiguratin management, dcumentatin, etc.; r perfrm engineering data analysis. A defect in Class C sftware may cause rewrk but has n direct impact n missin bjectives r system safety. Class C sftware is ften used by several peple in additin t the develper(s), and by its nature, can impact the quality f delivered prducts. Dcumentatin and review f Class C sftware shuld be tailred t its intended use, with attentin t lng-term maintenance needs and t evlutin f a design prttype int peratinal flight r grund sftware. Nte: Develpment tls that can intrduce critical defects in Class A r B sftware must be regarded as belnging t the same class as the peratinal sftware. Nn-deliverable sftware develped t meet a research bjective r supprt individual engineering effrts. Generally, Class D sftware is intended fr use nly by the individual wh develped it. Althugh Class D sftware is excepted frm the requirements dcumented in the SDPD, sme f the SDPD requirements may be useful in defining and implementing this class f sftware. A prject/task can encmpass sftware that falls in mre than ne categry. In such a case, it is the respnsibility f the prject/task manager t identify the sftware elements that fall in each class, and t tailr the develpment plan accrdingly. C. Applicability t R&D Tasks Requirements n R&D sftware tasks are less stringent than thse defined in this SDPD. While managers f R&D tasks can chse t emply all r part f the SDPD requirements t their areas, they are actually subject t the requirements specified either under the Generate Scientific Knwledge (GSK) dmain, r the Develp Needed Technlgy (DNT) dmain. At the time f this writing, a Technlgy Develpment prcess has been identified within the DNT dmain. R&D task managers shuld refer t fr the plicies and prcedures assciated with this prcess. In sme cases, there are tasks identified as R&D that are nt strictly s, but instead have the characteristics f a definitin phase and essentially functin as a precursr t an actual develpment prject/task. Typically, prttypes r demnstratin sftware is prduced. In sme cases, the prttype is ultimately used peratinally rather than being abandned. Thus, where vi

7 Dwnladed frm Table f Cntents Abstract the sftware develpment effrt is nt strictly R&D, and there is strng ptential that the prduct will be used peratinally, the requirements in this SDPD apply. D. Intended Use and Cmpliance The SDPD is intended t prvide guidance in planning and managing a sftware develpment effrt up t the pint where it is delivered t either an internal r external custmer. Maintenance is als addressed t cver thse cases where the cntract with the custmer calls fr fixing defects and making enhancements pst-delivery. The SDPD is but ne surce f requirements n the management f a sftware develpment task, with ther requirements being levied by prgram ffice directives, and the plicies and prcedures f the engineering rganizatin respnsible fr the develpment. The resulting develpment plan dcuments hw a particular prject r task elects t respnd t all such requirements. Thus, a develpment plan is effectively a tailred versin f this prcess descriptin. Nte that since a prject/task may encmpass all fur classes f sftware, it is the prject/task manager s respnsibility t 1) identify the class apprpriate t each sftware element, and 2) tailr the develpment prcedures, dcumentatin, and reviews, accrdingly. Althugh n explicit waiver is required, any deviatins frm the requirements specified in this SDPD must be adequately explained in the develpment plan, as required in Sectin 5.4. Ultimately, the respnsibility fr implementing the requirements f the SDPD and related dcumentatin rests with the JPL prject r task manager. It is the manager s respnsibility t tailr the requirements f the SDPD, plus relevant dmain, prgram ffice, and line rganizatin standards and plicies, t the needs f the specific develpment jb, the result being dcumented in prject/task plans. Evidence that this respnsibility has been met is cntained in the suite f plans, prduct descriptins (e.g., requirements dcument, peratins cncept), and quality recrds prduced during develpment. It must be emphasized that cnsiderable flexibility is affrded in dcumentatin, the essential idea being that all dcumentatin shuld be directly useful t develping a high quality end prduct within the allcated budget. E. Synpsis f SDPD Requirements Detailed requirements n sftware classes A, B, and C are extracted frm the main text and rganized int Life Cycle Activities and Supprting Activities. Requirements are dented by shall statements, and are distinguished by a different fnt (Arial) in bld italics. Numbering f requirements has been preserved t facilitate reference t the full text. The essence f these detailed requirements may be summarized cncisely: Written requirements and interface specificatins, under cnfiguratin management. A develpment plan, tailred t the cmplexity f the prject/task. This plan must have a descriptin f the prduct, a task breakdwn, a schedule, an estimate f develpment effrt, and a staffing plan. A test plan tgether with dcumented test cases and prcedures. vii

8 Dwnladed frm Table f Cntents Abstract. Reviews f critical intermediate prducts bth cde and dcumentatin as described in the develpment plan. A dcumented design; graphics are recmmended. Cnfiguratin management f dcuments and cde, as described in the develpment plan (r a separate cnfiguratin management plan). Independent system-level test with dcumented anmaly reprts and change requests. Dcumentatin t supprt the end user, system peratr, and the maintainer. Embedded dcumentatin is recmmended. 5. Requirements Life Cycle Activities 5.1 Sftware Methdlgy A sftware develpment prject/task shall be rganized accrding t a life-cycle mdel that is described in the develpment plan in terms f: [5.1] Phases, alng with milestnes and activities t be perfrmed during each phase; [5.1a] Phase utputs, including any dcumentatin; [5.1b] Verificatin activities (e.g., reviews, demnstratins, tests) by phase. [5.1c] 5.2 Cntract Review The rganizatin that has verall respnsibility fr a sftware develpment effrt shall establish and maintain dcumented prcedures fr a cmmitment review f the develpment plan r prpsal t ensure: [5.2.1] Scpe f wrk fr the current delivery is adequately defined and dcumented. [5.2.1a] Differences between the scpe f wrk defined in the develpment plan, and that requested by the custmer, are reslved. [5.2.1b] Respnsibilities f the custmer are identified. [5.2.1c] Mutually acceptable means have been defined fr dealing with changes in requirements during develpment, as well as crrectin f pst-delivery defects. [5.2.1d] The resurces and schedule described in the develpment plan are adequate t accmplish the cntractual deliverables. [5.2.1e] A recrd f cmmitment review findings shall be maintained as part f the prject/task quality recrd. [5.2.2] viii

9 Dwnladed frm Table f Cntents Abstract 5.3 Custmer s Requirements Specificatin The develper shall have a written set f sftware requirements that are sufficient t satisfy custmer and/r user needs. [5.3.1] Interfaces between the sftware prduct and external sftware r hardware items shall be specified, either directly r by reference. [5.3.2] Sftware requirements, whether prvided by the custmer r frmulated by the develper, shall be reviewed t ensure that: [5.3.3] the prduct is adequately defined, [5.3.3a] ambiguities and cnflicting requirements have been reslved, and [5.3.3b] the requirements are stated s as t allw validatin during prduct acceptance. [5.3.3c] The sftware requirements specificatin shall be subject t change cntrl prcedures, nce it is baselined (e.g., cmpletin f dcument review, custmer apprval btained). [5.3.4] Apprved changes in requirements shall be maintained as part f the prject/task quality recrd. [5.3.5] 5.4 Develpment Planning A develpment plan shall address the fllwing: [5.4.1] Overall definitin f the prduct, as in user needs addressed, deliverables, and critical functinality. [5.4.1a] Scpe f develpment wrk t be perfrmed, including management and supprting activities. [5.4.1b] Prject life cycle, including: [same as 5.1] Phases, alng with activities r milestnes t be perfrmed during each phase. Phase utputs, including any dcumentatin Verificatin activities (e.g., reviews, demnstratins, tests) by phase. Prject rganizatin and technical interfaces: team structure; nature f prject interfaces, bth internal and external; rles and respnsibilities, including custmer respnsibilities; use f subcntractrs; and ther crucial dependencies, such as critical equipment and facilities, and use f JPL supprt services. [5.4.1c] Prject schedule. [5.4.1d] ix

10 Dwnladed frm Table f Cntents Abstract Risk assessment. [5.4.1e] Cst estimate/budget that summarizes the cst f the persnnel and ther resurces required by the develpment. [same as ] Staffing prfile. [5.4.1f] Change cntrl prcedures fr dcumenting, reviewing, apprving, and cmmunicating requirements changes t all affected parties. [5.4.1g] Change cntrl prcedures fr dcumenting, reviewing, apprving, and cmmunicating design changes befre their implementatin. [5.4.1h] Review (r verificatin) plicies and prcedures that, at a minimum, address detailed technical reviews, and identify what is t be reviewed (including critical intermediate prducts) and when reviews are t be held. [same as 6.9.1] Prcedures fr verifying, string, prtecting, and maintaining items (e.g., sftware, data, hardware, specificatins) supplied by the custmer r designated third party. [same as 6.7.1] Prcedures fr verifying purchased r subcntracted prducts. [same as 6.6.3] Dcumentatin plan and prcedures. [same as and 6.2.2] Scpe and cntent f the training t be prvided t prject persnnel. [same as 6.8.1] System administratin plan, including apprach t back-up/archiving, security, and virus prtectin. [5.4.1i] Definitin f respnsibility, and descriptin f assciated prcedures, t identify and crrect recurring prblems in the develpment prcess. [5.4.1j] Metrics tailred t prject needs, and the assciated prcedures fr cllecting, string, and analyzing them. [same as 6.4.1] Planning f the fllwing specific activities, including identificatin f any separate plans: [5.4.1k] Cnfiguratin management Integratin and test Delivery and installatin Maintenance Reuse strategy, if any, r identificatin f reusable elements bth thse that can be adapted frm previusly implemented systems, and prtins f the current applicatin that will be designed fr reuse. [5.4.1l] Identificatin f quality recrds, assciated prcedures, and retentin times. [same as and 6.3.3] x

11 Dwnladed frm Table f Cntents Abstract Prvisins fr updating the plan as develpment prceeds. [5.4.1m] Explanatins fr any deviatins made frm SDPD requirements. [5.4.1n] 5.5 QUALITY PLANNING -- N Requirements. 5.6 DESIGN Requirements and design activities shall be guided by a plan with milestnes and detailed technical reviews tailred t the needs f each prject/task. [5.6.1] The design shall be dcumented and, prir t release, the resulting design dcumentatin shall be reviewed t ensure that (a) the design meets the requirements and is respnsive t acceptance criteria, (b) the design is verifiable, and (c) safety issues have been addressed. [5.6.2] 5.7 Implementatin Implementatin activities shall be guided by ne r mre plans with milestnes and detailed technical reviews tailred t the needs f each prject/task. [5.7.1] 5.8 Testing and Validatin Sftware integratin and testing shall be perfrmed in accrd with test planning and specificatin dcumentatin that addresses: [5.8.1] Test requirements, which may be an elabratin f sftware requirements. [5.8.1a] Levels f testing required up t acceptance by the custmer. [5.8.1b] Test cases, test prcedures, test data and expected results. [5.8.1c] Methd f dcumenting test status and results. [5.8.1d] Test envirnment, such as dedicated prcessrs, test tls (purchased r develped), and user dcumentatin. [5.8.1e] Apprach fr evaluating test tls, with respect t their ability t verify the prduct under test (e.g., thrugh testing, published reviews). [5.8.1f] Prcedures fr crrecting defects, including analyzing the cause f the defect, determining crrective actin, and ensuring that the crrective actin is taken. [5.8.1g] Befre delivery and acceptance by the custmer, the develper shall validate the prduct under cnditins similar t the user s applicatin envirnment. [5.8.2] Missing r deficient functinality (in light f custmer/user expectatins, based n a requirements dcument r ther frm f cntractual dcument) shall be dcumented in a release descriptin dcument r transfer agreement. [5.8.3] xi

12 Dwnladed frm Tp f Dcument Abstract Test recrds t be maintained as part f the prject quality recrd shall include, at a minimum: [5.8.4] Anmaly reprts (r prblem/failure reprts) [5.8.4a] Test tl checks, t evaluate whether the tls are capable f verifying the acceptability f the sftware prduct under develpment. [5.8.4b] Test results, with clear indicatins whether the prduct has passed r failed. [5.8.4c] 5.9 Delivery, Installatin, and Acceptance The activities cmprising delivery, installatin, and acceptance shall be defined in a plan r related dcumentatin, that addresses: [5.9.1] Preparatin f the acceptance test cases and acceptance criteria, with develper's respnsibilities (if any) nted. [5.9.1a] Prcedures t be used in dcumenting and reslving prblems fund fllwing installatin, whether during acceptance testing r delivery. [5.9.1b] Details f delivery and installatin lgistics, e.g., arranging fr use f custmer/user facilities and persnnel in installatin and test. [5.9.1c] Definitin f develper's rle (if any) in supprting transitin t full peratinal use f the prduct. [5.9.1d] Identificatin f dcumentatin t be delivered at installatin, including installatin and cnfiguratin prcedures. [5.9.1e] Identificatin f training fr the user and/r system administratr/peratr. [5.9.1f] A schedule fr key events pertaining t delivery, installatin, and acceptance. [5.9.1g] Strage f archived sftware media t prevent deteriratin and facilitate disaster recvery. [5.9.1h] Virus prtectin f sftware designated fr delivery, during strage and electrnic transmissin. [5.9.1i] After delivery, a baselined cpy f the sftware and delivered dcumentatin shall be archived. [5.9.2] 5.10 Maintenance If the develper is tasked t perfrm maintenance, a maintenance plan shall be prepared, defining the scpe f the activity and the develper s apprach. [5.10.1] xii

13 Dwnladed frm Table f Cntents Abstract If the develper is required t turn maintenance ver t anther rganizatin, the develpment plan shall address the mechanism fr transferring knwledge f the sftware t the maintainer. [5.10.2] 6. Requirements Supprting Activities 6.1 Cnfiguratin Management Cnfiguratin management prcedures shall be dcumented and applied t deliverables: cde, assciated data files, and dcumentatin. [6.1.1] 6.2 Dcumentatin and Dcument Cntrl Fr each develpment effrt, the develpment plan shall define: [6.2.1] Dcuments t be prduced, e.g., dcument titles, frm (web, file server, hard cpy), cntent standards r guidelines t be fllwed. [6.2.1a] Prcedures (including respnsibilities) fr prducing, reviewing, apprving, and cntrlling dcuments. [6.2.1b] Dcumentatin prcedures shall address: [6.2.2] Which dcuments are subject t cnfiguratin management and at what pint in the develpment cycle they are baselined. [6.2.2a] Preparatin f a master dcument list, r equivalent cntrl mechanism, t identify dcument status, and preclude the use f invalid r bslete dcuments. [6.2.2b] Respnsibility fr apprving and releasing dcuments, and prmptly withdrawing bslete dcuments frm use. [6.2.2c] Identificatin f changes in released dcuments (t be dne where practicable). [6.2.2d] Apprach fr ensuring that the master dcument list (r equivalent cntrl mechanism), as well as pertinent versins f dcuments, are readily available. [6.2.2e] Directry/file permissins and back-up plicies, where dcument cntrl is achieved thrugh electrnic means. [6.2.2f] 6.3 QUALITY RECORDS The develpment plan shall identify the pertinent quality recrds and describe prcedures fr cllectin, indexing, filing, strage, access, maintenance, and dispsitin f these recrds. [6.3.1] Required quality recrds include the fllwing: [6.3.2] Apprved changes in requirements [same as 5.3.7] xiii

14 Dwnladed frm Table f Cntents Abstract Review (r verificatin) results [same as 5.2.2] Anmaly reprts [same as 5.8.4a] Checks f test tls, t evaluate whether the tls are capable f verifying the acceptability f the sftware prduct under develpment. [same as 5.8.4b] Test results, with clear indicatins whether the prduct has passed r failed. [same as 5.8.4c] Change requests/rders generated during develpment and if prvided fr in the cntract after delivery. [6.3.2a] The retentin times fr prject/task quality recrds shall be established in the develpment plan in accrd with prgram ffice directives, with particular attentin t needs f pst-delivery maintenance. [6.3.3] Quality recrds shall be stred in an envirnment cnducive t the preventin f deteriratin and lss, and in a manner s as t be readily retrievable. [6.3.4] Pertinent subcntractr quality recrds shall be identified in the subcntract. [same as 6.6.2b] 6.4 Measurement Metrics, and the assciated prcedures fr cllecting, string, and analyzing them, shall be identified in a develpment plan, and shall be tailred t prject needs. [6.4.1] 6.5 Tls and Techniques -- N requirements. 6.6 Purchasing and Subcntracts Purchase rders shall clearly describe the prduct r service rdered, and shall be reviewed fr adequacy by the develper prir t release. [6.6.1] A develpment subcntract shall address: [6.6.2] In-prcess verificatin f subcntracted develpment, via reviews f intermediate prducts and/r ther versight activities as apprpriate. [6.6.2a] Identificatin f subcntractr quality recrds t be maintained. [6.6.2b] Criteria and/r prcedures fr accepting subcntracted sftware. [6.6.2c] Upn receipt, the develper shall ensure that a prduct r service that is purchased/subcntracted, r prvided by a separate develpment rganizatin, cnfrms t specified requirements, in accrdance with prcedures defined in the develpment plan. [6.6.3] xiv

15 Dwnladed frm Table f Cntents Abstract 6.7 CUSTOMER-SUPPLIED PRODUCT/REUSED SOFTWARE The develper shall establish and dcument prcedures fr verificatin, strage, prtectin, and maintenance f items (e.g., sftware, data, hardware, specificatins) supplied by the custmer r designated third party. [6.7.1] 6.8 TRAINING The scpe and cntent f the training t be prvided t prject persnnel (e.g., develpment team, user, maintainer) shall be addressed in the develpment plan. [6.8.1] 6.9 REVIEWS The develpment plan shall define review (r verificatin) plicies and prcedures that, at a minimum, address detailed technical reviews, and identify what is t be reviewed (including critical intermediate prducts) and when reviews are t be held. [6.9.1] Review (r verificatin) results shall be maintained as quality recrds, and shall include a summary f requests fr actin and the respnses theret. [6.9.2] 6.10 COST ESTIMATION Fr each new develpment, r incremental develpment f an existing system, the develper shall prepare a dcumented cst estimate/budget that summarizes the cst f the persnnel and ther resurces required by the develpment. [6.10.1] xv

16 Dwnladed frm Table f Cntents The JPL Sftware Develpment Prcess Descriptin 1. SCOPE AND OBJECTIVES - APPLICABILITY This descriptin f JPL s Sftware Develpment Prcess Descriptin (SDPD) cntains general requirements, guidelines, and suggestins fr defining and managing a sftware-intensive prject 2, prject element, r task cnsistent with ISO 9001, as interpreted by ISO , Quality Management and Quality Assurance Standards Part 3: Guidelines fr the Applicatin f 9001 t the Develpment, Maintenance, and Supply f Sftware. The SDPD is cnsistent with NASA Plicy Directive (NPD) , NASA Sftware Plicies, which identifies cmpliance with ISO 9001 (as described in ) as acceptable evidence that this plicy directive has been implemented. The primary fcus f the SDPD is the develpment f sftware supplied t bth internal and external custmers in cnjunctin with the design and implementatin f missins, spacecraft, instruments, and grund systems fr JPL s NASA spnsr. Hwever, the methdlgy can be applied t wrk fr reimbursable spnsrs and t develpment f sftware used in JPL s institutinal and business systems infrastructure. The SDPD methdlgy als applies t firmware up t the pint where testing in a simulated hardware envirnment is cmplete. At that pint, the develpment f firmware is defined by the Electrnic System Develpment sub-prcess f Design, Build, Assemble, and Test (DBAT). The SDPD is intended t: Prmte the use f cmparable develpment practices acrss the Labratry within brad classes f sftware, Establish a baseline fr cntinual imprvement f JPL s sftware develpment prcesses, and Identify requirements fr cmpliance with JPL s implementatin f ISO Dcumentatin, reviews, and critical develpment activities are identified fr the first three classes f sftware identified belw; nn-deliverable sftware (Class D) is nt addressed: Class A: Missin-Critical: Flight r grund sftware that is necessary either t assure missin success, r if it des nt functin as specified, that culd cause lss f spacecraft, seriusly degrade the attainment f primary missin bjectives, r cause injury t humans r flight hardware. Examples f serius degradatin f missin bjectives include lss f a missin-critical event, lss f science return frm multiple instruments, r lss f a large fractin f the engineering telemetry data. 2 Future uses f the term prject are intended t encmpass prject elements and tasks, even if nt explicitly stated. 1

17 Dwnladed frm Table f Cntents Class B: Class C: Class D: Missin Supprt: Flight r grund sftware that is necessary fr the science return frm a single (nn-critical) instrument, r supprts the timely generatin f missin sequences, r is used t prcess r analyze missin data, r ther sftware fr which a defect culd adversely impact attainment f sme secndary missin bjectives r cause peratinal prblems fr which ptential wrk-arunds exist. Examples f Class B include sftware that supprts pre-launch integratin and test, missin data prcessing and analysis, analysis sftware used in trend analysis and calibratin f flight engineering parameters, r sftware emplyed by the Netwrk Operatins and Cntrl Center (which is redundant with systems used at the tracking cmplexes). Class B sftware must be develped carefully, but validatin and verificatin effrt is generally less intensive than fr Class A. Develpment Supprt: Sftware develped t explre a design cncept; r supprt sftware develpment functins such as requirements management, design, test and integratin, cnfiguratin management, dcumentatin, etc.; r perfrm engineering data analysis. A defect in Class C sftware may cause rewrk but has n direct impact n missin bjectives r system safety. Class C sftware is ften used by several peple in additin t the develper(s), and by its nature, can impact the quality f delivered prducts. Dcumentatin and review f Class C sftware shuld be tailred t its intended use, with attentin t lng-term maintenance needs and t evlutin f a design prttype int peratinal flight r grund sftware. Nte: Develpment tls that can intrduce critical defects in Class A r B sftware must be regarded as belnging t the same class as the peratinal sftware. Nn-deliverable sftware develped t meet a research bjective r supprt individual engineering effrts. Generally, Class D sftware is intended fr use nly by the individual wh develped it. Althugh Class D sftware is excepted frm the requirements dcumented in the SDPD, sme f the SDPD requirements may be useful in defining and implementing this class f sftware. A prject/task can encmpass sftware that falls in mre than ne categry. In such a case, it is the respnsibility f the prject/task manager t identify the sftware elements that fall in each class, and t tailr the develpment plan accrdingly. Sectins 1 4 f the SDPD discuss hw this dcument is t be used, describe the rle f sftware develpment within the cntext f JPL s prcess-based rganizatin, cite reference dcuments, define essential terms, state a quality plicy fr sftware develpment, and identify acceptable sftware develpment standards. The remainder f the dcument cntains requirements and guidelines pertinent t the life-cycle activities and supprting activities identified in ISO A trace t the requirements f ISO 9001 may be fund in Appendix C. 1.1 INTENDED USE AND COMPLIANCE The SDPD is intended t prvide guidance in planning and managing a sftware develpment effrt up t the pint where it is delivered t either an internal r external custmer. Maintenance is als addressed t cver thse cases where the cntract with the custmer calls fr fixing defects and making enhancements pst-delivery. 2

18 Dwnladed frm Table f Cntents The SDPD establishes requirements that are needed t cmply with JPL s implementatin f ISO 9001 in the sftware develpment arena. Requirements are dented by shall statements, and are distinguished by a different fnt (Arial) in bld italics. All ther statements are prvided strictly as guidance and are typically set apart under a Guidance heading. One shuld nt infer that such guidance is unimprtant; rather in mst cases, it is highly recmmended, and shuld be given serius cnsideratin. The SDPD is but ne surce f requirements n the management f a sftware develpment task, with ther requirements being levied by prgram ffice directives, and the plicies and prcedures f the engineering rganizatin respnsible fr the develpment. The resulting develpment plan dcuments hw a particular prject r task elects t respnd t all such requirements. Thus, a develpment plan is effectively a tailred versin f this prcess descriptin. Nte that since a prject/task may encmpass all fur classes f sftware, it is the prject/task manager s respnsibility t 1) identify the class apprpriate t each sftware element, and 2) tailr the develpment prcedures, dcumentatin, and reviews, accrdingly. Althugh n explicit waiver is required, any deviatins frm the requirements specified in this SDPD must be adequately explained in the develpment plan, as required in Sectin 5.4. Evidence f cmpliance with each shall statement is, in mst cases, dcumentatin. Dcumentatin means a retrievable written recrd. It is the prergative f the prject/task t select the media and the frmat that best suits prject/task needs. Fr example, recrding requirements in an electrnic memrandum and the use f a CASE tl t dcument design are bth acceptable. Detailed sftware standards identified in Sectin 2 cntain tpic utlines that are intended t help rganize mre frmal dcuments. Again, these utlines shuld be tailred t the needs f individual prjects/tasks. Appendix A prvides a template fr a develpment plan, which addresses ISO requirements. Recmmended dcumentatin fr sftware classes A, B, and C is summarized in Appendix B. 1.2 APPLICABILITY TO R&D TASKS Requirements n R&D sftware tasks are less stringent than thse defined in this SDPD. While managers f R&D tasks can chse t emply all r part f the SDPD requirements t their areas, they are actually subject t the requirements specified either under the Generate Scientific Knwledge (GSK) dmain, r the Develp Needed Technlgy (DNT) dmain. At the time f this writing, a Technlgy Develpment prcess has been identified within the DNT dmain. R&D task managers shuld refer t fr the plicies and prcedures assciated with this prcess. In sme cases, there are tasks identified as R&D that are nt strictly s, but instead have the characteristics f a definitin phase and essentially functin as a precursr t an actual develpment prject/task. Typically, prttypes r demnstratin sftware is prduced. In sme cases, the prttype is ultimately used peratinally rather than being abandned. Thus, where the sftware develpment effrt is nt strictly R&D, and there is strng ptential that the prduct will be used peratinally, the requirements in this SDPD apply. 1.3 SYNOPSIS OF SDPD REQUIREMENTS Detailed requirements n sftware classes A, B, and C may be fund in Sectins 5 and 6. The essence f these detailed requirements may be summarized cncisely: 3

19 Dwnladed frm Table f Cntents. Written requirements and interface specificatins, under cnfiguratin management A develpment plan, tailred t the cmplexity f the prject/task. This plan must have a descriptin f the prduct, a task breakdwn, a schedule, an estimate f develpment effrt, and a staffing plan A test plan tgether with dcumented test cases and prcedures. Reviews f critical intermediate prducts bth cde and dcumentatin as described in the develpment plan. A dcumented design; graphics are recmmended Cnfiguratin management f dcuments and cde, as described in the develpment plan (r a separate cnfiguratin management plan) Independent system-level test with dcumented anmaly reprts and change requests Dcumentatin t supprt the end user, system peratr, and the maintainer. Embedded dcumentatin is recmmended. 1.4 OVERVIEW OF SOFTWARE DEVELOPMENT PROCESS ACTIVITIES The sftware develpment prcess exists t meet the needs f the custmer, user, maintainer, JPL management, vendrs, subcntractrs, and ther third parties, as depicted in Exhibit 1.1. The sftware develpment prcess, cnsists f the activities identified in Exhibit 1.2. Each f these activities is detailed in Sectins 5 and 6. The develpment activities prtrayed in the exhibit are related using the metaphr f a state chart. Transactins between activities are dented by labeled arrws. T reduce cmplexity, nly key transactins are identified explicitly. Fr expsitry cnvenience, Exhibit 1.2 grups tw sets f elemental activities int metaactivities f Prject Definitin and Develpment Planning. Prject Definitin cnsists f Cst Estimatin (6.10), Custmer Requirements Specificatin (5.3), Sftware Methdlgy (5.1), and Cntract Review (5.2). Develpment Planning encmpasses preparatin f the develpment plan (5.4) and related plans, such as Integratin & Test (5.8), and Cnfiguratin Management (6.1). Quality Planning (5.5) is regarded as an integral part f develpment planning. Other plans (nt separately identified in Exhibit 1.2) may include a plan fr Installatin and Acceptance (5.9), and a plan fr Maintenance (5.10) if JPL has that respnsibility. A develpment effrt begins with a discussin f custmer requirements that are subsequently frmalized in a prpsal. The identified prject definitin activities are essential t preparatin f bth the prpsal and the develpment plan (5.4) that details hw the requirements will be satisfied. Once requirements (5.3) have been dcumented (6.2) t the satisfactin f all parties, they are baselined, and put under cnfiguratin management (6.1). After review by the custmer and apprval by JPL management, the develpment plan and any related plans are als baselined. Once planning is cmplete, develpment cmmences. Develpment usually prceeds iteratively, and is rganized int life-cycle (primary) activities: 4

20 Dwnladed frm Table f Cntents Design (5.6), Implementatin (5.7), Testing and validatin (5.8), Delivery/installatin/acceptance (5.9), and Maintenance (5.10). Maintenance is fenced with a dashed line t indicate that JPL s respnsibility may vary frm prject t prject. Supprting activities, which functin thrughut the develpment prcess, include: Identificatin f tls and techniques (6.5), Purchasing and subcntracts (6.6), Custmer-supplied prducts /reused sftware (6.7), Training (6.8), Reviews (6.9), and Measurement (6.4) the cllectin and use f metrics. The develpment plan (5.4) details each f these activities. Once develpment is cmplete, the user is prvided with the first release, tgether with the required training and dcumentatin. Subsequent releases are prduced by maintenance (5.10), a functin pssibly prvided by a third party. Design requirements and design details are subject t dcumentatin and dcument cntrl (6.2) as develpment prceeds. Cde, develpment and test tls, and quality recrds (6.3) are subject t cnfiguratin management (6.1). An imprtant new requirement impsed by the ISO 9001 standard is the maintenance f a quality recrds archive that cntains evidence that the develpment prcess is functining as intended. The quality recrds archive is used in bth internal and third-party assessments, and is an essential requirement f ISO 9001 certificatin. Additinally, this archive prvides data useful in redesigning the develpment prcess t make it mre efficient and respnsive t prject needs. In practice, the archive is usually distributed. The archive typically includes: Develpment plan, which tailrs the prcess descriptin fr a particular prject/task; Related plans fr integratin and test, cnfiguratin management, installatin and acceptance, maintenance, etc.; Cst estimates; 5

21 Dwnladed frm Table f Cntents Recrds f reviews, including requests fr actin and the assciated respnses; Changes in requirements and design, including the ratinale fr these changes; Test recrds, including sftware anmaly reprts r prblem/failure reprts, suggested design changes, summaries f test findings and status, and test tl verificatin recrds; Cnfiguratin management recrds and reprts; Training recrds; and Metrics, as defined in the develpment plan. 1.5 RELATIONSHIP TO OTHER JPL PROCESSES AND DOMAINS The Sftware Develpment Prcess is an element f the Design, Build, Assemble, and Test (DBAT) Prcess, and is used cncurrently with ther DBAT prcesses. It may als be used by ther majr prcesses within the Develp New Prducts (DNP) Dmain, such as Prject Leadership Prcesses (PLP), Missin System Design (MSD), Verify, Integrate, Validate, and Operate (VIVO), as well as prcesses within ther dmains, such as Prvide Enabling Services (PES) Dmain. The Sftware Develpment plicy, which can be fund at describes the relatinship between the Sftware Develpment Prcess and ther JPL prcesses. It is incumbent upn the prject/task manager t use DMIE ( t becme familiar with the JPL prcesses that are currently applicable t the prject/task. A sample f the prcesses that interface with, r are used in cnjunctin with, the Sftware Develpment Prcess are prvided belw: Quality Assurance Engineering Engineering Standards Reliability Engineering System Safety Prduct Data Management, e.g., fr catalging and archiving quality recrds and prduct dcumentatin, such as requirements, design, cde, and user dcumentatin. Prject Planning Prject Technical Management Risk Management Prject Cst Estimatin 6

22 Dwnladed frm Table f Cntents EXHIBIT 1.1: Relatinship f Sftware Develpment Prcess t External Entities JPL Management Audit Supprt Quality Recrds Archive Plicies, Standards, Cnstraints Status Inf Quality Recrds Custmer Prpsal, Status Inf Cntract, Reqts, Cnstraints, Test Facilities, Budget, Changes SOFTWARE DEVELOPMENT PROCESS Anmaly Reprts (Prblem/Failure Reprts), Change Requests Cde, Dcuments, Data, Training User Requirements, Standards POs & MOUs HW, SW, Service Subcntractrs Status Inf, Cde, Dcuments Cde, Reqts & Design Dcuments, Test Tls, Data Files Vendrs And 3rd Parties Maintainer New Releases Anmaly Reprts (Prblem/Failure Reprts), Change Requests 7

23 Dwnladed frm Table f Cntents Exhibit 1.2: Inter-Relatinships Amng Develpment Activities, Emphasizing Quality System Transactins Custmer Prpsal Requirements 6.1 CONFIGURATION MANAGEMENT 6.5 TOOLS & TECHNIQUES PROJECT DEFINITION 5.3 Custmer Reqts Spec 5.1 SW Methdlgy 6.10 Cst Estimatin 5.2 Cntract Review Requirements Tls 6.2 DOCUMENTATION AND DOCUMENT CONTROL 6.6 PURCHASING & SUBCONTRACTS 5.4 DEVELOPMENT PLANNING SW Develpment Plan 6.1 Cnfig. Mgt. Plan 5.8 Integratin & Test Plan 5.5 Quality Plan Plans Design Specs 6.7 CUSTOMER-SUPPLIED PRODUCT/ REUSED SW 6.8 TRAINING 5.6 DESIGN 5.7 IMPLEMENTATION Cding Unit Testing Rewrk Review Recrds, Training Recrds, Metrics Reqts Changes, Design Changes Cde 6.3 QUALITY RECORDS 6.9 REVIEWS 5.8 TESTING AND VALIDATION Test Tl Verificatin, Test Results, Anmaly Reprts 6.4 MEASUREMENT 5.9 DELIVERY, INSTALLATION, AND ACCEPTANCE Release MAINTENANCE Release 2+ User 8

24 Dwnladed frm Table f Cntents In sme cases, an instantiating prcess will use all elements f the SDPD described belw in Sectins 5 and 6. In ther cases, the prcess will be primarily cncerned with executing selected activities r sub-prcesses, such as: Defining a sftware prduct and subsequently, managing the subcntracted implementatin; Perfrming supprting activities such as evaluatin f third party sftware, cnfiguratin management, independent verificatin and validatin, quality assurance, dcumentatin; Maintaining the sftware after installatin at the user s site(s). Althugh its applicability is intended t be brad, the SDPD was written t supprt the develpment f missin critical (Class A) and missin supprt (Class B) sftware by the engineering design and develpment prcesses within DNP, especially: Missin and spacecraft mdeling and trade-ff studies dne in Missin and System Design (MSD); On-bard prcessrs, cntrllers, and diagnstic sftware develped by elements f Design, Build, Assemble, and Test (DBAT), such as the Electrnic System Develpment sub-prcess; and Navigatin, sequencing, cmmand, telemetry, and testbed sftware develped by elements f Verify, Integrate, Validate, and Operate (VIVO). 1.6 SDPD REVISIONS Recmmendatins fr changes can be submitted t the authrs f this SDPD. This dcument is subject t the change cntrl prcedure f the Prvide Engineering Standards prcess, i.e., Change Cntrl fr JPL Level III Categry A Engineering Standards. (Refer t NOTATIONS As mentined previusly, requirements are dented by shall statements, and are distinguished by a different fnt (Arial) in bld italics. Requirements are als numbered sequentially within each requirements sectin and bracketed. In additin, where requirements trace t clauses in the ISO 9001 standard, the ISO clause is als identified and bracketed. Where requirements trace t ISO , which is the sftware interpretatin f 9001, the bracketed ISO reference includes the wrd guidance. 9

25 Dwnladed frm Table f Cntents 2. REFERENCES CMU/SEI-93-TR-006, Taxnmy-Based Risk Identificatin, lcated at (Sftware Engineering Institute) EIA/IEEE J-STD (frmerly P1498), Trial Use Standard fr Infrmatin Technlgy Sftware Life Cycle Prcesses Sftware Develpment Acquirer-Supplier Agreement, September 30, IEEE : 1990, IEEE Standard Glssary f Sftware Engineering Terminlgy. ISO :1984, Data Prcessing Vcabulary Part 01 Fundamental Terms. ISO 8402:1986, Quality Vcabulary. ISO 9001:1994, Quality Systems Mdel fr Quality Assurance in Design, Develpment, Prductin, Installatin, and Servicing. ISO :1997(E), Guidelines fr the Applicatin f ISO 9001:1994 t the Develpment, Supply, Installatin and Maintenance f Cmputer Sftware. ISO 12207:1995, Infrmatin Technlgy Sftware Life Cycle Prcesses. NASA Plicy Directive :1998, NASA Sftware Plicies. NASA Plicy Directive (NPD) A: 1996, Prgram/Prject Management, (available at N_PD_7120_4A.html). NASA Prcedures and Guidelines (NPG) A: 1998, NASA Prgram and Prject Management Prcesses and Requirements (available at Directives/NASA-WIDE/Prcedures/Prgram_Frmulatin/N_PG_7120_5A.html). NASA Technical Standard (NTS) A, Sftware Safety, (available at In additin t the abve standards, Table 1-1 prvides a list f IEEE standards pertaining t sftware issues, which the reader may chse t refer t in planning the sftware life cycle and activities. Nte that these standards may nt be referred t explicitly in this SDPD, but are prvided fr infrmatinal purpses t facilitate the tailring f ne s sftware life cycle, activities, and dcumentatin. JPL Standards and Related Dcuments: JPL D-560: 1993, JPL Standard fr Systems Safety. JPL D-4000:1988, JPL Sftware Management Standards Package. 10

26 Dwnladed frm Table f Cntents JPL D-10401:1995, JPL Standard fr Reviews. JPL D-7090:1990, A Guide t Develping Requirements. JPL D-8431:1991, D-4000 Standards Applicatin Guide: Prject Measures. JPL D-8433:1991, D-4000 Standards Applicatin Guide: D-4000 Activities and Prducts. JPL D-9085:1991, D-4000 Applicatins Guide: Findings and Recmmendatins frm Case Studies f Technical Reviews. JPL D-10459:1993, D-4000 Standards Applicatins Guide: Using Quality Factrs and Measures t Fcus n Custmer Satisfactin. JPL D-12018:1994, D-4000 Standards Applicatins Guide: Life Cycles. JPL D-12019:1994, D-4000 Standards Applicatins Guide: Prttyping. JPL D-12020:1994, D-4000 Standards Applicatins Guide: Dcumentatin. JPL D-12021:1994, D-4000 Standards Applicatins Guide: Testing. JPL D-12022:1995, D-4000 Standards Applicatin Guide: Sftware Reuse. JPL D-12023:1995, D-4000 Standards Applicatins Guide: Sftware Milestne Reviews. JPL D-13922:1996, A Guide t Selecting and Applying Sftware Develpment Standards. JPL D-15951:1998, Risk Management Handbk fr JPL Prjects JPL D-16110: 1998, Engineering Ecnmic Analysis Grup, Systems Analysis Sectin. DSN Guidelines fr Presenting Sftware Csts and Schedules at Majr Milestne Reviews. JPL Plicy, JPL Cst Estimatin, lcated at JPL Plicy, Risk Management, lcated at JPL Plicy, Sftware Develpment, lcated at JPL Plicy, System Safety, lcated at JPL Plicy, Wrk Breakdwn Structure, lcated at JPL System Prcedure, Change Cntrl fr JPL Level III Categry A Engineering Standards, (Prvide Engineering Standards Prcess), lcated at 11

27 Dwnladed frm Table f Cntents Table 1-1. IEEE Sftware Develpment Standards Dcument Number IEEE IEEE 730 IEEE IEEE 828 IEEE 829 IEEE 830 IEEE IEEE IEEE 1002 IEEE 1008 IEEE 1012 IEEE 1016 IEEE IEEE 1028 IEEE 1042 IEEE 1044 IEEE IEEE 1045 IEEE IEEE 1059 IEEE 1061 IEEE 1062 IEEE 1063 IEEE 1074 IEEE IEEE 1219 IEEE 1228 IEEE 1298 IEEE 1348 IEEE IEEE A IEEE 1430 IEEE-J-STD-016 IEEE Title Standard Glssary f Sftware Engineering Terminlgy Standard fr Sftware Quality Assurance Plans Guide fr Sftware Quality Assurance Planning Standard fr Sftware Cnfiguratin Management Plans. Standard fr Sftware Test Dcumentatin Recmmended Practice fr Sftware Requirements Specificatins Standard Dictinary f Measures t Prduce Reliable Sftware Guide fr the Use f IEEE Standard Dictinary f Measures t Prduce Reliable Sftware Standard Taxnmy fr Sftware Engineering Standards Standard fr Sftware Unit Testing Standard fr Sftware Verificatin and Validatin Plans Recmmended Practice fr Sftware Design Descriptins Guide t Sftware Design Descriptins Standard fr Sftware Reviews and Audits Guide t Sftware Cnfiguratin Management Standard Classificatin fr Sftware Anmalies Guide t Classificatin fr Sftware Anmalies Standard fr Sftware Prductivity Metrics Standard fr Sftware Prject Management Plans Guide fr Sftware Verificatin and Validatin Plans Standard fr a Sftware Quality Metrics Methdlgy Recmmended Practice fr Sftware Acquisitin Standard fr Sftware User Dcumentatin Standard fr Develping Sftware Life Cycle Prcesses Guide fr Develping Sftware Life Cycle Prcesses Standard fr Sftware Maintenance Standard fr Sftware Safety Plans Sftware Quality Management System, Part 1: Requirements Recmmended Practice fr the Adptin f Cmputer-Aided Sftware Engineering (CASE) Tls Standard fr Infrmatin Technlgy Sftware Reuse Data Mdel fr Reuse Library Interperability: Basic Interperability Data Mdel Supplement t IEEE Standard fr Infrmatin Technlgy Sftware Reuse Data Mdel fr Reuse Library Interperability: Asset Certificatin Framewrk Guide fr Infrmatin Technlgy Sftware Reuse Cncept f Operatins fr Interperating Reuse Libraries Standard fr Infrmatin Technlgy Sftware Life Cycle Prcesses Standard fr Infrmatin Technlgy Sftware Life Cycle Prcesses Full-text versins f these standards are available thrugh 12