?中華人民共和國國家標準

G8/T14079—93

軟件維護指南

GUNel5量e.量80『twa『ema5nte量Qnce

1主題內容與適用范圍

本標準描述軟件維護的內容和類型、維護過程及維護的限制和改良.

本標準適用于軟件生存周期的運行和維護階段,主要供軟件治理人員和維護人員使用.

2引用標準

GB8567計算機軟件產品開發文件編制指南

GB/Tl1457軟件工程術語

3術語

本標準使用GB/T11457中的術語及以下術語：

3.1自底向上法

在層次結構的軟件中,一種從最低層成份開始逐級向上擴展,直到最高層成份的開發方

法.

3.2自頂向下法

在層次結構的軟件中,一種從最高層成份開始逐級向下擴展,直到最低層成份的開發方

法.

3.3編譯擴展

一種程序設計語言的特征.這種特征超越了該語言的標準特征,但仍可以為一專門的編

譯程序所接受并加以編譯.

3.4同級評審

一種質量保證方法,由兩個或多個同級程序員互相檢查、評估,以保證被檢查內容正確,

且與軟件的其他局部相一致.

3.5軟件維護治理機構

為評審修改帶來的影響、制訂維護方案、復查修改結果、治理維護工作等而設立的機構.

3.6軟件維護主管

組織、治理和協調維護工作的負責人.

3.7維護治理人員

治理一個或幾個軟件的維護工作的技術人員.

3.8軟件維護人員

具體完成軟件維護的工作人員.

4軟件維護的內容與類型

軟件維護是在軟件產品交付使用之后,為糾正故障,改善性能和其他屬性,或使產品適

應改變了的環境所進行的修改活動.

4.1完善性維護

完善性維護是為擴充功能和改善性能而進行修改和擴充,以滿足用戶變化了的需求.主

要內容包括：

s.為擴充或增強功能而作的修改〔如擴充解題范圍和算法優化〕；

b.為提升性能而作的修改〔如提升精度,節省存儲空間等〕；

c.為便于維護而作的修改〔如增加注釋,改良易讀性〕.

4.2適應性維護

適應性維護是為適應軟件運行環境的變化而作的修改,變化的主要內容包括：

a.影響系統的規定、法律和規那么的變化；

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

c.數據格式或文卷結構的變化；

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

4.3改正性維護

改正性維護是為維持系統操作運行,對在開發過程產生而在測試和驗收時沒有發現的錯誤而進行的改正.所必需改正的錯誤包括：

s.設計錯誤；

b.邏輯錯誤；

c.編碼錯誤；

d.文檔錯誤；

e.數據錯誤.

5軟件維護過程

軟件生存周期中的維護階段通常起始于軟件產品交付給用戶、用戶驗收之時.軟件維護

活動通常可定義成軟件生存周期中前幾個階段的重復.軟件維護與軟件開發有許多相同的活

動,但也有其獨特之處：

a.維護活動限定在已有系統的框架之內完成,維護人員必須在已有的設計和編碼結構

的約束下作出修改,一般系統越舊,軟件維護越困難和越費時.

b.通常軟件維護階段的時間比軟件開發的時間長得多,但一項具體的軟件維護一般比

該軟件的開發時間短得多.

c.軟件開發必須從無到有產生所有測試數據,而軟件維護通常可以便用現有的測試數

據進行回歸測試.有時還要產生新的數據,對軟件修改及修改后的影響進行必要的測試.

完成一項軟件維護的過程是復雜的.下面按順序列出完成一項軟件維護過程的步驟：

a.確定修改類型；

b.確定修改的需要；

c.提出修改請求；

d.需求分析；

e.認可或否決修改請求；

f.安排任務進度；

g.設計；

h.設計評審；

5.編碼修改和排錯；

j.評審編碼修改i

k.測試；

I.更新文檔；

m.標準審計；

n.用戶驗收；

o.安裝后評審修改及其對系統的影響.

其中有幾個步驟會經常發生循環,但并不是每次修改都要執行所有的步驟.

6軟件維護的限制和改良

軟件維護必須有限制地進行,使整個過程中都處于適當的治理和限制之下.除了限制預

算、進度和人員,關鍵在于要由軟件維護主管來負責限制和修改系統.

大量的編碼在開發過程中并非都考慮到了維護.即使原來是良好設計及良好實現的編碼和邏輯,也會因無休止的“決速排錯〞和修補工作受到破壞.所以一個系統不僅在開發時要

考慮到維護,還要在維護時考慮到將來的維護.

6.1軟件維護的限制

軟件系統的可維護性常常隨著時間的推移而降低,這是許多因素綜合的結果.如果沒有

為軟件維護治理制定嚴格的條例,或條例貫徹不力,許多系統都將蛻變到無法繼續維護的地

步.

軟件維護的目標是保持系統功能和及時、滿意地響應用戶的請求.

軟件維護的限制是保持一個有秩序的維護過程,在這個過程中所有的維護請求要正式提

出、評審,給予一個優先級并安排進度.

6.1.1確立軟件維護的策略

軟件維護策略確實定是軟件維護限制的一個關鍵步驟.軟件維護策略應充分地描述軟件

維護組織的責任、權利、職能及操作,它應全面地考慮到軟件系統和它的環境的任何類型變化.該策略應由軟件維護治理機構制定和支持.

軟件維護策略必須具體地闡述修改的需要和理由、修改的責任和步驟.規定限制修改軟

件的過程和步驟,使請求的修改從提議到完成有限制地進行.

為保證維護策略的貫徹執行,需進行評審和審計.

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

a.所有的修改要求應先提出正規的書面請求；

b.評審所有修改請求；

c.分析和評價修改請求的類型和額度；

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

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

影響；

『.應特別強調確定所建議的修改是增強還是降低系統的性能；

g?僅當修改的效益超過其本錢時方可修改.

6.1.3為維護安排進度

a.給每個修改請求分配一個優先級；

b.為每個認可的修改請求安排進度；

c.遵守安排的進度.

6.1.4將代碼修改限制于批準的工作范圍內

軟件維護主管必須監督維護人員的工作,保證只在授權的工作范圍內作修改.為有效實

行監督,必須將所有的維護活動記入文檔,包括修改請求報告和完成修改后的源程序清單,并為系統復原做好安月6.

6.1.5強制實施文檔標準和編碼約定

必須貫徹編碼約定和文檔標準,以對軟件維護人員的所有工作進行經常不斷的強制性評審和檢查.在開始一項新的維護工作之前,應當為更新文檔分配足夠的時間.

6.2軟件維護的改良

可維護性是對軟件進行修改的難易程度.一個系統的可維護性必須放在系統的整個生存

周期中加以考慮.在系統最初的設計和開發階段就應考慮到可維護性.

由于維護階段的處理過程同開發階段相似,因此許多技術和開發工具也可用在維護階段.為提升軟件可維護性,應在系統的整個生存周期中綜合地使用以下技術和原理.

6.2.1編碼指南

編碼指南和標準提供了一種提升系統可維護性的結構和框架,它使得系統以一種共同的、更易理解的方式進行開發和維護.編碼應遵循以下根本原那么.

6.2.1.1單一高級語言

盡可能只用一種符合標準的高級語言.

6.2.1.2編碼約定

維護人員首先必須克服的困難是編碼本身,開發人員和維護人員編寫大量源碼時很少考

慮到以后的維護人員,結果使得源碼的可讀性很差.源碼一定要加注解并用結構化格式編寫.

以下技術可提升程序的可讀性：

n.盡量采用較簡單的方法；

b.代碼的每節開始行使用行首空格把一系列代碼分成段.行首空格和字間的間隔是顯

示附屬關系的兩種方法；

c.用有意義的注釋來適當地為代碼加說明；

d.使用有意義的變量名,以表達此數據項是什么以及為何要使用它；

e.防止使用相似的變量名；

『.在程序的過程/函數之間用參數來傳遞數據；

g?在變量名中使用數字時,應放在末端.用作程序序標簽或標號的數字應按順序給

出；

h.?邏輯上相關的功能應集中安排在同一模塊或模塊集,盡可能使邏輯流向自頂向下；

5.防止使用程序語言版本的非標準特征.

1.1.1.3結構化和模塊化

應采用自頂向下的程序設計方法,使程序的靜態結構與執行時的動態結構相一致.

模塊化是指用一組小的層次結構的單元或例行程序構成程序,其中每個單元或例行程序

集完成特定的單一功能.模塊性不是僅僅將程序分段,模塊的結構必須遵循以下設計原那么：

a.一個模塊應只完成一個主要功能；

b.模塊間的相互作用應最少；

c.一個模塊應只有一個入口和一個出口.

1.1.1.4標準數據定義

一定要為系統制定一組數據定義的標準.這些數據定義可聚集于數據字典.字典項定義

了系統中使用的每個數據元素名字、屬性、用途和內容.這些名字要盡可能具有描述性和意

義.正確一致地定義數據標準,就會大大簡化閱讀和理解各模塊,并保證各模塊問的正確通

信.

1.1.1.5良好注釋的代碼

好的注釋可增強源碼的可理解性.除了提升程序可讀性,注釋還有兩個重要用途,即提

供程序的用途和歷史信息、它的起源〔作者、生成和修改日期卜子程序名和個數以及輸入/輸出需求和格式,其次也提供操作限制信息、指示和建議來幫助維護人員理解代碼中不清楚的局部.

1.1.1.6編譯程序擴展

使用編譯程序的非標準特征會嚴重影響系統的可維護性.如果編譯程序更改了,或如果

系統必須移至新機器,那么以前的編譯程序擴展很可能與新的編譯程序相沖突.因此最好限制

語言的擴展和保存語言根本特征的一致.如果需要使用編譯程序擴展,應編制良好文檔加以

說明.

6.2.2文檔編寫指南

一個系統的文檔是良好維護的根底,文檔編寫工作應貫穿系統的整個生存周期.應有計

劃地建立和及時地更新文檔,使維護人員能很快地找到所需的信息.應參照GB8567編制

文檔.

文檔合格的關鍵不僅是將必需的信息記錄下來,以保持文檔的及時更新和一致；而且必

須使維護人員能迅速地獲得它.對于維護人員來說,具有受控的存取和修改水平的聯機文檔

是文檔的最正確形式,如果不能提供聯機文檔,應保證有一機制使維護人員在任何時候能取用

硬拷貝的文檔.

6.2.3編碼和評審技術

本條列出有助于提升軟件可維護性的設計和評審技術.

6.2.3.1自頂向下/自底向上法

應將自頂向下與自底向上的方法組合起來使用.

6.2.3.2同級評審

同級評審是一種質量保證方法.參加評審人員務必明白他們不是要評價其他程序員的能

力或表現,而是分析和評價編碼.評審內容應包括可維護性.

6.2.3.3審查

審查是一種質量評估技術,在軟件生存周期中檢查各階段工作,然后產生一個報告指出

發現的錯誤和提出錯誤改正要求.

6.2.3.4走查

復雜的走查方式可以有

簡單的走查方式是讓兩個維護人員一起討論正在進行的工作,

份日程表、報告書和一位記錄秘書.不管何種方式,目標是通過公開直接的交流,提煉好的

主意,修改原來的方案.

6.2.4測試標準和過程

測試是軟件維護的關鍵局部,因此測試過程必須強調一致性,并以合理的原那么為根底,

測試方案要定義預期的輸入,測試有效的、無效的、預期的和出乎意料的情況.測試要檢查

程序是否執行預期任務,測試的目的是發現錯誤,而不是證實錯誤不存在.

只要有可能,測試過程和測試數據均需由其他人完成,而不是由做系統實際維護的人來

完成.

6.3軟件維護人員的治理

治理是改良軟件維護過程的主要因素之一.治理必須指導怎樣維護軟件,行使對整個過

程的限制,并保證使用高效的軟件維護技術和工具.

為保證實現成功的維護,在維護過程中要有效使用良好的治理技術和方法,必須建立軟

件維護組織機構.

軟件維護機構由維護主管、維護治理機構、維護治理員和維護人員組成.

軟件維護機構的主要任務是審批維護請求,制訂并實施維護策略,限制和治理維護過程,

負責軟件維護的審查,組織評審和驗收,保證軟件維護任務的完成.

軟件維護人員的素質對于有效地進行維護是十分重要的,因此應為維護工程選擇合格的

各級人員.

下面列出挑選軟件維護人員和進行維護治理的要點：

a.維護與開發同等重要,同樣具有難度；

b.維護人員應是合格的、有責任心的人；

c.維護不能當作初級人員“放任自流〞式的培訓；

d.全體人員應輪流分配去做維護和開發工作；

e.出色的維護工作應同出色的開發工作一樣受到獎勵；

『.必須強調對維護人員進行良好的培訓；

g?輪換分配,不應讓一個系統或一個系統的主要局部成為某個人的專有領地.

7軟件維護與軟件宣新設計

維護是一種不斷進行的過程,但有時也應考慮是否要重新設計一個軟件系統.當一個軟

件已變得易出過失、效率降低和消耗增大,再對其繼續維護的本錢/效益比可能會超出重新設計一個系統時,應考慮是否要重新設計一個軟件系統.以下特征可幫助治理人員決定是否

應重建軟件.

7.1軟件經常出錯與性能惡化

代碼越久,那么經常的更新、新的需求和功能增強就越會引起系統的故障和性能惡化.

7.2程序結構和邏輯流過分復雜

具有局部或全部以下屬性的軟件通常很難維護,需重新設計：

a.過多使用DO循環；

b.過多使用IF語句；

c.使用不必'要的GOTO語句；

d.過多使用嵌入的常數和文字；

eo使用不必要的全程變量；

『.使用自我修改的代碼；

g?使用多入口或多出口的模塊；

h.使用相互作用過多的模塊；

5.使用執行同樣或相似功能的模塊.

7.3過時的代碼

過時的代碼嚴重影響新系統的性能發揮.

7.4在仿真方式下運行

采用仿真方法,常阻止系統發揮全部水平和所有功能.仿真系統往往介于功能上尚可實

用,但效率較低這二者之間.

7.5模塊或單個子程序非常大

此時,大模塊結構應重新構造,分成較小的、功能上相關的局部,這可增強系統的可維

護性.

7.6過多的資源需求

需要過多資源的系統會成為用戶的沉重負擔,因此需考慮是增加更多的計算機設備還是

重新設計和實現該系統.

7.7將易變的參數編在代碼中

盡可能對程序進行更新,以使它們能從輸入模塊或一個數據表中讀入參數.

7.8難于擁有維護人員

用低級語言編寫的程序,尤其是匯編,需大量的時間和人力去維護.一般這類語言不為

人們廣泛了解,因此要尋找了解這類語言的維護人員日益困難.

7.9文檔嚴重不全或失真

文檔不全、過時或失真,將造成維護工作極其困難.

7軟件維護與軟件宣新設計

維護是一種不斷進行的過程,但有時也應考慮是否要重新設計一個軟件系統.當一個軟

件已變得易出過失、效率降低和消耗增大,再對其繼續維護的本錢/效益比可能會超出重新設計一個系統時,應考慮是否要重新設計一個軟件系統.以下特征可幫助治理人員決定是否

應重建軟件.

7.1軟件經常出錯與性能惡化

代碼越久,那么經常的更新、新的需求和功能增強就越會引起系統的故障和性能惡化.

7.2程序結構和邏輯流過分復雜

具有局部或全部以下屬性的軟件通常很難維護,需重新設計：

a.過多使用DO循環；

b.過多使用IF語句；

c.使用不必'要的GOTO語句；

d.過多使用嵌入的常數和文字；

eo使用不必要的全程變量；

『.使用自我修改的代碼；

g?使用多入口或多出口的模塊；

h.使用相互作用過多的模塊；

5.使用執行同樣或相似功能的模塊.

7.3過時的代碼

過時的代碼嚴重影響新系統的性能發揮.

7.4在仿真方式下運行

采用仿真方法,常阻止系統發揮全部水平和所有功能.仿真系統往往介于功能上尚可實

用,但效率較低這二者之間.

7.5模塊或單個子程序非常大

此時,大模塊結構應重新構造,分成較小的、功能上相關的局部,這可增強系統的可維

護性.

7.6過多的資源需求

需要過多資源的系統會成為用戶的沉重負擔,因此需考慮是增加更多的計算機設備還是

重新設計和實現該系統.

7.7將易變的參數編在代碼中

盡可能對程序進行更新,以使它們能從輸入模塊或一個數據表中讀入參數.

7.8難于擁有維護人員

用低級語言編寫的程序,尤其是匯編,需大量的時間和人力去維護.一般這類語言不為

人們廣泛了解,因此要尋找了解這類語言的維護人員日益困難.

7.9文檔嚴重不全或失真

文檔不全、過時或失真,將造成維護工作極其困難.

下午13:00—17:00

B.實行不定時工作制的員工,在保證完成甲方工作任務情況下,經公司同意,可自行安排工作和休息時間.

3.1.2打卡制度.

3.1.2.1公司實行上、下班指紋錄入打卡制度.全體員工都必須自覺遵守工作時間,實行不定時工作制的員工不必打卡.

3.1.2.2打卡次數：一日兩次,即早上上班打卡一次,下午下班打卡一次.

3.1.2.3打卡時間：打卡時間為上班到崗時間和下班離崗時間；

3.1.2.4因公外出不能打卡：因公外出不能打卡應填寫?外勤登記表?,注明外出日期、事由、外勤起止時間.因公外出需事先申請,如因特殊情況不能事先申請,應在事畢到崗當日完成申請、

審批手續,否那么按曠工處理.因停電、卡鐘〔工卡〕故障未打卡的員工,上班前、下班后要及時到部門考勤員處填寫?未打卡補簽申請表?,由直接主管簽字證實當日的出勤狀況,報部門經理、

人力資源部批準后,月底由部門考勤員據此上報考勤.上述情況考勤由各部門或分公司和工程文員協助人力資源部進行治理.

3.1.2.5手工考勤制度

,可由各部門提出人員名單,經主管副總批準后,報人力資源部審批備案.

3.1.2.6手工考勤制申請：由于工作性質,員工無法正常打卡〔如外圍人員、出差〕

3.1.2.7參與手工考勤的員工,需由其主管部門的部門考勤員〔文員〕或部門指定人員進行考勤治理,并于每月26日前向人力資源部遞交考勤報表.

3.1.2.8參與手工考勤的員工如有請假情況發生,應遵守相關請、休假制度,如實填報相關表單.

3.1.2.9外派員工在外派工作期間的考勤,需在外派公司打卡記錄；如遇中途出差,持出差證實,出差期間的考勤在出差地所在公司打卡記錄；

3.2加班治理

3.2.1定義

加班是指員工在節假日或公司規定的休息日仍照常工作的情況.

A.現場治理人員和勞務人員的加班應嚴格限制,各部門應按月工時標準,合理安排工作班次.部門經理要嚴格審批員工排班表,保證員工有效工時到達要求.但凡到達月工時標準的,應扣減

員工本人的存休或工資；對超出月工時標準的,應說明理由,報主管副總和人力資源部審批.

B.因員工月薪工資中的補貼已包括延時工作補貼,所以延時工作在4b時〔不含〕以下的,不再另計加班工資.因工作需要,一般員工延時工作4小時至8小時可申報加班半天,超過8小

時可申報加班1天.對主管〔含〕以上治理人員,一般情況下延時工作不計加班,因特殊情況經總經理以上領導批準的延時工作,可按以上標準計加班.

3.2.2.2員工加班應提前申請,事先填寫?加班申請表?,因無法確定加班工時的,應在本次加班完成后3個工作日內補填?加班申請表?.?加班申請表?經部門經理同意,主管副總經理審核

報總經理批準后有效.?加班申請表?必須事前當月內上報有效,如遇特殊情況,也必須在一周內上報至總經理批準.如未履行上述程序,視為乙方自愿加班.

3.2.2.3員工加班,也應按規定打卡,沒有打卡記錄的加班,公司不予成認；有打卡記錄但無公司總經理批準的加班,公司不予成認加班.

3.2.2.4原那么上,參加公司組織的各種培訓、集體活動不計加班.

3.2.2.5加班工資的補償：員工在排班休息日的加班,可以以倒休形式安排補休.原那么上,員工加班以倒休形式補休的,公司將根據工作需要統一安排在春節前后補休.加班可按1:1的比例沖

抵病、事假.

3.2.3加班的申請、審批、確認流程

3.2.3.1?加班申請表?在各部門文員處領取,加班統計周期為上月26日至本月25日.

3.2.3.2員工加班也要按規定打卡,沒有打卡記錄的加班,公司不予成認.各部門的考勤員〔文員〕負責?加班申請表?的保管及加班申報.員工加班應提前申請,事先填寫?加班申請表?加班

前到部門考勤員〔文員〕處領取?加班申請表?,?加班申請表?經工程治理中央或部門經理同意,主管副總審核,總經理簽字批準后有效.填寫并履行完審批手續后交由部門考勤員〔文員〕保

管.

27日匯總交人力資源部,逾期未交的加班記錄公司不予成認.

3.2.3.3部門考勤員〔文員〕負責檢查、復核確認考勤記錄的真實有效性