2025年信息系統項目管理師法律法規(guī)與行業(yè)標準深度解析_第1頁
2025年信息系統項目管理師法律法規(guī)與行業(yè)標準深度解析_第2頁
2025年信息系統項目管理師法律法規(guī)與行業(yè)標準深度解析_第3頁
2025年信息系統項目管理師法律法規(guī)與行業(yè)標準深度解析_第4頁
2025年信息系統項目管理師法律法規(guī)與行業(yè)標準深度解析_第5頁
已閱讀5頁,還剩50頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

附錄一原則部分

第一章開發(fā)原則

1.1GB/T8566.信息技術軟件生存周期過程

GB/T8566原則為軟件生存周期過程建立了?種公共框架,可供軟件產業(yè)界參照。它包括在具有軟件的系統、獨立軟件產品和

軟件服務的獲取期間以及在軟件產品的獲取、供應、開發(fā)、運行和維護的公共軟件過程體系構造。該原則也提供了為管理和改善過

程的必要的支持過程、任務和活動,以及組織過程、任務和活動。軟件包括固件的軟件部分。

1.部分術語定義

一件生存周期是指軟件從構思開始至軟件退伍為止的軟件發(fā)生、發(fā)展直至軟件退伍(死亡)的整個生存周期。為開發(fā)高水平、

高質量的軟件(尤其是大型軟件),軟件的開發(fā)和維護,需要由過程來控制和管理。

及用周境:顧客、任務、設備(硬件、軟件和資料)以及產品使用的物理和社會環(huán)境■:

GB/T8566構造

5生存周期基本過程6生存周期支持過程7生存周期組織過程

6.1文檔編制過瓦"

7.1管理過程

5.1獲取過程

6.2配置管理過程

7.2基礎設施過程

5.2供應過程6.3質量保證麗"

7.3改進過程

15.3開發(fā)過程6.4驗證過程

6.5福認過程

15.4運作過程Z4人力資源過程

聯評審過程

15.5維護過程6.667.5資產管理過程

6.7審核過程

|7.6重用大綱管理過程

6.8問題解決麗"

7.7領域工程管理過程

6.9易用性過程

2.1生存周期基本過程

生存周期基本過程包括5個過程:

a)獲取過程一一為雷方而定義的活動;

b)供應過程一一為供方而定義的活動:

c)開發(fā)過程一一為開發(fā)方而定義的活動:

d)運作過程一一為操作方而定義的活動:

e)維護過程——為維護方面定義的活動。也就是對軟件的修改善行管理,使它保持合適的運行狀態(tài)。該過程包括軟件產品的遷

移和退伍。

2.2生存周期支持過程

生存周期支掙過程包括g個迎程。支持過程以明確的目的作為構成整體所必須的部分文持其他過程(重要是基本過程)。有助

于軟件項目的成功和提高質量。支持過程按照其他過程的需要采用和執(zhí)行。支持過程有?:

a)文檔編制過程一一為記錄生存周期過程所產生的信息而定義的活動:

b)配置管理過程一一定義配置管理活動:

c)質量保證過程一一為客觀地保證軟件產品和過程符合規(guī)定的需求以及已建立的計劃而定義的活動。聯合評審、審核、驗證

和確承認以作為質量保證技術使用:

d)驗證過程一一根據軟件項目需求,按不一樣深度(為需方、供方或某獨立方)驗證軟件產品而定義的活動:

e)確認過程一一(為需方、供方或其獨立方)確認軟件項目的軟件產品而定義的活動;

:)聯合評審過程一一為評價一項活動的狀態(tài)和產品而定義的活動。該過程可由任何兩方應用,其中一方(評審方)以聯合討

論會的形式評審另一方(被評審方);

g)審核過程一一為鑒定符合需求、i-劃和協議而定義的活動。該過程可由任何兩方應用,其中一方(審核方)審核另一方(被

審核方)的軟件產品或活動。

h)問題處理過程一一為分析和處理問題(包括不合格)而定義的活動,不管問題的性質或來源怎樣,它們都是在實行開發(fā)、

運作.維護或其他過程期間暴露出來的;

i)易用性過程一一為易用性專業(yè)人員而定義的活動。

2.3生存周期組織過程

生存周期組織過程包括7個過程:

a)管理過程一一為生存周期過程中的管理包括項目管理而定義的基本活動:

b)基礎設施過程一一為建立生存周期過程基礎設施而定義的基本活動;

c)改善過程一一為某一組織(即需方,供方,開發(fā)方,操作方,維護方,或另一過程的管理者)建立、測量、控制和改善其

生存周期過程而定義需要執(zhí)行的基本活動:

d)人力資源過程——為給組織或項目擁有技能和知識的員工而定義的活動;

e)資產管理過程——為組織的資產管理者而定義的活動:

:)重用大綱管理過程一一為組織的亙用大綱主管而定義的活動;

g)領域工程管理過程一一為領域模圓、領域體系構造確實定及該領域資產的開發(fā)和維護而定義的活動。

三類過程的關系

?基本過程是針對不?樣的使用者而規(guī)定獲取、開發(fā)、維護軟件需要開展的活動及任務;

?支持過程是規(guī)定為支持實行基本過程而需耍開展的活動及任務:

?組織過程是規(guī)定為支持實行基本過程和支持過程而在組織層面而需要開展的活動及任務。

2.4過程與組織

2.4.3開發(fā)方與開發(fā)過程

開發(fā)過程包括開發(fā)方的活動和任務。開發(fā)過程的活動是:(1)過程實行:(2)系統需求分析;(3)系統構造設計:(4)軟件雷

求分析:(5)軟件構造設計:(6)軟件詳細設計:(7)軟件編碼和測試:(8)軟件集成:(9)軟件合格性測試:(10)系統集成:

(11)系統合格性測試;(12)軟件安裝;(13)軟件驗收支持。

開發(fā)方按照管理過程在項目級上管理本條中詳細闡明的開發(fā)過程。按照基礎設施過程建立該過程的基礎設施;按照剪裁過程為

該項目剪裁不過程:按照改善過程和培訓過程在組織級上管理本過程。當開發(fā)者是所開發(fā)的軟件產品的供方時,開發(fā)者要執(zhí)行供應

過程,

I.2GB/T15853-1995軟件支持環(huán)境

本原則規(guī)定了軟件支持環(huán)境的基本規(guī)定,軟件開發(fā)支持環(huán)境的內容及實現措施,以及對軟件生存期支持部門軟件支持能力的詳

細規(guī)定.本原則合用于軟件支持環(huán)境的設計、建立、管理和評價.

3.2任務委托單位指定的資源一一由任務委托單位向承接單位指明,要在所開發(fā)的軟件支持環(huán)境中包括并使用的資源。

3.4宿主機系統一一為研制用于一種或多種目的機系統的軟件而需要的硬件設備、系統軟件、支持軟件及規(guī)程。一種宿主機系統

此外丕也許包括:

a.目的機系統的某些基本部件;b.目的機系統的變型、模擬或仿真;

c.供開發(fā)或支持某些運行軟件和支持軟件用的專用軟件或專用設備。

3.6軟件支持環(huán)境-----種宿主機系統,加上其他有關的設備和規(guī)程而構成。它能對目的機系統的軟件提供全面的支持,包括:

性能泮價、系統與軟件生成、開發(fā)與修改測試、模擬與仿真、培訓、軟件集成、配置管理、以及軟件的運行分派。

軟件支持環(huán)境又可分為如下兩種類型:

3.6.1軟件開發(fā)支持環(huán)境一一由軟件承接單位確定、并經任務委托單位承認的資源,用于支持協議項目中的軟件需求。

3.6.2軟件生存期支持環(huán)境一一由軟件生存期支持部門使用的(屬于任務委托單位的)資源,用于為指定的目的機系統提供整個生存

期內的軟件支持。

3.8目的機系統一一作為運行系統一部分的計算機硬件、軟件以及規(guī)程。

4.1軟件支持環(huán)境

承接單位必須規(guī)定、實現并集成所有軟件及有關項目,以用于開發(fā)和支持按協議應交付的軟件。承接單位還必須確定應推薦給

軟件生存期支持部門的所有軟件,以便支持按協議交付的軟件在整個生存期內正常運行。此外,還必須向軟件生存期支持部門提供

某些措施,以保證其有能力執(zhí)行對按協議交付的軟件的支持。必須在承接的軟件項目末動工前,先將所提供的措施報送任務委托單

位審執(zhí)

5.1軟件開發(fā)支持環(huán)境

承接單位必須實現一種開發(fā)用的軟件支持環(huán)境,以便為開發(fā)和支持按協議交付的軟件提供服務。承接單位必6對提供軟件開發(fā)

支持環(huán)境的有關問題進行描述,該環(huán)境要能提供所需的支持服務,并且要同軟件生存期支持環(huán)境完全兼容。承接單位必須闡明怎樣

保證軟件生存期支持環(huán)境中所規(guī)定的支持能力。承接單位必須在所提議的軟件開發(fā)支持環(huán)境實現措施獲得任務委托單位的承認后,

才能在協議規(guī)定的軟件項目中使用。

5.1.1實現軟件開發(fā)支持環(huán)境的基礎

對協議規(guī)定的所有軟件的開發(fā),都是任宿上機系統中駐留有廣泛的支持夷件這樣一種環(huán)境中進行的。

5.1.2軟件開發(fā)支持環(huán)境確實定

除任務委托單位另有規(guī)定外,承接單位可以提議使用軟件生存期支持部門的資源,或承接單位內部的軟件開發(fā)資源,或者采用

這兩者的組合。承接單位在提議使用商品軟件或自行開發(fā)的軟件時,必須認真考慮有關問題,包括:所需費用的分析,長期依賴于

間接承接單位及廠商的風險,以及軟件版本的更新等。必須闡明同軟件生存期支持環(huán)境的界面,并使軟件開發(fā)支持環(huán)境同任務委托

單位規(guī)定的運行需求和支持需求和?致。所提議的軟件開發(fā)支持環(huán)境?經同意,承接單位對它的任何修改,都必須得到任務委托單

位的承認。

5.1.3軟件開發(fā)支持環(huán)境的內容

較件開發(fā)支持環(huán)增應提供一組確定的顧客/系統界面、一組軟件支持工具,以及一種中心庫(該中心庫既用于存儲軟件,也用

于存諸在協議規(guī)定的軟件的開發(fā)階段及整個生存期內用到的所有信息)。此外.還必須做到,所有軟件可用源碼形式存儲,也可用

宿主機或特定目的機編譯過的形式存儲。軟件開發(fā)支持環(huán)境還必須提供一種管理語言,由它提供對顧客和中心庫信息的接口。軟件

支持工具必須包括用于軟件開發(fā)、測試、保障、維護及配置管理等方面的工具。軟件開發(fā)支持環(huán)境必須具有項目管理、文檔管理及

釋放密制等功能。任務委托單位可以規(guī)定軟件開發(fā)支持環(huán)境中用的多種專用數據庫、工具、接口及規(guī)程。

5.1.4軟件開發(fā)支持環(huán)境的運行

承接單位必須在軟件開發(fā)支持環(huán)境中建立存取、使用、生成和修改所有軟件的規(guī)程和控制措施。至少必須規(guī)定數據庫的使用和

控制、軟件生成、軟件運行、軟件配置管理、軟件質量評估和軟件故障匯報等方面的開發(fā)規(guī)定,這些規(guī)定必須在所有軟件的開發(fā)中

付諸實行。

5.2軟件開發(fā)支持環(huán)境的實行

在任務委托單位同意后,承接單位就可以實行所提議的軟件開發(fā)支持環(huán)境。承接單位必須按如下各條管理任務委托單位提供

的軟件。

集成規(guī)定承接單位必須保證將任務委托單位提供的軟件、商品軟件、自行開發(fā)的軟件及將由承接單位開發(fā)的軟件對的地集

成到軟件開發(fā)支持環(huán)境中,并同軟件生存期支持環(huán)境兼容。

文檔規(guī)定任務委托單位提供的軟件、商品軟件、自行開發(fā)的軟件及將由承接單位開發(fā)的軟件的文檔和交付規(guī)定,必須按協

議的規(guī)定完畢。

質量保證規(guī)定承接單?位必須在軟件質量保證計劃中,列入必要的規(guī)程,以保證所用的任務委托單位提供的軟件、商品軟件、

自行開發(fā)的軟件及將由承接單位開發(fā)的軟件滿足規(guī)定規(guī)定,并集成到軟件開發(fā)支持環(huán)境中。

配置管理規(guī)定承接單位必須在軟件配置管理計劃中,列入必要的規(guī)程,以防止這些任務委托單位提供的軟件、商品軟件、

自行開發(fā)的軟件及將由承接單位開發(fā)的軟件被越權修改。

軟件修改未經任務委托單位同意,承接單位不得對任務委托單位提供為軟件、商品軟件、自行開發(fā)的軟件及將由承接單位

開發(fā)的軟件作任何修改。要作修改時,必須指明這種修改對協議規(guī)定的軟件,對軟件開發(fā)支持環(huán)境、以及對軟件生存期支持環(huán)境的

影響

驗收規(guī)定除任務委托單位已規(guī)定的驗收原則外,任務委托單位提供的軟件、商品軟件、自行開發(fā)的軟件及將由承接單位開

發(fā)的枚件驗收,必須以與軟件生存期支持環(huán)境的兼容性,及與否圓滿處理權限問題為根據。

1.3GB/T14079-1993軟件維護指南

.本原則描述軟件維護的內容和類型、維護過程及維護的控制和改善。本原則合用于軟件生存周期的運行和維護階段,重要供軟

件管理人員和維護人員使用0

3.4同級評審一一?種質量保證措施,由兩個或多種同級程序員互相檢查、評估,以保證被檢查內容對的,且與軟件的其他部分

相一致。

4軟件維護的內容與類型

軟件維護是在軟件產品交付使用之后,為糾正故障,改善性能和其他屬性,或使產品適應變化了的環(huán)境所進行的修改活動。

4.1完善性維護一一完善性維護是為擴充功能和改善性能而進行修改和擴充,以滿足顧客變化了的需求。重要內容包括:

a.為擴充或增強功能而作的修改(如擴充解題范困和算法優(yōu)化):

b.為提高性能而作的修改(如提高精度,節(jié)省存儲空間等):

c.為便于維護而作的修改(如增長注解,改善易讀性)。

4.2適應性維護一一適應性維護是為適應軟件運行環(huán)境的變化而作的修改,變化的重要內容包括:

a.影響系統的規(guī)定、法律和規(guī)則的變化;

b.硬件配置的變化,如機型、終端、打印機等的變化:

c,數據格式或文卷構造的變化;

<1.系統軟件的變化,如操作系統、編譯系統或實用程序的變化。

4.3改正性維護一一改正性維護是為維持系統操作運行,對在開發(fā)過程產生而在測試和驗收時沒有發(fā)現的錯誤而進行的改正。所必

需改正的錯誤包拈?:

a.設計錯誤;b.邏輯錯誤;c.編碼錯誤;d.文檔錯誤:e.數據錯誤。

5軟件維護過程

一件生存周期中的維護階段一般[起始于軟件產品交付給顧客、顧客驗收之時|。軟件維護與軟件開發(fā)有許多相似的活動,但也有

其獨特之處:

a.維護活動限定在已經有系統的框架之內完畢,維護人員必須在已經有的設計和編碼構造的約束下作出修改,-?般系統越舊,

軟件維護越困難和越費時。

b.一般軟件維護階段的時間比軟件開發(fā)的時間長得到,但一項詳細的軟件維護一般比該軟件的開發(fā)麗短得多|。

C.軟件開發(fā)必須從無到有產生所有測成數據.而軟件維護?般可以使用既有的測試數據進行回歸測試.有時還要產生新的數

據,對軟件修改及修改后的影響進行必要的測試。

6軟件維護的控制和改善

軟件維護要由軟件域子宜來負責控制和修改系統。

一種系統不僅在開發(fā)時要考慮到維護,還要在維護時考慮到未來的維護。

6.1軟件維護的控制

軟件系統的可維護性常常伴隨時間的推移而減少。

軟件維護的目的是保持系統功能和及時、滿意地響應顧客的祈求。

軟件維護的控制是保持一種有秩序的維護過程,所有的維護祈求要制式提出、評審,予以一種優(yōu)先級并安排進度。

6.1.1確立軟件維護的方略

一件維護方略應充足地描述軟件維護組織的貢任、權利、職能及操作,它應全面地考慮到軟件系統和它的環(huán)境的任何類型變化。

該方略應由軟件維護管理機構制定和支持。

軟件維護方略必須詳細地論述修改的需要和理由、修改的責任和環(huán)節(jié)。規(guī)定控制修改軟件的過程和環(huán)節(jié),使祈求的修改從提議

到完畢有控制地進行。保證維護方略的貫徹執(zhí)行,需進行評審和審計。

6.1.2評審和評價所有修改祈求

a.所有的修改規(guī)定應先提出正規(guī)的書面祈求;b.評審所有修改祈求:c.分析和評價修改祈求的類型和額度;

d.考慮對修改的需要程度和它可預見的使用,所有修改都需有充足的理由;

e.評價修改,以保證與本來的系統設計和用意不沖突,對每個修改都應當仔細考慮其影響:

f應尤其強調確定所提議的修改是增強還是減少系統的性能:g僅當修改的效益超過其成本時方可修改。

6.1.5強制實行文檔原則和編碼約定

必須貫徹編碼約定和文檔原則,以對軟件維護人員的所有工作進行常常不停的強制性評審和檢查。在開始一項新的維護工作之

前,應當為更新文檔分派足夠的時間。

6.2軟件維護的改善

■維護性是對軟件進行修改的難易.程度。一種系統的可維護性必須放在系統的整個生存周期中加以考慮。在系統最初的設計和

開發(fā)階段就應考慮到可維護性。

6.2.1.6編譯程序擴展

一用編譯程序的非原則特性會嚴重影響系統的可維護性。假如編譯程序更改了,或假如系統必須移至新機器,則此前的編譯程

序擴展很也許與新的編譯程序相沖突。因此最佳限制語言的擴展和保留語言基本特性的一致。假如需要使用編譯程序擴展,應編制

良好文檔加以闡明。

第二章文檔原則

2.1GB16680-1996軟件文檔管理指南

本原則是針對文檔編制管理而提出的.不池及軟件文檔的內容和編排.

三、定義

1.文檔----種數據媒體和其上所記錄的數據。它具有永久性并可以由人或機器閱讀。一般僅用于描述人工可讀的內容。例

如,技術文獻、設計文獻、版本闡明文獻。

3.文檔計劃一一一種描述文檔編制工作措施的管理用文檔。該計劃一要描述要編制什么類型的文檔,這些文檔的內容是什么,

何時幅寫,由誰編寫,怎樣編寫,以及什么是影響期望成果的可用資源和外界原因。

4.文檔等級一一對所需文檔的一種闡明,它指出文檔的范圍、內容、格K及質星,可以根據項目、費用、預期用途、作用范

圍或其他原因選擇文檔等級。

四、軟件文檔的作用

(-)管理根據;(二)任務之間聯絡的憑證;(三〉質量保證;(四)培訓與參照;(五)軟件維護支持;(六)歷史檔案。

(-)管理根據

開發(fā)文檔規(guī)定若干個檢查點和進度表,使管理者可以評估項目的進度,假如開發(fā)文檔有遺漏,不完善,或內容陳舊,則管理者

將失去跟蹤和控制項目的重要根據。

(二)任務之間聯絡的憑證

大多數軟件開發(fā)項目一般被劃提成若干個任務,并由不一樣的小組去完畢。人員需要的互相聯絡是通過文檔資料的宴制、分發(fā)

和引用而?實現的,因而,任務之間的聯絡是文檔的一種重要功能°

(三)質量保證

那些負責軟件質量保證和評估系統性能的人員需要程序規(guī)格闡明、測試和評估計劃、測試該系統用的多種質量原則以及有關期

望系統完畢什么功能和系統怎樣實現這些功能的清晰闡明:必須制定測試計劃和測試規(guī)程,并匯報測試成果:他償還必須闡明和評

估完全、控制、計算、檢查例行程序及其他控制技術。這些文檔的提供可滿足質量保證人員和審查人員上述工作的需要。

(四)培訓與參照軟件文檔使系統管理員、操作員、顧客、管理者和其他有關人員理解系統怎樣工作,以及為了到達他們的

各自的目的,怎樣使用系統。

(五)軟件維護支持維護人員需要軟件系統的詳細闡明以協助他們熟悉系統,找出并修正錯誤,改善系統以適應顧客需求的變

化或適應系統環(huán)境的變化。

(六)歷史檔案軟件文檔可用作未來項目的一種資源。一般文檔記載系統的開發(fā)歷史,可使有關系統構造的基本思想為后來

的項目運用。良好的系統文檔有助于把程序移植和轉移到多種新的系統環(huán)境中。

五、管理者的作用

管理者嚴格規(guī)定軟件開發(fā)人員和編制組完畢文檔編制,并且在方略、原則、規(guī)程、資源分派和編制計劃方面予以支持。

(->管理者對文檔工作的責任。管理者要認識到正式或非正式文檔都是重要的,還要認識到文檔工作必須包括文檔計劃、編寫、

修改.形成、分發(fā)和維護等各個方面0

(二)管理者對文檔工作的支持。

(三)管理者的重要里遺:

I、建立編制、登記、出版系統文檔和軟件文檔的多種方略;

2、把文檔計劃作為整個開發(fā)工作的一種構成部分:

3、建立確定文檔質量、測試質量和評審質量的多種措施的規(guī)程:

4、為文檔的各個方面確定和準備多種原則和指南;

5、積極支持文檔工作以形成在開發(fā)二作中自覺編制文檔的團體風氣;

6、不停檢查已建立起來的過程,以保證符合方略和多種規(guī)程并遵守有關原則和指南。

一般?項目管理者在項目開發(fā)前應決定如下事項:

一規(guī)定哪些類型的文檔:一一提供多少種文檔;一一文檔包括的內容:一一到達何種級別的質量水平;——何時產生何種文

檔:一一怎樣保留、維護文檔以及怎樣進行通信。

六、制定文檔編制方略

文檔方略是由上級(資深〉管理者準備并支持下的,對下級開發(fā)單位或開發(fā)人員提供指導。方略規(guī)定重要的方向,不是做什么

或怎年做的詳細闡明。

支持有效文檔方略的基本條件:

(->文檔需要覆蓋整個軟件生存期在項目初期幾種階段就規(guī)定有文檔,并且在貫穿軟件開發(fā)過程中必須是可用的和可維護

的。主開發(fā)完畢后,文檔應滿足軟件的使用、維護、增強、轉換或傳播。

(二)文檔應是可管理的指導和控制文檔的獲得和維護,管理者和發(fā)行專家應準備文檔產品、進度、可靠性、資源,質量保

證和評審規(guī)程的詳細計劃大綱。

(三)文檔應適合于它的讀者針對K一樣的讀者,發(fā)行專家應負責設計不一樣類型的文檔.

(四)文檔效應應貫穿到軟件的整個開發(fā)過程中文檔應指導所有開發(fā)過看。

(五)文檔原則應被標識和使用

(六)應規(guī)定支持工具工具有助于開發(fā)和維護軟件產品,包括文檔。

七、制定文檔編制原則和指南

1、選擇軟件生存期模型

采用嘶種模型都無關緊要,只要階段和對應的文檔是清晰定義的、己計劃的,并且對于任何詳細軟件項目是能遵照的C因此,

管理者應選擇?種軟件生存期模型并保證該模型在他們機構內是合用的。

2、翅定文檔類型和內容

軟件文檔歸入如下三種類別:

I)開發(fā)文檔一一描述開發(fā)過程自身;

2)產品文檔一一描述開發(fā)過程的產物:

3)管理文檔一一記錄項目管理的信息。

1)開發(fā)文檔

開發(fā)文檔是描述軟件開發(fā)過程,包括軟件需求、軟件設計、軟件測試、保證軟件質量的一類文檔,開發(fā)文檔也包括軟件的送細

技術描述(程序邏輯、程序間互相關系、數據格式和存儲等)。

開發(fā)文檔起到如下五種作用:

a)它們是軟件開發(fā)過程中包括的所有階段之間的通信工具,它們記錄生成軟件需求、設計、編碼和測試的詳細規(guī)定和闡明:

b)它們描述開發(fā)小組的職賁。通過規(guī)定軟件、主題事項、文檔編制、質量保證人員以及包括在開發(fā)過程中任何其他事項的角色來

定義也直截了當、怎樣做和何時做;

0它們用作檢查點而容許管理者評估開發(fā)進度。假如開發(fā)文檔丟失、不完整或過時,管理者將失去跟蹤和控制軟件項目的一種重

要工具;

d)它們形成了維護人員所規(guī)定的基本的軟件支持文檔。而這些支持文檔可作為產品文檔的一部分:

c)它們記錄軟件開發(fā)的歷史。

基本的開發(fā)文檔是:

-可行性研究和項口任務書:一一需求規(guī)格闡明:一一功能規(guī)格闡明:一一設計規(guī)格闡明,包括程序和數據規(guī)格闡明:

一一開發(fā)計劃:一一軟件集成和測試計劃;一一質量保證計劃、原則、進度:一一安全和測試信息。

2)產品文檔

產品文檔規(guī)定有關軟件產品的使用、維護、增強、轉換和傳播的信息。

產品的文檔起到如下三種作用:

a)為使用和運行軟件產品的任何人規(guī)定培訓和參照信息:

b)使得那些未參與開發(fā)本軟件的程序員維護它;

c)增進軟件產品的市場流通或提高可接受性。

產品文檔用于卜列類型的讀者:

顧客一一他們運用軟件輸入數據、檢索信息和處理問題;

迄行者一一他們在計算機系統上運行軟件:

維護人員一他們維護、增強或變更軟件。

產品文檔包括如下內容:

一一用于管理者的指南和資料,他們監(jiān)督軟件的使用;

—宣傳資料通告軟件產品的可用性并詳細闡明它的功能、運行環(huán)境等:

一一一般信息對任何有愛好的人描述軟件產品。

基本的產品文檔包括:

一一潛訓手冊:一一參照手冊和顧客指國;一一軟件支持手冊:一一產品手冊和信息廣告。

3)管理文檔

一種文檔建立在項目管理信息的基礎上,諸如:

一一開發(fā)過程的每個階段的進度和進度變更的記業(yè);一一軟件變更狀況的記求;一一相對于開發(fā)的鑒定也b——職責定義。

3、確定文檔的質量等級

質量規(guī)定確實定取決于可得到的資源、項目的大小和風險,可以對該產品的每個文檔的格式及詳細程度作出明確的規(guī)定。

場個文檔的質量必須在文檔計劃期間就有明確的規(guī)定。

文檔的質量可以按文檔的形式和列出的規(guī)定劃分為四級:

最低程度文檔(1級文檔)1級文檔適合開發(fā)工作量低于?種人月的開發(fā)者自用程序。該文檔應包括程序清單、開發(fā)記錄、測

試數據和程序簡介。

內部文檔(2級文檔)2級文檔可用于在精心研究后被認為似乎沒有與其他顧客共享資源的專用程序。除I級丈檔提供的信息

外,2級文檔還包括程序清單內足夠的注釋以協助顧客安裝和使用程序。

工作文檔(3級文檔)3級文檔適合于由同一單位內若干人聯合開發(fā)的程序,或可被其他單位使用的程序。

正式文檔(4級文檔)4級文檔適合那些要正式發(fā)行供普遍使用的軟件產品。關鍵性程序或具有反復管理應用性質(如工資計

算)的程序需要4級文檔。

,貨量方面需要考慮文檔的構造和文檔的內容。文檔內容可以根據對的性、完整性和明確性來判斷。而文檔構造由各個構成部分

的次序和總體安排的簡樸性來測定。

八、文檔編制計劃

文檔計劃可以是整個項目計劃的一部分或是一種獨立的文檔。應當編寫文檔計劃并把它分發(fā)給全體開發(fā)組組員,作為文檔審:要

性的詳細根據和管理部門文檔工作責任的備忘錄。

對于小的、非正式的項目,文檔計劃也許只有一頁紙;對于較大的項目,文檔計劃也許是一種綜合性的正式文檔,這樣的文檔

計劃應遵照各項嚴格的原則及正規(guī)的評審和同意過程。

編制計劃的工作應及早開始,對計劃的評審應貫穿項口的全過程。所有與該計劃有關的人員都應得到文檔計劃。

文檔訃劃一般包括如下幾方面內容:

1)列出應編制文檔的目錄;

2)提醒編制文檔應參照的原則:

3)指定文檔管理員:

4)提供編制文檔所需要的條件,貫徹文檔編寫人員、所需經費以及編制工具等:

5)明保證證文檔質量的措施,為了保證文檔內容的對的性、合理性,應采用一定的措施,如評審、鑒定等等;

6)繪制進度表,以圖表形式列出在軟住生存期各階段應產生的文檔、編制人員、編制日期、完畢日期、評審日期等。

2.2GB"8567-計算機軟件文檔編制規(guī)范

本原則重要對軟件的開發(fā)過程和管理過程應編制的重要文檔及其編制的內容、格式規(guī)定了基本規(guī)定。原則上合用于所有類型的

軟件產品的開發(fā)過程和管理過程。軟件文檔從使用的角度大體可分為顧客文檔和內部文檔(開發(fā)文檔)兩類。

本原則不規(guī)定詳細的布局和字體。本原則也規(guī)定何種信息對文檔管理者是可用的、誰做評審和再生產文檔。

5.2源材料準備

需方應容許文檔管理者訪問如下內容:

a)所有有關的規(guī)格闡明、記錄格式、匯報布局和文檔的準備所需要的任何其他的信息:

c)軟件的分析員和程序員.以及及時和確切地解答由文檔開發(fā)人員提出的問題:

不管文檔管理者與否是軟件的開發(fā)者,需方應提供合用的原則、風格和格式指南和其他有關的材料。文檔管理者成分發(fā)這些材

料至需要它的文檔開發(fā)人員。

球證需方交付給文檔管理者的所有材料,當交付時.,是完整的和對的的且在交付后保持是最新的。

文檔管理者應采用所有有理由的環(huán)節(jié),以保證由需方提供的材料保持在很好的狀態(tài),應保證需方規(guī)定的信息安全并在文檔項目

完畢后,所有材料返回給需方。

5.3文檔計劃

文檔計劃應正式地描述計劃的文檔的范圍和限制,以及重要的文檔分析和設計決定。也應規(guī)定在文檔開發(fā)期間實現的過程和控

蚪文檔計劃應包括(但不限于)如下內容:

a)計劃的文檔的工作名稱、目的、范圍和限制;b)文檔的預定的讀者,和使用的目的;

c)文檔內容的草案表,帶有估計的頁數和其他媒體的等效細節(jié);

d)交付:打印副本數,與否提供電子副本,磁盤和文獻格式(包括軟件版本)和任何處交付:

e)版權的擁有者和任何其他所有權;f)合適處,包括每個文檔的安全或機密級;

g)管理文檔開發(fā)過程的環(huán)節(jié)和控制,包括存儲、檢索、后備、處理和質量保證(若規(guī)定);

h)所用的生產措施、工具和工具版本;i)文檔開發(fā)人員所在的隊伍的構造,可包括隊伍選擇計劃:

。項目依賴;k)所規(guī)定的人時和成本;

D項目資源需求,包括需方提供的信息和其他資源:

m)在軟件開發(fā)期間,軟件變更傳送信息給文檔管理者的措施;p)顯示合適的里程碑的時間表。

5.3.2文檔計劃控制

至正式同意后,文檔管理者應控制文檔計劃和它的公布。文檔管理者應保持一份文檔計劃副本的分發(fā)的清單。若后來文檔計劃

變更了(得到文檔管理者和需方的同意),文檔管理者應保證所有獲得文檔計劃副本的人員得到變更告知。

5.4文檔開發(fā)按文檔計劃規(guī)定進行文檔開發(fā)。一般,在進行文檔開發(fā)前,要規(guī)定文檔的格式(風格)。

5.5評審對于開發(fā)文檔的評審,由供方出織和實行。而同意由開發(fā)組織的上級技術機構實行。更要著重常常性的、非正式的重視

實效的評審。

顧客文檔的評審應由需方實現,包括當需要時與文檔管理者討論。為評審交付的文檔應包括從文檔管理者來的闡明書,闡明評

審的目的和評審員的職責。

5.5.2文檔計劃評審此評審的目的應保證文檔計劃定義的文檔,當完畢時,既滿足開發(fā)過程的需要也滿足鐳方在協議中規(guī)定

的文理目的。需方同意文檔計劃,是同意在計劃中定義的顧客文檔的所有可交付的特性。

5.5.3第一種草案評審文檔的第一種草案的評審目的是核杳文檔的技術對的性和完整性,以保證草案滿足文檔計劃的目的。

標點符號、風格和版面應如在文檔計劃中定義的。

5.5.4第二個草案評審第二個草案應包括在笫一種草案評審中同意的所有變更,且應以盡量能近最終的形式,包括在文檔計

劃中定義的可交付的內容。此評審的目的是核查在第一種草案中的內容已經定的實現。

5.5.5校樣評審校樣應包括在第二個草案評審中同意的所有變更。此評審的目的始核查對第二個草案的評論已對的實現。

6.1軟件生存周期與多種文檔的編制

在軟件的生存周期中,一般地說,應當產生如下某些基本文檔:

a)可行性分析(研究)匯報;b)軟件(或項目)開發(fā)計劃:c)軟件需求規(guī)格闡明:d)接I」需求規(guī)格闡明:e)系統/子系統設計(構造

設計:,闡明:力軟件(構造)設計闡明:g)接口設計闡明:h)數據庫(頂層)設計闡明:D(軟件)顧客手冊:j)操作手冊;k)測試計劃;

1)測式匯報:m)軟件配置管理計劃;n)軟件質量保證計劃;。)開發(fā)進度月報:p)項目開發(fā)總結匯報;q)軟件產品規(guī)格闡明;r)軟件

版本闡明等。

本原則一般不波及整個系統開發(fā)中的文檔編制問題,本原則僅僅是軟件開發(fā)過程中的文檔編制指南。

對于使用文檔的人員而言,他們所關懷的文獻的種類隨他們所承擔的工作而異.

管理人員開發(fā)人員維護人員用戶

可行性分析(研究)匯報可行性分析(研究)匯報軟件需求規(guī)格闡明軟件產品規(guī)格闡明

項目開發(fā)計劃項目開發(fā)計劃接口需求規(guī)格闡明軟件版本闡明

軟件配置管理計劃軟件需求規(guī)格闡明軟件(構造)設計闡明顧客手冊

軟件質量保證計劃接口需求規(guī)格闡明測試匯報操作手冊

開發(fā)進度月報軟件(構造)設計闡明

項目開發(fā)總結匯報接口設計闡明書

數據庫(頂層)設計闡明

測試計劃

測試匯報

軟件生存周期可以提成如下6個階段:

a)在可行性分析(研究)與計劃階段內,要確定該軟件的開發(fā)目的和總的規(guī)定,要進行可行性分析、投資一收於分析、制定開發(fā)

計劃,并完畢可行性分析匯報、開發(fā)計劃等文檔。

b)在露求分析階段內,由系統分析人員對被設計的系統進行系統分析,確定對該軟件的各項功能、性能需求和設計約束,確定

對文酉編制的規(guī)定,作為本階段工作的成果,一般地說軟件需求規(guī)格闡明(也稱為:軟件需求闡明、軟件規(guī)格闡明)、數據規(guī)定闡明

和初步的顧客手冊應當編寫出來。

c)在設計階段內,系統設計人員和程序設計人員應當在反復理解軟件需求的基礎上,提出多種設計.分析每個設計能履行的功

能并逐行互相比較,最終確定一種設計,包括該軟件的構造、模塊(或CSCI)的劃分、功能的分派,以及處理流程。在被設計系統

比較更雜的狀況下,設計階段應分解成概要設計階段和詳細設計階段兩個環(huán)節(jié)。在一般狀況下,應完畢的文檔包括:構造設計闡明、

詳細設計闡明和測試計劃草稿。

d)在實現階段內,要完畢源程序的編碼、編譯(或匯編)和排錯調試得到無語法錯的程序清單,要開始編寫進度日報、周報和月

報(與否要有日報或周報,取決于項目的重要性和規(guī)模),并且要完畢顧客手冊、操作手冊等面向顧客的文檔的編寫工作,還要完畢

測試計劃的編制。

e)在測試階段:該程序將被全面地測試,己編制的文檔將被檢查審閱。一般要完畢測試分析匯報。作為開發(fā)工作的結束,所生

產的程序、文檔以及開發(fā)工作自身將逐項被評價,最終寫出項目開發(fā)總結匯報。在整個開發(fā)過程中(即前五個階段中),開發(fā)集體要

按月編寫開發(fā)進度月報。

E)在運行和維護階段,軟件將在運行使用中不停地被維護,根據新提出的需求進行必要并且也許的擴充和刪改、更新和升級。

2.3GB/T9385-1988計算機軟件需求闡明編制指南

一指南不化1導把軟件需求闡明(SoftwareRequircmcnisSpecifications,如下簡稱SRS)劃提成等級,防止把它定義成更小的需

求子集。它描述「一種SRS所必須的內容和質量。

SRS將完畢下列目的:

a.在軟件產品完畢目的方面為客戶和開發(fā)者之間建立共同協議創(chuàng)立一種基礎、對要實現的軟件功能做全面描述,協助客戶制

斷所規(guī)定的軟件與否符合他們的規(guī)定,或者怎樣修改這種軟件才能適合他們的規(guī)定:

b.提高開發(fā)效率。編制SRS的過程將使客戶在設計開始之前周密地思索所有需求,從而減少事后重新設計、重新編碼和重新

測試的返工活動。在SRS中對多種需求仔細地進行復查,還可以在開發(fā)初期發(fā)現若干遺漏、錯誤的理解和不?致性,以便及時加

以糾正;

c.為成本計價和編制計劃進度提供基礎.SRS提供的對被開發(fā)軟件產品的描述,是計算機軟件產品成本核算的基礎,并且可

認為各方的要價和付費提供根據。SRS對軟件的清晰描述,有助于估計所必須的資源,并用作編制進度的根據:

(1.為確認和驗證提供一種基準.任何組織將更有效地編制他們確實認和驗證計劃。作為開發(fā)協議的一部分,SRS還可以提供

一種可以度量和遵照的基準(然而,反之則不成立,即任一有關軟件的協議都不能作為SRS。由于這種文獻幾乎不包括詳理的需求

闡明?并且一般不完全的);

e.便于移植。有了SRS就便于移值軟件產品,以適應新的顧客或新的機種??蛻粢惨子谝浦财滠浖狡渌块T,而開發(fā)者同

樣也易于把軟件移植到新的客戶;

f.作為不停提高的基礎。由于SRS所討論的是軟件產品,而不是開發(fā)這個產品的設計。因此SRS是軟件產品繼續(xù)提高的基礎。

雖然SRS也也許要變化,不過本來的SRS還是軟件產品改善的可靠基礎。

3定義

客戶(customer)——指個人或單位,他們?yōu)楫a品開發(fā)提供資金,一般(但有時也不必)還提出多種需求。文獻中的客戶和開

發(fā)者也也許是同一種組織的組員。

顧客(user)一一指運行系統或者直接與系統發(fā)生交互作用的個人或集團。顧客和客戶一般不是同某些人。

4編寫SRS的背景信息

4.1SRS的基本規(guī)定

SRS是對要完畢一定功能、性能的軟件產品、程序或一組程序的闡明。對SRS的描述有兩項基本規(guī)定:

a.必須描述一定的功能、性能:

I).必須用確定的措施論述這些功能、性能。

4.2SRS的環(huán)境,SRS要滿足下列規(guī)定:

a.SRS必須對的地定義所有的軟件需求;

b.除了設計上的特殊限制之外,SRS中一般不描述任何設計、驗證或項目管理細節(jié)。

4.3SRS的特點

43.1無歧義性當且僅當它對每一種需求只有一種解釋時,SRS者是無歧義的。需求一股是用自然語言編寫的,使用自然

語言的SRS起草者必須尤其注意消除其需求的歧義性。倡導使用形式化需求間明語言。

4.3.2完整性一一假如一種SRS能滿足下列規(guī)定,則該SRS就是完整的:

a.包括所有故意義的規(guī)定,無論是關系到功能的、性能的、設計約束的,還是關系到屬性或外部接口方面的需求:

b.對所有也許出現的輸入數據的響應予以定義,要對合法和非合法的輸入值的響應做出規(guī)定;

c.要符合SRS規(guī)定。假如個別章節(jié)K合用,則在SRS中耍保留章節(jié)號:

d.填寫SRS中的所有插圖、表、圖示標識和參照,并且定義所有術語和度量單位。

4.3.3可驗證性一一當且僅當SRS中描述的每?種需求都是可以驗證的,該SRS才是可以驗證的:當且僅當在某?性能價格比可取

的有限處理過程,人或機器能通過該過程檢查軟件產品能否滿足需求時,才稱這個需求是可以驗證的。

4.3.4一致性——當且僅當SRS中各個需求的描述是不矛盾時SRS才是一致的。

4.3.5可修改性一一假如種SRS的構造和風格在需求有必要變化時處易于實現的、完整性的、,致的,那么這個SRS就處可以修

改的??尚薷男砸?guī)定SRS具有如卜條件:

a.具有一種有條不紊的易于使用的內容組織,具有目錄表,索引和明確的交叉引用表;

b.沒有冗余。即同?需求不能在SRS中出現多次。

4.3.6可追蹤性一一假如每一種需求的源流是清晰的,在深入產生和變化文獻編制時,可以以便地引證每一種需求,則該SRS就是

可追蹤的。

4.3.7運行和維護階段的可使用性,SRS必須滿足運行和維護階段的需要,包括軟件最終替代。

5軟件需求

SRS中每一?種軟件需求處規(guī)定開發(fā)軟件產品的某些基本功能和性能的一種陳說。

5.1體現軟件需求的措施

欷件需求可以用若干種措施來體現:a.通過輸入、輸出闡明;b,使用代表性的例子;c.用規(guī)范化的模型。

另一種體現需求的措施是模型的方式.這是體現復雜需求的精確和有效措施.至少可以提出三種可供使用的通用模型:數學

型、功能型、計時型。

5.2軟件需求的注釋

有關軟件產品的所有需求,并不是同等重要的。SRS中每一種需求必須法行注釋,以便區(qū)別其重要的程度。

5.2.1穩(wěn)定性.注釋需求的一種措施是使用穩(wěn)定性量綱。當一種需求在軟件預期的生存期間內描述不變化的話,可以認為該需

求是穩(wěn)定的,否則可以認為是易變的。

5.2.2必要性等級,注一的另一種措施是把需求提成必須保證級、期望級和任選級。

5.3在體現需求時碰到的共同弊病

SRS的基本點是它必須闡明III軟件獲得的成果,而不是獲得這些成果的手段.編寫需求的人必須描述的基本問題是:

a.功能-所設計的軟件要做什么:

b.性能--是指軟件功能在執(zhí)行過程中的速度、可使用性、響應時間、多種軟件功能的恢復時間、吞吐能力、料度、頻率等等;

c.強加于實現的設計限制--在效果、實現的語汗、數據庫完整性、資源限制、操作環(huán)境等等方面所規(guī)定的原則:

<1.屬性-可移植性、對的性、可維護性及安全性等方面的考慮原因;

e.外部接口-與人、硬件、其他軟件和其他硬件的互相關系。

編寫需求的人應當防止把設計或項口需求寫入SRS之中,應當對闡明需求設計約束與規(guī)劃設計兩者有清晰的區(qū)別。

53.1在SRS中嵌入了設計

SRS必須描述在什么數據上、為誰完畢什么功能、在什么地方、產生什么成果。SRS應把注意力集中在要完生的服務目的匕

一般不指定如下的設計項目:a.把軟件劃提成若干模塊:h.給每一種模塊分派功能:c.描述模塊間的信息流程或者控制流

程d.選擇數據構造。

5.3.2在SRS中嵌入了某些項目規(guī)定,SRS應當是描寫一種軟件產品,而不是描述生產軟件產品的過程。項目規(guī)定體現客戶

和開發(fā)者之間對于軟件生產方面協議性事宜的理解(因此不應當包括在SRS巾〉例如:a.成本;b.交貨進度:c.報表處理;d.

軟件開發(fā)措施;e.質量保證;f.確認和驗證的原則;g.驗收過程。

項目需求在此外的文獻中描述,在SRS中提供的只是有關軟件產品自身的需求。

第三章管理原則

3.1GB/T12505-1990計算機軟件配置管理計劃規(guī)范

3.7軟件生存周期一一是指從軟件系統設計對軟件系統提出應用需求開始,通過開發(fā),產生出一種滿足需求的計算機軟件系統,

然后投入運行,直至該軟件系統退伍為止。其間經歷系統分析與軟件定義、軟件開發(fā)以及系統的運行與維護等三個階段。其中軟件

開發(fā)階段一般又提成需求分析、概要設計、詳細設計、編內與單元測試、組裝與系統傲試以及安裝與驗收等六個階段。

3.8軟件開發(fā)庫一一是指在軟件生存周期的某一種階段期間,寄存與該階段軟件開發(fā)工作有關的計算機可讀信息和人工可讀信息

的庫.

3.9軟件受控庫一一是指在軟件生存周期的某?種階段結束時,寄存作為階段產品而釋放的、與軟件開發(fā)工作有關的計算機可讀

信息一人丁可讀信息的虛、軟件配置管理就是對軟件受控龐中的各軟件是進行管理.因此軟件受控庫也叫版軟件配置管理庫C

3.10軟件產品庫一一是指在軟件生存周期的組裝勺系統測試階段結束后,寄存最終產品而后交付給顧客運行或在現場安裝的軟件

的庫。

3.11接口控制--是指描述有關由一種或多種部門提供的兩個或兩個以上的配置項接旦的所有功能特性和物理特性的過程。在實

現之前,要保證對這些功能特性和物理特性所提議的修改已通過評審和同意。

3.12功能基線一一是指在系統分析與軟件定義階段結束時,通過正式評審和同意的系統設計規(guī)格闡明書中看待開發(fā)系統的規(guī)格闡

明:或是指通過項目委托單位和項目承接單位雙方簽字同意的協議書或協議中所規(guī)定的看待開發(fā)軟件系統的規(guī)格闡明:或是由下級

申請經上級同意或直接由上級下達的項目任務書中所規(guī)定的看待開發(fā)軟件系統的規(guī)格闡明。功能基線是最初同意的功能配置標識。

3.13指派基線一一是指在軟件需求分析是段結束時,通過正式評審和同意的軟件需求的規(guī)格闡明。指派基線是最初同意的指派配

置標漢。

3.14產品基線一一是指在軟件組裝與系統測試階段結束時,通過正式評審的同意的有關所開發(fā)的軟件產品的所有配置項的規(guī)格闡

明。產品基線是最初同意的產品配置標識。

3.15軟件配置-一是指一種軟件產品在軟件生存周期各個階段所產生的多種形式(機器可讀或人工可讀)和多種版本的文檔、程

序及其數據的集合。該集合中的每?種元素稱為該軟件產品軟件配置中的?種配置項。

3.16林放一是指在軟件生存周期的各個階段結束時,由該階段向卜.階段提交該階段產品的過程。它也指將集成與系統測試階段

結束時所獲得的最終產品向顧客提交的過程。背面這個過程也中做交付(delivery)。

4.軟件配置管理計劃編制大綱

4.1引言

目的,本條必須指明特定的軟件配置.管理計劃的詳細目的,還必須描述該計劃所針對的軟件項目及其所屬的各個子項目的名稱

和用途。

4.2管理,本堂必須描述負責軟件配更管理的機構、任務、職費及其有關的塞口控制。

4.2.1機構,本條必須描述在各階段中負責軟件配置管理的機構。

4.2.2任務,本條必須描述在軟件生存周期各個階段中的配置管理任務以及要進行評審的檢查工作,并指出各個階段的階段產品

應寄存在哪一類軟件庫中(軟件開發(fā)庫、軟件受控庫或軟件產品庫〉。

4.2.3職責,本條必須描述與軟件配置管理有關的各類機構或組員的職責,并指出這些機構或組員互相之間的關系。

4.2.5實現本條應當規(guī)定實現軟件配置管理計劃的重要里程碑。

4.2.6合用的原則、條例和約定,木條必須指明所合用的軟件配置管理原則、條例和約定,并把它們作為本計劃要實現的一部分:

還必須闡明這些原則、條例和約定要實現的程度。

4.3軟件配置管理活動,本章必須描述配置標識、配置控制、配置狀態(tài)記錄與匯報以及配置檢查與評審等到四方而的軟件配置管

理活動的需求。

4.3.1配置標識,本條必須詳細闡明軟件項目的基線。在軟件生存周期中,重要有三種基線,它們是功能基線、指派基線和產品

基線。

4.3.2配置控制,本條必須描述在軟件生存周期中各個階段使用的修改同意權限的級別。必須定義對己經有配置的修改提議進行

處理的措施。

4.3.3配置狀態(tài)的記錄和匯報,本條必須:

A.指明怎樣搜集、驗證、存儲、處理和匯報配置項的狀態(tài)信息:

B.詳細闡明要定期提供的匯報及其分發(fā)措施;

C.假如有動態(tài)查詢,要指出所動態(tài)查詢的能力:

D.假如規(guī)定記錄顧客闡明的特殊狀態(tài)時,要描述其實現手段。

4.3.4配置的檢查和評審,本條必須:

A.定義檢查和評審中軟件配置管理計劃的作用:

B.規(guī)定每次檢查和評審所包括的配置項;

C.指出用于標識和處理在檢查和評審期間所發(fā)現的問題的工作規(guī)程。

4.4工具、技術和措施本章必須指明為支持特定項目的軟件配置管理所使用的軟件工具、技術和措施,指明它們的目的,并在

開發(fā)者所有權的范圍內描述其使用方法。

3.2GB/T16260.信息技術軟件產品評價質量特性及其使用指南

一、質量模型

一部分描述了有關軟件產品質量的兩部分模型:a)內部質量和外部質量b)使用陸量。

噗型的第一部分為內部質量和外部質量,規(guī)定了六個特性,它們可深入細分為子特性。

模型的第一部分規(guī)定了四個使用質量的特性.使用盾量是面向顧客的六個軟件產品質量特性的組合效用.

定義的特性合用于每一類軟件,包括固件中的計算機程序和數據。

這些度量可應用于闡明包括中間產品在內的軟件產品質量需求和設計R的o

.本部分可使軟件產品質量從軟件的獲取、需求、開發(fā)、使用、評價、支持、維護、質量保證和審核有關的不一樣視而來確定和

評價.例如它可以被開發(fā)者、需方、質量保證人員和獨立評價者,尤其是那些對確定和評價軟件產品質量負責的人員所使用。

5質量模型框架

5.1質量途徑

過程軟件產品軟件產品的效用

過程內部外部使用質量

測度測度測度的測度

軟件產品質量可以通過測量內部屬性,也可以通過測量外部屬性,或者通過測量使用質量的屬性來評價,目的就是使產品在指

定的使用周境下具有所需的效用。

過程質量有助于提高產品質量,而產品質量又有助于提高使用質量。評價使用質量可認為改善產品提供反饋,而評價產品則可

認為改善過程提供反饋。

合適的軟件內部屬性是獲得所需外部行為的先決條件,而合適的外部行為則是獲得使用質量的先決條件

軟件產品質量需求一?般要包括對于內部質量、外部質量和使用質量的評估準則,以滿足開發(fā)者、維護者、需方以及最終顧客的

需要。

5.2產品質量和生存周期

為部質量、外部質量和使用質量的觀點在軟件生存周期中是變化的。

外部質量需求從外部視角來規(guī)定規(guī)定的質量級別,包括顧客質量規(guī)定派生的需求(包括使用質量需求)。外部質量需求用作不一

樣開發(fā)階段確實認目的。

內部質量需求從產品的內部視角來規(guī)定規(guī)定的質量級別,內部質量需求用來規(guī)定中間產品的特性。這些可以包括靜態(tài)的和動態(tài)

的模型,其他的文檔和源代碼。內部質量需求可用作不一樣開發(fā)階段確實認目的,也可以用于開發(fā)期間定義開發(fā)方略以及評價和驗

證的準則。

內部質量是基于內部視角的軟件產品特性的總體。內部質量針對內部質量需求被測量和評價。軟件產品質量的枝節(jié)部分可以在

代碼實現、評審和測試期間被改善,不過由內部質量表達的軟件產品質量的基本性質不會變化,除非進行重新設計。

外部質量是基于外部視角的軟件產品特性的總體。即當軟件執(zhí)行時,經典地是在模擬環(huán)境中用模擬數據測試時,使用外部度量

所測顯和評價的質量.

使用質量是基于顧客觀點的軟件產品用于指定的環(huán)境和使用周境時的質量。它測量顧客在特定環(huán)境中能到達其目的的程度,而

不是測量軟件自身的屬性。

5.4質量模型的使用

軟件產品質量宜使用己定義的質的模型來評價。質量模型宜在為軟件產品和中間產品設置質量目的時使用。軟件產品質量應當

按層次分解為一種由特性和了特性所構成的質量模型,該模型可作為與質量有關的問題清單來使用。

對大型軟件產品的所有部分,測量其所有內部和外部子特性分際上是不所許的。為所有也許的顧客-任務方案測量使用質量一

般也是不切實際的,評價資源需要基于業(yè)務目的和產品與設計過程的性質在不一樣類別的測量間進行分派。

6外部和內部質量的質量模型

外部和內部質量的質量模型將軟件質量屆性劃分為六個特性(功能性、可小性、易用性、效率、維護性和可移植性),并深入細

分為若干子特性,這些子特性可用內部或者外部度量來測量。

6.1功能性當軟件在指定條件下使用時,軟件產品提供滿足明確和隱含規(guī)定的功能的能力。(本特性與軟件為滿足規(guī)定要做什么

有關.而其他特性則重要與何時滿足規(guī)定以及怎樣滿足規(guī)定有關〉

適合性一一與規(guī)定任務能否提供一組功能以及這組功能的適合程度有關的軟件屬性

精確性一一與能否得到對的或相符的成果或效果有?關的軟件屬性

互操作性互用性一一與同其他指定系統進行交互的能力有關的軟件屬性

安全性一一與防止對程序及數據的非授權的故意或意外訪問的能力有關的軟件屬性

依從性一一使軟件遵照有關的原則約定法規(guī)及類似規(guī)定的軟件屬性

6.2可靠性在

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論