吴忠躺衫网络科技有限公司

您好,歡迎來電子發(fā)燒友網(wǎng)! ,新用戶?[免費注冊]

您的位置:電子發(fā)燒友網(wǎng)>電子百科>電腦硬件>臺式機>

軟件生存期過程(1)

2010年04月14日 11:10 www.solar-ruike.com.cn 作者:佚名 用戶評論(0
關(guān)鍵字:軟件(87248)

軟件生存期過程(1)

 6 獲取過程

  獲取過程包含需方的活動和任務(wù)。此過程從定義軟件產(chǎn)品或服務(wù)的獲取需求開始。接著就是準備并公布標書、選擇供方和管理獲取過程,直到系統(tǒng)的驗收。有這種需求的機構(gòu)可以叫做擁有者。該擁有者可以就任一項或全部獲取活動與某機構(gòu)簽訂合同,該機構(gòu)將根據(jù)獲取過程開展相應(yīng)的活動。本章中的需方可以是擁有者或者是代理人。

  此過程含有下述活動:
  a.開始和范圍定義;
  b.招標的準備;
  c.合同的準備、談判及修改;
  d.對供方的監(jiān)督;
  e.驗收和完成。

  6.1 開始和范圍定義
  本項活動含有下述任務(wù):

  6. 1.1 需方將認定獲取、開發(fā)或改進一個軟件產(chǎn)品(該軟件產(chǎn)品可能是一個系統(tǒng)的一部分)或服務(wù)的概念或需求,并依此開始該獲取過程。

  6.1.2 需方將詳細地定義系統(tǒng)需求,此需求在已存在的限制條件下開發(fā)系統(tǒng)是可行的。

  6.1.2.1 該系統(tǒng)需求定義最好包括與設(shè)計、測試和遵守標準及開發(fā)過程有關(guān)的關(guān)鍵性、安全性和保密性要求。

  6.1.2.2 該系統(tǒng)需求將遵循開發(fā)過程(第8章)定義并形成文檔。

  6.1.3 如果需方不能定義系統(tǒng)需求,則將制訂一個定義它們的計劃。這個計劃將指定提出這些需求的一個機構(gòu),最好包括一一些活動,如進行可行性研究、制作原型和模型。

  6.1.4 系統(tǒng)需求一旦定義,需方將依據(jù)風(fēng)險分析來考慮獲取系統(tǒng)所能采用的方案。這些方案包括:
  a.購買能滿足需求的現(xiàn)貨產(chǎn)品;
  b.在內(nèi)部開發(fā)產(chǎn)品或得到服務(wù);
  c.通過合同開發(fā)產(chǎn)品或得到服務(wù);
  d.上述a、b、c條的結(jié)合;
  e.提高現(xiàn)有的系統(tǒng)、產(chǎn)品或服務(wù)。

  6.1.5 當要獲得一個現(xiàn)貨產(chǎn)品的時候,需方將保證能滿足下述條件:
  a.該軟件滿足它的需求;
  b.有必須的文檔;
  c.可滿足所有權(quán)和使用權(quán);
  d. 有未來的產(chǎn)品支持計劃。

  6.1.6 需方將制訂一個獲取計劃。此計劃要對系統(tǒng)需求作出定義,并定義對所計劃的系統(tǒng)的使用、將執(zhí)行的合同的類型、所涉及的機構(gòu)的責(zé)任、將使用的支持的概念、所考慮到的風(fēng)險以及管理這些風(fēng)險的辦法。并將該計劃寫成文檔。

  6.1.7 需方將定義系統(tǒng)的驗收策略和準則,并將其寫成文檔。

  6.2 招標的準備
  此項活動含有下述任務(wù):

  6.2.1 需方將制作一份系統(tǒng)獲取需求的文檔(即標書),其內(nèi)容視第6.1.4條中所選的獲取選擇方案而定。該系統(tǒng)獲取文檔最好包括:
  a.系統(tǒng)需求;
  b.工作描述;
  c.投標者須知;
  d.產(chǎn)品或服務(wù)清單;
  e.合同條款;
  f.子合同條款;
  g.技術(shù)限制(例如目標環(huán)境)。

  6.2.2 需方將決定本標準的哪些過程、活動和任務(wù)適合它的項目并對其進行適當?shù)募舨谩P璺綄⑻貏e指明可以使用的支持過程(第11章)和它們的執(zhí)行機構(gòu),這樣供方就可以在它們的建議中定義達到每個特定支持過程的方法。

  6.2.3 系統(tǒng)的獲取文檔將定義合同的里程碑,以便作為對獲取的監(jiān)督(見第 11. 3條)的一部分將檢驗和審計供方的進度。

  6.2.4 系統(tǒng)的獲取需求最好交給實施獲取活動任務(wù)的機構(gòu)。

  6.3 合同的準備、談判和修改
  此項活動由下述任務(wù)組成:

  6.3.1 需方最好建立一個選擇供方的規(guī)程,其中包括建議的評價準則和對需求的依從程度。

  6.3.2 需方最好在對供方的建議、能力以及需要考慮的其它因素進行評價的基礎(chǔ)上選擇一個供方。

  6.3.3 需方可以與其它各方一道為項目而剪裁本標準。但是,在需方與其它各方之間達成協(xié)議時,最后的剪裁決定將由需方做出。

  6.3.4 然后,需方將準備就一項合同與供方進行談判。談判中提出系統(tǒng)的需求、成本、提供產(chǎn)品或服務(wù)的日程。該合同將提及與可重復(fù)使用的現(xiàn)貨產(chǎn)品有關(guān)的產(chǎn)權(quán)、使用權(quán)和所有權(quán)。

  6.3.5 在合同的執(zhí)行期內(nèi),需方將通過與供方(即控制合同變化的另一當事方)進行談判來控制合同的變化。應(yīng)當研究合同的變化對項目計劃、成本、質(zhì)量和日程的影響。

  6.4 對供方的監(jiān)督
  此項活動由下述任務(wù)組成:

  6.4.1 需方將按照合同所定范圍監(jiān)督和評價供方的技術(shù)和進度,其中包括質(zhì)量和成本。所用的手段最好適合于獲得的類型并包括下述活動,例如非正式的會面、合同所要求的評審、審計,以及(獨立的)驗證和確認。獨立的驗證和確認將分別根據(jù)第 11.3和11.4條進行。

  6.4.2 需方最好與供方合作以便及時地提供全部必要的信息和解決尚未解決的問題。

  6.5 驗收和完成
  此項活動含有下述任務(wù):

  6.5.1 需方將根據(jù)已定義的策略和準則為驗收做好全部必要的準備。準備最好包括對測試用例、測試數(shù)據(jù)、測試過程和測試環(huán)境的準備。

  6.5.2 需方將對交付的產(chǎn)品或服務(wù)進行驗收評審和驗收測試,當符合所有的驗收條件之后,從供方處驗收該產(chǎn)品或服務(wù)。驗收過程應(yīng)符合第6.1.6條中的規(guī)定。

  6.5.3 在驗收之后,需方最好按照第 11.2條采取交付產(chǎn)品的配置管理。


  7 供應(yīng)過程

  此過程含有供方的活動和任務(wù)。

  此過程的開始方法可以有兩種,-是決定準備一項建議以應(yīng)答需方的標書(RFP);二是就提供一個含有軟件的系統(tǒng)(或系統(tǒng)的一個部件、一個產(chǎn)品或一項服務(wù))與需方簽訂合同或協(xié)議。接著就是規(guī)定為了管理和保證這個項目所需要的步驟和資源,其中包括制訂項目計劃和實施計劃,直至向需方交付系統(tǒng)、產(chǎn)品或提供服務(wù)。 供方按照第5章來管理這個過程。

  此過程含有下述活動:
  a. 開始;
  b.準備投標;
  c.簽訂協(xié)議;
  d.編制計劃;
  e.實施和控制;
  f.評審和評價;
  g.交付和完成。

  7.1 開始
  此項活動含有下述任務(wù):

  7.1.1 供方評審標書(RFP)中的需求,與公司的方針及其它規(guī)則相對照。

  7.1.2 供方最好對是否投標或是否接受合同作出決定。

  7.2 準備投標
  此項活動含有下述任務(wù): 供方最好定義和準備一份投標書。

  7.3 簽訂協(xié)議
  此項活動含有下述任務(wù):

  7.3.1 供方應(yīng)當與需方就提供系統(tǒng)、產(chǎn)品或服務(wù)進行談判并簽訂合同。

  7.3.2 作為修改控制機制的一部分,供方可以請求修改合同。

  7.4 編制計劃
  此項活動含有下述任務(wù):

  7.4.1 為了保證交付的系統(tǒng)、產(chǎn)品或服務(wù)的質(zhì)量,供方應(yīng)當全面評審合同中的系統(tǒng)獲取需求,以確定管理和保證項目的框架。

  7.4.2 供方應(yīng)當確定或選擇與項目的范圍、規(guī)模和復(fù)雜性相適合的軟件生存周期模型。應(yīng)當把從本標準中選出的過程、活動和任務(wù)影射到該生存周期模型中。該生存周期模型應(yīng)當包括可使用的開發(fā)環(huán)境,其中包括標準、方法和工具等。

  7.4.3 供方應(yīng)當規(guī)定管理和保證此項目的計劃需求。這種規(guī)定最好包括對資源的需求和需方的介入。

  7.4.4 計劃需求一旦規(guī)定,供方應(yīng)當根據(jù)風(fēng)險分析,為開發(fā)該產(chǎn)品或提供該服務(wù)選擇方案。
  可供選擇的方案有:
  a.利用內(nèi)部資源開發(fā)產(chǎn)品或提供服務(wù);
  b.用子合同方式開發(fā)產(chǎn)品或提供服務(wù);
  c.從內(nèi)部或外部來源獲得現(xiàn)貨產(chǎn)品;
  d.上述a、b二條結(jié)合。

  7.4.5 供方應(yīng)當以所計劃的需求和第7.4.4條中規(guī)定的可選方案為基礎(chǔ)制定項目管理計劃,并將其寫成文檔。
在這些計劃中應(yīng)當規(guī)定下述事項:
  a. 項目的組織機構(gòu),以及包括外部機構(gòu)在內(nèi)的每個機構(gòu)的權(quán)利和責(zé)任;
  b.開發(fā)環(huán)境,包括測試環(huán)境。庫、設(shè)備、儀器以及工程標準、步驟和工具;
  c.生存期過程和活動的工作細目的結(jié)構(gòu),其中包括可交付的產(chǎn)品,與任務(wù)有關(guān)的經(jīng)費預(yù)算、人員。物理資源、軟件的規(guī)模以及時間進度;
  d.系統(tǒng)的質(zhì)量需求管理。如果需要,可以另外制訂質(zhì)量保證計劃;
  e.系統(tǒng)安全和保密的關(guān)鍵需求管理。如果需要,另外制訂安全和保密計劃;
  f.分包商的管理,其中包括對分包商的選擇。如果選擇了分包商,還包括分包商一需方的介入;
  g.需方的介入,即按合同要求進行的評審和審計(見第11.3條)、非正式的會面、報告、修改和變更的實施、批準、驗收、對設(shè)施的使用等;
  h.驗證和確認(見第11.4條),規(guī)定中應(yīng)包括與獨立的驗證和確認機構(gòu)接觸的方法;
  i.質(zhì)量保證(見第 11.5條);
  j.風(fēng)險管理,此項管理包括對項目的潛在技術(shù)、成本和進度諸風(fēng)險領(lǐng)域的管理;
  k.保密方針,即在每個項目組織層次上有關(guān)“需要知道”和“接觸信息”的規(guī)則;
  l.規(guī)則所要求的批準、證書、專有權(quán)利等; m.制定計劃、跟蹤和報告的方法;
  n.人員培訓(xùn)(見第 11. 7條)。

  7.5 執(zhí)行和控制
  此項活動包括下述任務(wù):

  7.5.1 供方應(yīng)當實施和執(zhí)行使第7.4條制訂的項目計劃。

  7.5.2 供方應(yīng)當分別根據(jù)開發(fā)過程(第8章)、操作過程(第9章)或維護過程(第10章)開發(fā)、操作或維護軟件。

  7.5.3 供方應(yīng)當在合同所定的整個生存周期內(nèi)監(jiān)督和控制項目產(chǎn)品或服務(wù)的進展和質(zhì)量。這應(yīng)當是一個連續(xù)的、反復(fù)進行的任務(wù),它應(yīng)當提供:
  a.監(jiān)督技術(shù)性能、成本和進度的進展情況,報告項目的狀況;
  b.問題的識別、記錄、分析和解決。

  7.5.4 供方應(yīng)當管理和控制分包商,向其傳達全部必要的合同需求,以保證交給需方的所有的產(chǎn)品或服務(wù)都符合主合同的要求。

  7.6 評審和評價
  此項活動包括下述任務(wù):

  7.6.1 在適當?shù)那闆r下,供方最好根據(jù)合同進行評審活動、與需方進行接觸和通信

  7.6.2 供方應(yīng)當進行或支持非正式的會面、驗收評審和驗收測試,按照合同和項目計劃的規(guī)定與需方一起進行合同所要求的評審和正式的審計。審計應(yīng)當按照第11。3條進行。

  7.6.3 供方應(yīng)當向需方提供關(guān)于評價、評審、審計、測試、改正工作和解決問題的報告。

  7.6.4 為了按照合同和項目計劃的規(guī)定評審產(chǎn)品或服務(wù),供方應(yīng)當讓需方使用供方和分包商的設(shè)備。

  7.6.5 供方應(yīng)當按照合同和項目計劃的規(guī)定,與獨立的驗證和確認機構(gòu)或測試機構(gòu)(見第11.4條)進行接觸。

  7.6.6 供方應(yīng)當根據(jù)11.5條實施項目的質(zhì)量保證。實施軟件的質(zhì)量保證時可以用ISO 9003—87或其它類似的指南。

  7.7 交付和完成
  此項活動包括下述任務(wù):

  7.7.1 供方應(yīng)按照合同的規(guī)定交付系統(tǒng)。

  7.7.2 供方應(yīng)當對已交付的系統(tǒng)向需方提供支持。

  7.7.3 供方應(yīng)當考察需方對已交付的系統(tǒng)是否滿意。

  8 開發(fā)過程

  開發(fā)過程包括開發(fā)者的活動和任務(wù)。此過程包括需求分析、設(shè)計、編碼、集成、測試、軟件安裝和驗收等活動。完成下面所列出的全部活動。按照合同,軟件開發(fā)者的責(zé)任從軟件需求分析開始,以軟件鑒定測試終止。但是,通常軟件是作為整個系統(tǒng)的一部分實現(xiàn)的。軟件的需求分析與整個系統(tǒng)需求分析、系統(tǒng)設(shè)計有關(guān),故軟件開發(fā)者有可能要參加系統(tǒng)需求分析。系統(tǒng)設(shè)計,或從系統(tǒng)需求分析、系統(tǒng)設(shè)計中獲取必要的信息。軟件鑒定測試完成后,還要把軟件集成到整個系統(tǒng)中去。所以,本過程列出了系統(tǒng)的開發(fā)過程所包含的所有活動。軟件開發(fā)者按照合同的規(guī)定來確定此過程所包含的活動。開發(fā)者也可以完成需方所要求的其它活動。

  此過程由下述活動組成:
  a.建立過程;
  b.系統(tǒng)需求分析;
  c.系統(tǒng)設(shè)計;
  d.軟件需求分析;
  e.軟件體系結(jié)構(gòu)設(shè)計;
  f.軟件的詳細設(shè)計;
  g.軟件編碼;
  h.軟件集成;
  i.軟件鑒定測試;
  j.系統(tǒng)集成;
  k.系統(tǒng)鑒定測試;
  l.驗收所需要的安裝和支持。

  8.1 建立過程
  此項活動含有下述任務(wù):

  8.1.1 開發(fā)者應(yīng)當將開發(fā)過程的活動映射到為軟件項目所建立的生存周期模型中。如果沒有建立一個生存周期模型,就應(yīng)當建立一個。所選擇的活動可以是重疊的或相互有關(guān)聯(lián)的,而且也可以反復(fù)交替地一實施。

  8.1.2 開發(fā)者應(yīng)當實施第11章指定的支持過程,這些過程是按照第6.2.2條的決定支持開發(fā)活動所必須的。

  8.1.3 如果在合同中沒有約定,開發(fā)者應(yīng)當選擇、剪裁和使用適當?shù)膬?nèi)部的標準、方法、步驟和計算機編程語言,這些是由開發(fā)者的組織為了實施開發(fā)活動和支持各種過程已用文檔建立起來的。

  8.1.4 開發(fā)者應(yīng)當制訂進行開發(fā)過程的活動計劃。該計劃應(yīng)當包括與開發(fā)和鑒定的全部需求(包括安全和保密需求)有關(guān)的特定的標準、方法、行為和責(zé)任。如果需要,要分別制訂計劃。這些計劃應(yīng)當形成文檔并得到實施。

  8.1.5 在軟件的開發(fā)或維護中可以使用不交付項。但是,應(yīng)當保證:
  a.在可交付軟件交給需方之后,它的操作和維護與這些不交付項無關(guān);
  b.這些項變成可交付項。

  8.2 系統(tǒng)需求分析
  此項活動含有開發(fā)者應(yīng)當執(zhí)行或支持的下述任務(wù):

  8.2.1 如第6.1和6.2條所規(guī)定,應(yīng)當對獲取和系統(tǒng)的要求進行分析,以建立系統(tǒng)需求。系統(tǒng)需求應(yīng)當說明:系統(tǒng)的功能和性能;安全、保密、人機工程、接口、操作和維護需求;設(shè)計限制和鑒定的要求。這些系統(tǒng)需求應(yīng)當寫成文檔。

  8.2.2 應(yīng)當對這些系統(tǒng)需求進行評價,使其包括下述準則:可跟蹤性;與獲取及系統(tǒng)要求的一致性;可測試性;以及設(shè)計、操作和維護的可行性。

  8.3 系統(tǒng)設(shè)計
  此項活動含有開發(fā)者應(yīng)當執(zhí)行和支持的下述任務(wù):

  8.3.1 應(yīng)當建立一個高層的系統(tǒng)體系結(jié)構(gòu)。應(yīng)當在系統(tǒng)的體系結(jié)構(gòu)中體現(xiàn)系統(tǒng)的需求,該系統(tǒng)體系結(jié)構(gòu)要表現(xiàn)出系統(tǒng)的內(nèi)部結(jié)構(gòu)以及硬件、軟件和人工操作的配置。應(yīng)當保證:系統(tǒng)需求已完全分配給硬件配置項(HCI)、軟件配置項(SCI)和人工操作。分配給 HCI、 SCI和人工操作的系統(tǒng)體系結(jié)構(gòu)和系統(tǒng)需求要寫成文檔。

  8.3.2 應(yīng)對HCI、SCI和人工操作的系統(tǒng)體系結(jié)構(gòu)和需求進行評價,使其包括下述準則:可跟蹤性、與系統(tǒng)需求的一致性、設(shè)計和所用標準恰當,以及操作和維護的可行性。

  8.4 軟件需求分析
  對于每個SCI,此項活動含有開發(fā)者應(yīng)當執(zhí)行的下述任務(wù):

  8.4.1 開發(fā)者應(yīng)當確定各種需求并將其寫成文檔,其中包括與第2.5條相一致的質(zhì)量特性規(guī)格說明(可操作性、可靠性、可用性、有效性、可維護性和可移植性)。
  該文檔描述:
  a.功能和能力規(guī)格說明,其中包括性能、物理特性、運行軟件的環(huán)境條件;
  b.用戶文檔;
  c.安全規(guī)格說明,其中包括與操作和維護的方法、環(huán)境影響和人員傷害有關(guān)的說明;
  d.保密規(guī)格說明,其中包括對敏感性信息或資料的危害有關(guān)的說明;
  e.人機工程和人一機規(guī)格說明,其中包括與人工操作、人機對話、對人員的限制有關(guān)的規(guī)格說明,以及那些對于人的錯誤和能力很敏感的、需要人集中注意力的領(lǐng)域的說明;
  f.處理器、存儲設(shè)備或數(shù)據(jù)通道所用的硬件處理和資源儲備的規(guī)格說明;
  g.數(shù)據(jù)定義和數(shù)據(jù)庫的需求;
  h.已交付軟件在操作和維護現(xiàn)場上的安裝和驗收的需要;
  i.用戶操作和執(zhí)行的需求;
  j.用戶維護需求。

  8.4.2 開發(fā)者應(yīng)當確定SCI的外部接口的需求并將其寫成文檔。

  8.4.3 開發(fā)者應(yīng)當對SCI的鑒定要求寫成文檔。

  8.4.4 開發(fā)者應(yīng)當對需求作出評價,使其包括下面指出的準則:
  a.對系統(tǒng)需求和系統(tǒng)設(shè)計的可跟蹤性;
  b.與系統(tǒng)需求的外部一致性;
  c.各種軟件需求之間的內(nèi)部一致性;
  d. 軟件需求的可測性;
  e.軟件需求的測試范圍;
  f.軟件設(shè)計、操作和維護的可行性。

  8.4.5 開發(fā)者應(yīng)當依據(jù)第11.3條進行合同所要求的評審,以決定軟件需求的完善和恰當。當評審?fù)瓿蓵r,就應(yīng)當建立SCI需求的基線。

  8.5 軟件體系結(jié)構(gòu)設(shè)計
  對于每個SCI,此項活動含有開發(fā)者應(yīng)當執(zhí)行的下述任務(wù):

  8.5.1 開發(fā)者應(yīng)當把SCI的工程需求轉(zhuǎn)變?yōu)橐粋€體系結(jié)構(gòu),該體系結(jié)構(gòu)應(yīng)描述它的頂層結(jié)構(gòu)和定義它的主要部分。它應(yīng)當保證此項工程和SCI的鑒定要求已完全分配給了各個部分,并對其進行了細化以便進行詳細設(shè)計。應(yīng)當建立SCI體系結(jié)構(gòu)的文檔。

  8.5.2 開發(fā)者應(yīng)當為SCI外部接口的設(shè)計、SCI的各軟件部分之間的設(shè)計建立一個頂層的設(shè)計文檔。

  8.5.3 開發(fā)者應(yīng)當為數(shù)據(jù)庫建立一個頂層的設(shè)計文檔。

  8.5.4 開發(fā)者應(yīng)當評價SCI的體系結(jié)構(gòu)、接口和數(shù)據(jù)庫的設(shè)計,使其包括下面指出的各項:
  a. 對SCI需求的可跟蹤性;
  b.與SCI需求的外部一致性;
  c.各部分需求之間的內(nèi)部一致性;
  d.所使用的設(shè)計方法和標準是否恰當;
  e.詳細設(shè)計、操作和維護的可行性。

  8.5.5 開發(fā)者應(yīng)當依據(jù)第11.3條進行合同所要求的評審,以決定分配給各部分的需求和 SCI體系結(jié)構(gòu)設(shè)計方法的完善和恰當。

  8.6 軟件的詳細設(shè)計
  對于每個SCI,此項活動含有開發(fā)者應(yīng)當執(zhí)行的下述任務(wù):

  8.6.1 開發(fā)者應(yīng)當詳細設(shè)計SCI的每個軟部件。應(yīng)當盡量地將各個軟部件詳細劃分為含有軟件單元的較低的層次,以便進行編碼、編譯和測試。應(yīng)當保證該軟件的需求已完全分配給從軟部件到軟件單元的整個軟件。應(yīng)當把該詳細設(shè)計寫成文檔。

  8.6.2 開發(fā)者應(yīng)當寫出與SCI的外部接口、各軟部件之間和各軟件單元之間的詳細設(shè)計文檔。接口的詳細設(shè)計應(yīng)當足夠詳細以便于編碼。

  8.6.3 開發(fā)者應(yīng)當寫出數(shù)據(jù)庫的詳細設(shè)計文檔。

  8.6.4 開發(fā)者最好寫出軟件用戶手冊的最初版本。

  8.6.5 開發(fā)者應(yīng)當為測試軟件單元規(guī)定測試要求和時間進度,并將其寫成文檔。測試要求中最好包括在軟件需求限定上的重點軟件單元。

  8.6.6 開發(fā)者應(yīng)當為軟件的集成規(guī)定測試要求和時間進度,并將其寫成文檔。

  8.6.7 開發(fā)者應(yīng)當評價軟件的詳細設(shè)計和測試要求,使其包括下面的準則:
  a. 對SCI需求的可跟蹤性;
  b.與體系結(jié)構(gòu)設(shè)計的外部一致性;
  c.各部件和單元的需求之間的內(nèi)部一致性;
  d.所使用的設(shè)計方法和標準是否恰當;
  e.測試、操作和維護的可行性。

  8.6.8 開發(fā)者應(yīng)當依據(jù)第11.3條進行合同所要求的評審,以決定分配給各個部分和單元的需求以及 SCI詳細設(shè)計方法是否完善和恰當。

  8.7 軟件編碼
  對于每個SCI,此項活動含有開發(fā)者應(yīng)當執(zhí)行的下述任務(wù):

  8.7.1 開發(fā)者應(yīng)當進行下述開發(fā)并建立文檔:
  a.開發(fā)每個軟件單元和數(shù)據(jù)庫;
  b.為測試每個軟件單元和數(shù)據(jù)庫而開發(fā)的測試過程和數(shù)據(jù);
  c.為進行軟件集成而開發(fā)的測試過程和數(shù)據(jù)。

  8.7.2 開發(fā)者應(yīng)當測試每個軟件單元和數(shù)據(jù)庫,以保證它們符合需求。測試結(jié)果應(yīng)當寫成文檔。

  8.7.3 必要時,開發(fā)者應(yīng)當更新軟件的用戶手冊。

  8.7.4 開發(fā)者應(yīng)當評價軟件的代碼和測試結(jié)果,使其包括下面的準則:
  a. 對SCI需求和設(shè)計的可跟蹤性;
  b.與 SCI需求和設(shè)計的外部一致性;
  c.各單元需求之間的內(nèi)部一致性;
  d.各單元的測試范圍;
  e.使用的編碼方法和標準是否恰當;
  f.集成、操作和維護的可行性。

  8.8 軟件集成
  對于每個SCI,此項活動含有開發(fā)者應(yīng)當執(zhí)行的下述任務(wù):

  8.8.1 開發(fā)者應(yīng)當制訂計劃把各個軟件單元和軟部件集成為SCI。該計劃應(yīng)當包括測試要求、步驟、數(shù) 據(jù)、責(zé)任和時間表。該集成計劃應(yīng)當寫成文檔。

  8.8.2 在依據(jù)集成計劃開發(fā)集合體時,開發(fā)者應(yīng)當集成軟件的單元、部件和進行測試。應(yīng)當保證每個集 合體都能滿足SCI的需求,并且在集成活動結(jié)束時形成完全集成的SCI。集成和測試的結(jié)果應(yīng)當寫成文 檔。

  8.8.3 必要時,開發(fā)者應(yīng)當更新用戶手冊。

  8.8.4 為了進行軟件的鑒定測試,開發(fā)者應(yīng)當為每個SCI開發(fā)寫出一個完整的測試集、測試用例(輸 入、輸出、測試準則)和測試步驟。開發(fā)者應(yīng)當保證集成后的SCI可以進行軟件鑒定測試。

  8.8.5 開發(fā)者應(yīng)當對集成計劃、設(shè)計、代碼、測試、測試結(jié)果和用戶手冊進行評價,使其包括下面的準 則:
  a. 對 SCI需求的可跟蹤性;
  b.與 SCI需求的外部一致性;
  c.內(nèi)部一致性;
  d.SCI需求的測試范圍;
  e.使用的測試方法和標準是否恰當;
  f.是否符合預(yù)期的結(jié)果;
  g.鑒定測試、操作和維護的可行性。

  8.8.6 開發(fā)者應(yīng)當依據(jù)第11.3條進行合同所要求的評審,以確定測試過程的完善和適當,并確定已經(jīng) 做好軟件鑒定測試的準備。

  8.9 軟件鑒定測試
  對于每個SCI,此項活動含有開發(fā)者應(yīng)當執(zhí)行的下述任務(wù):

  8.9.1 開發(fā)者應(yīng)當依據(jù)為 SCI確定的鑒定要求進行鑒定測試。應(yīng)當保證對每項要求進行符合測試。應(yīng)將鑒定測試結(jié)果寫成文檔。

  8.9.2 必要時,開發(fā)者應(yīng)當更新用戶手冊。

  8.9.3 開發(fā)者應(yīng)當對設(shè)計、代碼、測試、測試結(jié)果和用戶手冊進行評價,使其包括下面的準則:
  a. 對SCI和系統(tǒng)需求的可跟蹤性;
  b.與 SCI和系統(tǒng)需求的外部一致性;
  c.內(nèi)部一致性;
  d.SCI和系統(tǒng)需求的測試范圍;
  e.是否符合預(yù)期結(jié)果;
  f.操作和維護的可行性。

  8.9. 4 開發(fā)者應(yīng)當依據(jù)第 11. 3條支持對 SCI的功能性配置審計(FCA)和物理配置審計(PCA)。在 FCA時,應(yīng)當保證SCI的測試成功并符合需求,而且用戶手冊中充分描述SCI的操作和支持。在PC:A 時,應(yīng)當保證SCI的設(shè)計和源碼完整并正確,反映了SCI的新技術(shù)。FCA和PCA的結(jié)果應(yīng)當寫成文檔。如果同時開發(fā)硬件和軟件,F(xiàn)CA和PCA可以推遲到系統(tǒng)鑒定測試時進行。

  8.9.5 在FCA和PCA成功地完成之后,開發(fā)者應(yīng)當:
  a.為系統(tǒng)集成、系統(tǒng)鑒定測試或適當時的安裝和驗收,更新和準備可交付的軟件;
  b.為SCI的設(shè)計和編碼建立一個基線。

  8.10 系統(tǒng)集成
  此項活動含有開發(fā)者應(yīng)當執(zhí)行或支持的下述任務(wù):

  8.10.1 SCI應(yīng)當與 HCI、人工操作和其它必要的系統(tǒng)一起集成到系統(tǒng)中去。當開發(fā)該集合體時,應(yīng)當對照它們的需求進行測試。應(yīng)當將集成和測試的結(jié)果寫成文檔。

  8.10.2 應(yīng)當為系統(tǒng)的每項已確定的需求進行系統(tǒng)鑒定測試開發(fā)一個完整的測試集、測試用例(輸入。輸出、測試準則)和測試步驟,并將其寫成文檔。開發(fā)者應(yīng)當保證集成的系統(tǒng)已做好系統(tǒng)鑒定測試的準備。 8.10.3應(yīng)當對集成的系統(tǒng)進行評價以使其包括下述準則:系統(tǒng)需求的測試范圍。、所使用的測試方法和標準是否恰當;是否符合預(yù)期結(jié)果;鑒定測試、操作和維護的可行性。

  8.11 系統(tǒng)鑒定測試
  此項活動含有開發(fā)者應(yīng)當執(zhí)行或支持的下述任務(wù):

  8.11.1 應(yīng)當依據(jù)為系統(tǒng)建立的鑒定要求進行系統(tǒng)鑒定測試。應(yīng)當保證每項系統(tǒng)需求都進行符合性測試,而且系統(tǒng)已做好交付準備。應(yīng)當把鑒定測試的結(jié)果寫成文檔。

  8.11.2 應(yīng)當對系統(tǒng)進行評價以使其包括下述準則:系統(tǒng)需求的測試范圍;是否符合預(yù)期的結(jié)果;操作與維護的可行性。

  8.11.3 本項需求不適用于已經(jīng)進行過 FCA、PCA的 SCI。 SCI的 FCA和 PCA應(yīng)當依據(jù)第 11.3條進行。在成功地完成FCA和PCA后,
  a. 可交付的SCI應(yīng)當更新并做好驗收安裝和支持的準備;
  b.應(yīng)當為每個SCI的設(shè)計和代碼建立基線。

  8.12 驗收所需要的安裝和支持
  此項活動含有下述開發(fā)者應(yīng)當執(zhí)行的任務(wù):

  8.12.1 開發(fā)者應(yīng)當制定一個合同中指明的、在目標環(huán)境中安裝軟件的計劃。應(yīng)當指出與軟件的安裝有關(guān)的必要的資源和信息并保證提供。開發(fā)者應(yīng)當以適當?shù)姆绞綆椭璺降玫脚c系統(tǒng)建立活動有關(guān)的信息。當所安裝的軟件替代了現(xiàn)有的系統(tǒng)時,開發(fā)者應(yīng)當支持合同所要求的并行運行的活動。應(yīng)當將安裝情況寫成文檔。

  8.12.2 開發(fā)者應(yīng)當依據(jù)安裝計劃安裝軟件。應(yīng)當保證該軟件和數(shù)據(jù)庫能按照合同的規(guī)定初始化、執(zhí)行和終止。應(yīng)當把安裝情況及其結(jié)果寫成文檔。

  8.12.3 開發(fā)者應(yīng)當支持需方對軟件(或系統(tǒng))的驗收評審和測試。驗收評審和測試應(yīng)當考慮 FCA、 PCA、軟件鑒定測試和系統(tǒng)鑒定測試(如果進行系統(tǒng)鑒定測試)的結(jié)果。應(yīng)當把驗收評審和測試的結(jié)果寫成文檔。

  8.12.4 開發(fā)者應(yīng)當按照合同的規(guī)定完成文檔和編碼并交付給需方。

  8.12.5 開發(fā)者應(yīng)當按照合同的規(guī)定向需方提供初始的和繼續(xù)的培訓(xùn)和支持。

12 過程的建立、評價和改進

  本章含有要建立、評價、測量、控制和改進軟件生存期過程的活動。
  此項過程含有下述活動:
  a. 過程建工;
  b. 過程評價;
  c. 過程改進。

  12.1 過程建立

  此項活動含有下述任務(wù): 因為在業(yè)務(wù)活動中機構(gòu)要具有獲取、供應(yīng)、開發(fā)、操作、維護功能,所以,機構(gòu)應(yīng)當為這些活動建立一套過程。應(yīng)當將這些過程以及它們在特殊情況下的應(yīng)用寫成文檔,并寫進公司的出版物中。在適當?shù)那闆r下,最好建立一個過程控制機制以開發(fā)、監(jiān)督、控制和改進這些過程。

  12.2 過程評價

  此項活動含有下述任務(wù): 最好制訂一個過程評價步驟,將它寫成文檔并使用它。最好能保存并維護評價記錄。

  12.3 過程改進

  此項活動含有下述任務(wù): 最好用過程評價的結(jié)果來改進機構(gòu)的過程。最好能更新過程的文檔,使其反映機構(gòu)過程中的改進。

  附錄A 剪裁過程(補充件)

  本附錄定義為一個軟件項目剪裁本標準時所需要的基本活動和步驟。附錄B剪裁指南(參考件)是對剪裁本標準的要求的簡要說明。
  本剪裁過程含有下述活動:
  —指定項目的環(huán)境;
  —輸入請求;
  —選擇標準的單元;
  —把剪裁決定和理由寫成文檔。

  AI 指定項目的環(huán)境

  此項活動含有下述任務(wù):
  應(yīng)當指出將影響剪裁的項目環(huán)境的特性。可能的特性是:生存周期模型;當前的系統(tǒng)生存周期階段; 系統(tǒng)和軟件的需求;機構(gòu)所采用的方針、過程和策略;系統(tǒng)和軟件的規(guī)模、類型和關(guān)鍵性;所涉及的人數(shù) 和當事各方等。

  A2 輸人請求

  此項活動含有下述任務(wù):
  應(yīng)當征求將要受剪裁影響的機構(gòu)的請求并輸入。用戶、支持人員、簽訂合同的官員和潛在的投標人 最好參與剪裁。

  A3 選擇標準的單元

  此項活動含有下述任務(wù):

  A3.1 應(yīng)當根據(jù)在AI和 A2中收集的數(shù)據(jù),對照本標準的每一章,決定要執(zhí)行本標準的哪些過程、活動和任務(wù),要開發(fā)什么文檔,誰將負責(zé)等。

  A3.2 本標準中,要求是用含有“應(yīng)”、“應(yīng)當”和“將”“將要”的句子來指明的。最好認真考慮在特殊項目 中是否把這些要求包括進去。要考慮的因素有(但不僅僅限于這些):風(fēng)險、成本、時間進度、性能、規(guī)模、 關(guān)鍵性和人機界面。

  A4 把剪裁決定和理由寫成文檔

  此項活動含有下述任務(wù):
  應(yīng)當把全部剪裁決定及做這些決定的理由寫成文檔。

  附錄B 剪裁指南 (參考件)

  同樣的項目是不存在的。在諸多的因素中,機構(gòu)所采用的方針和步驟、獲取方法和策略、項目的規(guī)模和復(fù)雜性、系統(tǒng)需求和開發(fā)方法等因素影響著一個系統(tǒng)的獲取、開發(fā)、操作和維護的方式。本標準是為通用項目編寫的,以盡可能地適應(yīng)各種變化。因此,為了降低成本和改進質(zhì)量,最好針對具體項目剪裁本標準。項目的有關(guān)各方最好參與剪裁。

  B1 通用的剪裁指南

  本章提供與本標準有關(guān)的剪裁指南,但不詳述。圖BI示出剪裁過程。本章可用來為一個項目完成” 對本標準的第一級剪裁。本章是根據(jù)地區(qū)的用途實現(xiàn)剪裁。

  B2 開發(fā)過程的剪裁

  要特別注意開發(fā)過程(第8章),因為此過程可以為具有不同目的的不同機構(gòu)所使用。作為此過程的第一級剪裁,建議進行以下活動。對于包含在系統(tǒng)內(nèi)或集成到系統(tǒng)中的軟件:
  a. 此過程中的全部12個活動最好都考慮;
  b.最好區(qū)分開發(fā)者是否要完成或支持系統(tǒng)的活動。 獨立的、不是系統(tǒng)一部分的軟件可能不需要第8.2、8.3、8.10和8。11條中的用于系統(tǒng)的活動,但最好考慮其它的活動。

  B3 與評價有關(guān)的活動的剪裁

  與一個項目或一個過程的生存周期的某個階段有關(guān)的任何人都要對自己的或他人的產(chǎn)品或服務(wù)進行評價。該標準把這些評價分為下述五類。前四類評價與項目有關(guān),第五類評價與過程有關(guān)。最好根據(jù)項目或過程的范圍、規(guī)模、復(fù)雜性和關(guān)鍵性適當?shù)剡x擇和剪裁這些評價活動。把從這些評價中產(chǎn)生的問題、不符合之處和改進的報告反饋給改正過程(第11.6條)。

  a. 過程內(nèi)的評價(第5、6、7、8、、9和10章的評價任務(wù))。由在此過程中執(zhí)行指定任務(wù)的人員在他們的日常活動中進行。

  b.合同要求的評審和審計(第11.3條)。由需方和供方按照事先同意的時間表正式進行。

  c.(獨立的)驗證和確認(第11.4條)。由需方、供方或獨立的第三方進行,根據(jù)項目對產(chǎn)品或服務(wù)進行不同程度的評價。此項評價并不代替其它種類的評價,只是其它評價的補充。

  d.軟件質(zhì)量保證(第11.5條)。由對開發(fā)該產(chǎn)品或?qū)嵤┰摲?wù)的直接責(zé)任人之外的人員進行獨立的質(zhì)量保證。進行獨立的保證的目的是使產(chǎn)品或服務(wù)與合同的要求相符,并堅持已制訂的計劃。

  e.過程建立、評價和改進(第12章)。這些活動由一機構(gòu)實施,以對過程進行有效的管理和自我改進。這種評價活動與合同的要求無關(guān)。

  B4 剪裁的考慮因素

  本章中的各段指出了為此項目的關(guān)鍵特性在剪裁時要考慮的廣泛的因素。此處對這些考慮因素和特性不作詳述,只陳述目前的一些想法。

  B4.1 機構(gòu)所采用的方針

  指出機構(gòu)所采用的方針。例如關(guān)于計算機語言、安全和保密、硬件儲存需求、風(fēng)險管理等等。 應(yīng)當保留本標準中與機構(gòu)的方針有關(guān)的章條。

  B4.2 獲取策略

  指出項目的獲取策略。例如合同的類型、多項合同、分包商和v&v構(gòu)的介入、需方作為合同當事人介入的程度、對合同當事人能力的評價等等。 應(yīng)當保留本標準中與這些策略有關(guān)的章條。

  B4.3 支持的概念

  指出支持的概念。例如需方或合同當事人預(yù)期應(yīng)當支持的時間、變化的程度等。 如果軟件將有較長的支持壽命或預(yù)期有較大的改變,最好考慮全部的文檔需求。建議自動生成文檔。

  B4.4生存周期模型

  指出項目的生存周期模型。例如瀑布式、交互瀑布式、漸進式、積木式、預(yù)期的產(chǎn)品改進等。 所有的這些模型描述了可以有順序地、重復(fù)地或組合地完成的一些過程和活動。在這些模型中,本標準中的生存周期活動最好映射到所選擇的模型中。對于漸進式的、積木式的和預(yù)期的產(chǎn)品改進模型,項目的一個階段的輸出就是下一個階段的輸入。在這些情況下,最好在每項活動完成時提交文檔。

  B4.5 所涉及的各方

  指出此項目所涉及的當事各方。例如需方、供方、開發(fā)者、分包商、v&v機構(gòu)、維護者和人員的數(shù)量。 與當事雙方之間(例如需方一開發(fā)者,供方一v&v機構(gòu)等)有關(guān)的全部需求都要考慮。 涉及許多(幾十或幾百)人的大項目需要大量的管理性監(jiān)督和控制。對于一個大項目,內(nèi)部的、合同需求的和獨立的評價、評審、審計和檢測、數(shù)據(jù)收集等都是很重要的工具。對于小項目,這些控制可以是 多余的。

  B4.6 生存周期的階段

  指出系統(tǒng)的生存周期當前階段。例如需方的項目起動,供方的開發(fā)、維護等,例如下述情況: 需 方在提出或定義系統(tǒng)需求時,可能要對需求和設(shè)計進行可行性研究和原型制作,也可能要編寫原 型的軟件代碼,這些代碼在以后按照合同開發(fā)軟件時可能用到,也可能用不到;可能是開發(fā)系統(tǒng)需求和 最初的軟件需求,在這種情況下,第8章的開發(fā)過程可以作為開發(fā)指南使用,而不是作為需求使用;可能 不需要嚴格的鑒定和評價;合同所要求的評審和審計也可能不需要。 開發(fā)者在按照合同生產(chǎn)軟件的情況下,剪裁時最好考慮全部的開發(fā)過程(第8章)需求。 維護者要修改軟件和文檔,在考慮維護過程(第10章)時,開發(fā)過程(第8章)的各部分可以作為子 過程使用。

  B4.7 系統(tǒng)的層次特性

  指出系統(tǒng)的層次特性,例如子系統(tǒng)的數(shù)量和配置項等。 如果系統(tǒng)有許多子系統(tǒng)或配置項,最好謹慎地為每個子系統(tǒng)和配置項剪裁開發(fā)過程(第8章)。最好 考慮全部的接口和集成需求。

  B4.8 軟件的層次特性

  指出軟件的層次特性,例如軟件配置項(SCI)的數(shù)量,軟件的類型、規(guī)模和關(guān)鍵性,技術(shù)風(fēng)險等。 如果軟件有許多SCI、部件或單元,最好謹慎地為每個SCI剪裁開發(fā)過程(第8章)。最好考慮全部 的接口和集成需求。

  決定何種類型的軟件包括在內(nèi),因為不同類型的軟件可以需要不同的剪裁決定。例如:

  a. 新開發(fā)的軟件。考慮全部的需求,特別是開發(fā)過程(第8章)。

  b.照原樣使用現(xiàn)成的軟件。開發(fā)過程(第8章)可能是多余的。最好評價與該軟件有關(guān)的性能、文 檔、產(chǎn)權(quán)和未來的支持。

  c.修改現(xiàn)有的軟件。可以沒有文檔。最好依據(jù)關(guān)鍵性和所預(yù)期的未來的改變,通過維護過程(第 10章)來使用開發(fā)過程(第8章)。最好評價與該軟件有關(guān)的性能、文檔、產(chǎn)權(quán)和未來的支持。

  d.包含在一個系統(tǒng)中的或集成進一個系統(tǒng)的軟件或固件。既然這種軟件是一個大系統(tǒng)的一部分,最好考慮開發(fā)過程(第8章)中與該系統(tǒng)有關(guān)的活動。在與系統(tǒng)有關(guān)的活動中,只需要選擇詞匯“執(zhí)行”或是“選擇”。 如果在未來不可能修改該軟件或固件,最好仔細審計文檔需要的范圍。

  e.獨立的軟件。既然該種軟件不是一個系統(tǒng)的一部分,就不必考慮開發(fā)過程(第8章)中與系統(tǒng)有關(guān)的活動。最好仔細審查文檔需求,尤其是維護文檔的需求。

  f.不交付軟件。既然沒有任何一項被獲取、供應(yīng)或開發(fā),最好不考慮除開發(fā)過程的第8。1.5條之外的其它章條。但是,如果需方?jīng)Q定獲取這種軟件中的一個軟件用于未來的操作和維護,那么,這個軟件最好按照b條或c條中的軟件對待。

  B4.9 其它考慮因素:

  系統(tǒng)越是依賴于軟件的正確操作和及時完成,就越是要通過測試、評審、審計、V&V等來加強管理控制。但是,對非關(guān)鍵性的軟件或小軟件加強管理反而不會降低成本。 軟件的開發(fā)可能有技術(shù)風(fēng)險。如果采用的軟件技術(shù)是不成熟的,正在開發(fā)的軟件是前所未有的或是復(fù)雜的,或者,軟件含有安全和保密的重要需求,那么,就可能需要嚴格的規(guī)范、設(shè)計、測試和評價。獨立的V&V就可能是很重要的。

  附加說明:

  本標準由中華人民共和國電子工業(yè)部提出。
  本標準由電子工業(yè)部標準化研究所歸口。
  本標準由中國計算機軟件與技術(shù)服務(wù)總公司負責(zé)起草。
  本標準主要起草人周明德、賈耀良、王桂蘭。
  本標準于 1988年 7月首次公布。

非常好我支持^.^

(0) 0%

不好我反對

(0) 0%

( 發(fā)表人:admin )

      發(fā)表評論

      用戶評論
      評價:好評中評差評

      發(fā)表評論,獲取積分! 請遵守相關(guān)規(guī)定!

      ?
      百家乐送彩金平台| 大发888老l| 八大胜百家乐娱乐城| 网上百家乐官网公司| 华侨人百家乐官网的玩法技巧和规则 | 958棋牌游戏| 利来娱乐开户| 永善县| 百家乐官网娱乐天上人间| 百家乐官网投注平台信誉排名 | 土豪百家乐官网的玩法技巧和规则 | 华宝娱乐城| 丰县| 网上百家乐官网是假| 百家乐官网博娱乐网赌百家乐官网| 百家乐官网赌博走势图| 任我赢百家乐官网软件| 百家乐视频大厅| 致胜百家乐软件| 大发8888游戏平台| 网络赌博网站| gt百家乐官网平台假吗| 大上海百家乐官网的玩法技巧和规则 | 百家乐官网玩法说明| 百利宫百家乐官网现金网| 沙龙百家乐官网娱乐网| 游戏百家乐押发| 网页百家乐的玩法技巧和规则 | 百家乐游戏机破解方法| 大发888的任务怎么做| 现金娱乐城| 百家乐官网楼梯缆 | 太阳百家乐官网娱乐| 百家乐007| 大发888官方ylc8| 在线百家乐投注| 百家乐官网在线赌场| 百家乐娱乐城介绍| 大发888真钱游戏玩法| 三明市| 星期8百家乐官网娱乐城|