第一章

1.1什么是計算機軟件？軟件的J特點是什么？

計算機軟件是指計算機系統中的I程序及其文檔

軟件的特點：

?軟件是i種邏輯實體，而不是有形口勺系統元件，其開發成本和進度難以精確地估算。

?軟件是被開發的或被設計的，沒有明顯的制造過程，一旦開發成功，只需復制即可,

但其維護的工作量大。

?軟件時使用沒有硬件那樣的機械磨損和老化問題。

1.2簡述軟件H勺分類，并舉例闡明

1.系統軟件

系統軟件居于計算機系統中最靠近硬件的一層，其他軟件一般都通過系統軟件發揮

作用。例如：編譯軟件、操作系統。

2.支撐軟件

支撐軟件是支撐軟件口勺開發和維護的軟件。例如：數據庫管理系統、網絡軟件、軟

件工具、軟件開發環境。

3.應用軟件

應用軟件是特定應用領域專用日勺軟件。例如：工程/科學計算機軟件、嵌入式軟件、

產品線軟件、Web應用軟件、人工智能軟件。

13簡述軟件語言口勺分類，并舉例闡明。

1.需求定義語言

是用于書寫軟件需求定義的語言。例如：PSL/PSA.

2.功能性語言

是用于書寫軟件功能規約的J語言，一般又稱為功能規約語言。例如：廣譜語言、Z

語言。

3.設計性語言

是用于書寫軟件設計規約的語言。例如：PDLo

4.實現性語言

也稱為程序設計語言，是用于書寫計算機程序的語言。例如：C、java.PROLOG.

FORTRAN、COBOL、Modula。

5.文檔語言

是用于書寫軟件文檔的語言。一般用自然語言或半形式化語言書寫。

1.4什么是軟件工程？

軟件工程是應用計算機科學、數學及管理科學等原理，開發軟件日勺工程。軟件工程借鑒

老式工程日勺原則、措施，以提高質量、減少成本為目的J。

1.5簡述軟件工程II勺基本原則。

軟件工程原則包括圍境工程設計、工程支持和工程管理所提出H勺如下4條基本原則。

1.選用合適的開發模型

必須認識需求定義的易變性，采用合適的開發模型，保證軟件產品滿足顧客的

規定。

2.采用合適的設計措施

合適時設計措施有助于這些特性日勺實現，以到達軟件工程的目日勺。

3.提供高質量的工程支撐

軟件工程項目的I質量與開銷直接取決于對軟件工程所提供的支撐質量和效用。

4.重視軟件工程的管理

僅當軟件過程予以有效管理時，才能實既有效的軟件工程。

1.6軟件工程生存周期分哪幾種階段？分別簡述各個階段的任務。

1.計算機系統工程

計算機系統工程H勺任務是確定待開發軟件的總體規定和范圍，以及該軟件與其

他計算機系統元素之間的關系，進行成本估算，作出進度安排，并進行可行性分析。

2.需求分析

需求分析重要處理待開發軟件要“做什么”的問題，確定軟件的功能、性能、

數據、界面等規定，生成軟件需求規約（也稱軟件需求規格闡明）。

3.設計

系統設計的I任務是設計軟件系統口勺體系構造，詳細設計的任務是設計各個構成

成分的實現細節，包括局部數據構造和算法。

4.編碼

編碼階段日勺任務是用某種程序設計語言，將設計日勺成果轉換為可執行日勺程序代

碼。

5.測試

測試階段口勺任務是發現并糾正軟件中的錯誤和缺陷。

1.7簡述CMM歐J5個等級。

1.初始級

2.可反里級

3.已定義級

4.已管理級

5.優化級

1.8簡述CMMI的持續式模型和階段式模型。

1.階段式模型的構造類同于軟件CMM,它關注組織I勺成熟度，CMMI-SE/SW/IPPD1.1版

中有5個成熟度等級：初始H勺、已管理的、已定義H勺、定量管理H勺、優化的。

2.持續式模型關注每個過程域的能力，CMMI中包括6個過程域能力等級：未完畢的、

己執行日勺、己管理的、己定義的、定量管理小J、優化的J。

1.9簡述各類軟件過程模型的特點。

1.瀑布模型：上一階段的活動完畢并通過評審才能開始下一階段的活動，接受上一階

段活動U勺成果作為本階段活動的輸入，根據上一階段活動的成果實行本階段應完畢的活

動，對本階段的活動進行評審。

2.演化模型：從構造初始歐I原型出發，逐漸將其演化成最終軟件產品的過程。演化模

型尤其合用于對軟件需求缺乏精確認識的狀況。

3.增量模型：將軟件的開發過程分為若干個日程時間交錯U勺線性序列，融合了瀑布模

型的基本成分（反復地應用）和演化模型的迭代特性，尤其合用于需求常常發生變化的

軟件開發。

4.原型模型：開發人員和顧客在“原型”上到達一致，縮短了開發周期，加緊了工程進

度，減少成本。

5.螺旋模型：將原型實現的迭代特性與瀑布模型中控制的和系統化的方面結合起來,

不僅體現了這兩種模型的長處，并且增長了風險分析。

6.噴泉模型：各個階段沒有明顯的界線，開發人員可以同步進行開發，可以提高軟件

項目開發效率，節省開發時間，適應于面向對象的軟件開發過程。

7.基于構件的開發模型：運用預先包裝的構件來構造應用系統。

8.形式化措施模型：易于發現需求的歧義性、不完整性和不?致性，易于對分析模型、

設計模型和程序進行險證。

1.10敏捷軟件開發的特點是什么？

1.個體和交互勝過過程和工具

2.可以工作的軟件勝過面面俱到的I文檔

3.客戶合作勝過協議談判

4.響應變化勝過遵照計劃

1.11簡述敏捷軟件開發的價值觀。

1.個人和交互高于過程和工具

2.可運行軟件高于詳盡口勺文檔

3.與客戶協作富于協議（契約）談判

4.對變更及時作出反應高于遵照計劃

1.12簡述敏捷軟件開發的原則。

1.最優先的是通過盡早地和不停地交有價值的軟件來使客戶滿意。

2.雖然到了開發的后期，也歡迎變化需求。

3.以幾周到幾種月為周期，盡快、不停地公布可運行軟件。

4.在整個項目過程中，業務人員和開發人員必須每天一起工作。

5.以積極向上的員工為中心建立項目組，予以他們所需要的環境和支持，對他們的工作

予以充足的信任。

6.項目組內效率最高、最有效的信息傳遞方式是面對面的交談。

7.測量項目進展的首要根據是可運行的軟件。

8.敏捷過程倡導可持續H勺開發，項目發起者、開發者和顧客應能長期保掙恒定的速度。

9.應時刻關注技術上向精益求精和好的設計，以增強敏捷性。

10.簡樸化是必不可少的，這是盡量減少不必要工作的藝術。

11.最佳的構架、需求和設計出自于自我組織的團體。

12.團體要定期反思怎樣才能更有效，并據此調整自己的行為。

1.13通過本章學習，請對敏捷軟件開發作簡要評價。

（略）

1.14簡述CASE工具和環境H勺重要性。

CASE已被證明可以加緊開發速度，提高應用軟件生產率并保證應用軟件的可靠品

質。計算機專業人員運用計算機使他們U勺企業提面了效率，企業U勺各個部門通過使用計算機

提高了生產率和效率，增強了企業的競爭力并使之帶來了更多的利潤。

第一草

2.1簡述系統工程的任務

1.識別顧客的規定

識別顧客對基于計算機的系統的總體規定，標識系統的功能和性能范圍，確定系統

的功能、性能、約束和接口。

2.系統建模和模擬

?種基于計算機的系統?般可考慮建立如下模型：硬件系統模型、軟件系統模型、

人機接口模型、數據模型。

3.成本估算及進度安排

開發一種基于計算機的系統需要一定的資金投入和時間約束（交互日期），需進行

成本估算，并作出進度安排。

4.可行性分析

重要從經濟、技術、法律等方面分析所給出的處理方案與否可行。

5.生成系統規格闡明

作為后來開發基于計算機的系統的根據。

2.2基于計算機日勺系統由哪些元素構成？

1.軟件

2.硬件

3.人員

4.數據庫

5.文檔

6.規程

2.3簡述可行性分析的任務

1.經濟可行性

a）成本

b）效益

c）貨幣的時間價值

d）投資的回收期

e）純收入

2.技術可行性

a）風險分析

b）資源分析

c）技術分析

3.法律可行性

4.措施的選擇和折變

第三章

3.1需求工程的重要性是什么？

可以確定客戶需求協助分析人員理解問題評估可行性協商合理H勺處理措施無

歧義日勺規約方案、確認規約以及將規約轉換到可運行的系統時日勺管理規定。

3.2需求工程詳細包括哪些環節？每個環節的詳細任務是什么？

1.需求獲取：系統分析人員通過與顧客日勺交流、對既有系統的觀測及對任務進行分析。

2.需求分析與協商：分析每個需求與其他需求的關系以檢查需求的一致性、重疊和遺

漏日勺狀況，并根據顧客的需求對需求進行排序。

3.系統建模：通過合適的工具和符號系統地描述需求。

4.需求規約：給出對目的軟件的多種需求。

5.需求驗證：對功能的對時性、完整性和清晰性以及其他需求予以評價。

6.需求管理：對需求工程所有有關活動H勺規約和控制。

3.3一種系統分析員應當具有哪些思想素質和基木知識？請闡明理由.

1.可以純熟地掌握計算機硬、軟件的專業知識，具有一定H勺系統開發經驗。

2.善于進行抽象口勺思維和發明性日勺思維，善于把握抽象的I概念，并把它們重新整頓成

為多種邏輯成分，并給出簡要、清晰日勺描述。

3.善于從互相沖突或混淆的原始資料中抽出恰當的條目來。

4.善于進行調杳研究，可以很快學習顧客日勺專業領域知識，理解顧客叫I環境條件。

5.可以傾聽他人日勺意見，注意發揮其他人員的作用。

6.具有良好的書面和口頭交流體現能力。

3.4列出在制定需求獲取方略時H勺3種重要考慮原因。

1.功能需求。考慮系統要做什么，在何時做，在何時及怎樣修改或升級。

2.性能需求。考慮軟件開發的技術性指標。

3.顧客或人對原因。考慮顧客的類型。

3.5（略）

3.6（略）

3.7（略）

3.8軟件需求分析的操作性原則和需求工程口勺指導性原則是什么？

需求分析的操作性原則：

?必須可以表達和理解問題的信息域.

?必須可以定義軟件將完畢的功能。

?必須可以表達軟件日勺行為（作為外部事件日勺成果）。

?必須劃分描述數據、功能和行為的模型，從而可以分層次地揭示細節。

?分析過程應當從要素信息轉移向細節信息

需求工程的指導性原則：

?在開始建立分析模型之前應當先理解問題。假如問題沒有很好理解就急于求成，常

常會產生一種處理錯誤問題的完美日勺軟件。

?強力推薦使用原型。這樣做可以使顧客理解將怎樣與計算機交互，而人們對軟件質

吊日勺認識常常是基于對界面“友好性”日勺切身體會。

?記錄每一種需求的來源和原因。這是建立對顧客規定日勺可追溯性的第一步。

?使用多種視圖，建立系統的數據、功能和行為模型。這樣做可辦助分析員從多方面

分析和理解問題，減少遺漏，識別也許口勺不一致之處。

?給需求賦予優先級。由于過短的時限會減少實現所有軟件需求的也許性。因此，對

需求排定一種優先次序，標識哪些需求先實現，哪些需求后實現。

?注意消除歧義性。由于大多數需求都是以自然語言描述，存在論述的歧義性問題

導致遺漏和誤解。采用正式的技術評審是發現和消除歧義性的好措施。

3.9軟件需求規約重:要包括哪些內容？

1.引言

2.信息描述

3.功能描述

4.行為描述

5.檢查原則

6.參照書目

7.附錄

3.10需求驗證應當有哪些人參與？

分析人員、顧客、開發部門的管理者、軟件設計、實現、測試的人員。

第四章

4.1簡述軟件設計階段的基本任務。

1.數據/類設計：將分析類模型變換成類的實現和軟件實現所需要的數據構造。

2.體系構造設計：定義了軟件U勺整體構造，由軟件部件、外部可見的屬性和他僅之間

H勺關系構成。

3.接口設計：描述了軟件內部、軟件和協作系統之間以及軟件同人之間的通信方式。

4.部件級設計：將軟件體系構造的構造性元素變換為對軟件部件的過過程性描述。

4.2軟件設計與軟件質量的關系是怎么樣啊?

設計是在軟件開發中形成質量的階段，設計提供了可以用F質量評估的軟件表達，是將

顧客需求精確地轉化為完整的軟件產品或系統的重要途經。

4.3（略）

4.4簡述模塊、模塊化及模塊化設計的概念。

模塊是數聽闡明、可執行語句等程序對象的集合，是單獨命名的，并且可以通過名

字來訪問時。

模塊化是指把軟件按照規定原則，劃分為一種人較小U勺，互相獨立的但又互相關聯

的部件。

模塊化設計就是程序U勺編寫不是開始就逐條錄入計算機語句和指令,而是首先用主

程序、子程序、子過程等框架把軟件的重要構造和流程描述出來，并定義和調試好各個

框架之間的輸入、輸出鏈接關系。

4.5舉例闡明每種類型的模塊耦合度和每種類型的I模塊內聚度。

a）內容耦合：當一種模塊直接修改或操作另一種模塊的數據，或者直接轉入另一種模

塊時就發生了內容耦合。此時，被修改的1模塊完全依賴于修改它的模塊。假如發生

下列情形，兩個模塊之間就發生了內容耦合：

I.一種模塊直接訪問另一種模塊日勺內部數據

ii.一種模塊不通過正常入口轉到另一模塊內部

Hi.兩個模塊有一部分程序代碼重疊（只也許出目前匯編語言中）

iv.一種模塊有多種入口。

b）公共耦合：若一組模塊都訪問同一種公共數據環境，則它們之間的I耦合就稱為公共

耦合。公共口勺數據環境可以是全局數據構造、共享日勺通信區、內存的公共覆蓋區等。

C）外部耦合：一組模塊都訪問同一全局簡樸變量而不是同一全局數據構造，并且不是

通過參數表傳遞該全局變量日勺信息，則稱之為外部耦合。

d）控制耦合：假如一種模塊通過傳送開關、標志、名字等控制信息，明顯地控制選擇

另一模塊的功能，就是控制耦合。

e）標識耦合：一組模塊通過參數表傳遞記錄信息，就是標識耦合。這個記錄是某一數

據構造H勺子構造，而不是簡樸變量。其實傳遞的是這個數據構造H勺地址。

f）數據耦合：?種模塊訪問另?種模塊時，彼此之間是通過簡樸數據參數（不是控制

參數、公共數據構造或外部變量）來互換輸入、輸出信息的。

g）非直接耦合：兩個模塊之間沒有直接關系，它們之間的聯絡完全是通過主模塊的控

制和調用來實現的

1.巧合內聚：講幾種模塊中沒有明確體現出獨立功能的相似程序代碼段獨立出來建立

的模塊稱巧合內聚模塊。

2.邏輯內聚：邏輯內聚是指完畢一組邏輯有關任務的模塊，調用該模塊時，由傳送給

模塊的控制性參數來確定該模塊應執行哪?種功能。

3.時間內聚：時間內聚是指一種模塊中II勺所有任務必須在同一時間段內執行。

4.過程內聚：過程內聚是指一種模塊完畢多種任務，這些任務必須指定的過程執行。

5.通信內聚：通信內聚是指一種模塊內所有處理元素都集中在某個數據構造的一塊區

域中。

6.次序內聚：次序內聚是指一種模塊完畢多種功能，這些功能又必須次序執行

7.功能內聚：功能內聚是指一種模塊中各個部分都是為完畢一項詳細功能而協同工

作，緊密聯絡不可分割。

4.6耦合和軟件可移植性的概念有何關系？

耦合性是2個或多種模塊有關的程度，可移植性是指軟件從一種平臺/環境轉移到

另一種平臺/環境的難易程度。

4.7描述信息隱蔽概念，并討論信息隱蔽與模塊獨立兩概念之間的關系。

1.信息隱蔽指在設計和確定模塊時，使得一種模塊內包括信息（過程或數據），對于不

需要這些信息口勺其他模塊來說，是不能訪問的。在面向對象措施中，信息隱蔽是通

過對象的封裝性來實現的J。

2.信息隱蔽的概念與模塊的獨立性直接有關

4.8什么是模塊B勺獨立性？設計中為何模塊要獨立？怎樣度量獨立性？模塊功能獨立有何長

處？

1.模塊獨立性：

A.模塊獨立性指每個模塊只完畢系統規定的獨立日勺子功能，并且與其他模塊H勺聯

絡至少且接L1簡樸

B.模塊獨立性是指模塊內部各部分及模塊間的關系日勺一種衡鼠原則，由內聚和耦

合來度量。

2.A.具有獨立日勺模塊的軟件比較輕易開發出來。這是由于可以分割功能并且接口可以

簡化，當許多人分工合作開發同一種軟件時，這個長處尤其重要。

B.獨立的模塊比較輕易測試和維護。這是由于相對說來修改設計和程序需要的工

作量比較小，錯誤傳播范圍小，需要擴充功能時可以“插入”模塊。總之，模塊獨立

是優秀設計日勺關鍵，而設計又是決定軟件質量的關鍵環節。

3.模塊的獨立程度可以由兩個定性原則度量：內聚和耦合。

4.A.具有獨立口勺模塊的軟件比較輕易開發出來。這是由于可以分割功能并且接口可以

簡化，當許多人分工合作開發同一種軟件時，這個長處尤其重要。

B.獨立的模塊比較輕易測試和維護。

4.9軟件設計規約重要包括哪些內容？

1.工作范圍

A.系統目的

B.運行環境

C.重要軟件需求

D.設計約束/限制

2.體系構造設計

A.數據流與控制流復審

B.導出的程序構造

C.功能與程序交叉索引

3.數據設計

A.數據對象與形成日勺數據構造

B.文獻和數據庫構造：i.文獻口勺邏輯構造；ii.文獻邏輯記錄描述；iii.訪問方式

C.全局數據

D.文獻/數據與程序交叉索引

4.接口設計

A.人機界面規格闡明

B.人機界面設計規則

C.外部接【I設計：i.外部數據接口；ii.外部系統或設備接口

D.內部接口設計規則

5.各部件的過程設計

A.處理與算法描述

B.接口描述

C.設計語言（或其他）描述

D.使用的部件

E.內部程序邏輯描述

F.注釋/約束/限制

6.運行設計

A.運行部件組合

B.運行控制

C.運行時間

7.出錯處理設計

A,出錯處理信息

B.出錯處理對策：i.設置后備；ii.性能降級；iii.恢復和再啟動

8.安全保密設計

9.需求/設計交叉索引

10.測試部分

A.測試方針

B.集成方略

C.特殊考慮

11.特殊注解

12.附錄

第五章

5.1簡述數據流圖U勺重要思想，概述使用數據流圖進行需求分析的過程。

數據流圖描述輸入數據流到輸出數據流的變換（即和工），用于對系統的功能建模。

1.畫出系統的輸入和輸出?

A.確定源和宿

B.確定加工

C.確定數據流

D.頂層圖一般沒有文獻

2.畫出系統內部

A.確定加工

B.確定數據流

C.確定文獻

D.確定源和宿

3.畫出加工內部

4.反復第3步，直至每個尚未分解的加工都足夠簡樸（即不必再分解）

5.2分別采用數據流措施中的哪些技術來完畢顧客需求的精確化、一致化和完全化任務？

1.父圖和子圖平衡

2.數據守恒

3.局部文獻

4.一種加工的輸入數據流不能與該加工的輸入數據流同名

5.每個加工至少有一種輸入數據流和一種輸出數據流

6.在整套分層數據流中，每個文獻應至少有一種加工讀該文獻，有另一種加工寫該文

獻。

7.分層數據流圖中得每個數據流和文獻都必須命名（除了流入或流出文獻H勺數據流）,

并且與數據字典一致。

8.分層DFD中的每個基本加工（即不再分解子圖的加工）都應有一種加工規約。

5.3（略）

5.4在數據流圖中，可否將兩個加工用一種數據流相連？可否將兩個源用一種數據流相連？

為何？

兩個加工可以直接用數據流相連，兩個源不能直接月數據流相連。由于數據流由一組固

定成分H勺數據構成。在DFD中，數據流H勺流向可以有如下幾種：從一種加工劉向另一種加

工，從加工流向文獻（寫文獻），從文獻流向加工（讀文獻），從源流向加工，從加工流向宿。

5.5（略）

5.6（略）

5.7（略）

5.8（略）

5.9（略）

第六章（略）

第七章（略）

第八章（略）

第九章（略）

第十章（略）

第十一章

11.1軟件測試的目H勺是什么？

軟件測試的目的是發現軟件中的錯誤和缺陷，并加以糾正。

11.2什么是白盒測試？什么是黑盒測試？

白盒測試乂稱構造測試，這種措施把測試對象看做一種透明H勺盒子，測試人員根據程序

內部的邏輯構造及有關信息設計測試用例，檢查程序中所有邏輯途徑與否都按預定的規定對

的地工作。白盒測試重要用于對?程序模塊日勺測試。包括：

?程序模塊中的所有獨立途徑至少執行一次。

?對所有邏輯鑒定的取值（“真”與“假”）都至少測試一次。

?在上下邊界及可操作范圍內運行所有循環

?測試內部數據構造口勺有效性等

黑盒測試又稱行為測試，這種措施吧測試對象看做i種黑盒子，測試人員完全不考慮程

序內部H勺邏輯構造和內部特性，只根據程序的需求規格闡明書，檢查程序的J功能與否符

和它H勺功能需求。黑盒測試可用于多種測試，它試圖發現如下類型的錯誤：

?不對的或遺漏的功能

?接口錯誤，如輸入輸出參數的個數、類型等

?數據構造錯誤或外部信息（如外部數據庫）訪問錯誤

?性能錯誤

?初始化和終止錯誤

11.3（略）

11.4（略）

11.5分別筒述單元測試、集成測試、確認測試和系統測狀的任務。

1.單元測試：又稱模塊測試，著重對軟件設計的最小單元一一軟件構件或模塊進行驗

證。單元測試根據設計描述，對重要日勺控制途徑進行測試，已發現構建或模塊內部

口勺錯誤，一般采用白盒測試，并且多種構件或模塊可以并行測試。單元測試的重要

內容：接口、局部數據構造、邊界條件、獨立途徑和錯誤處理途徑。

2.集成測試：也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照規定

（如根據構造圖）組裝成為子系統或系統，進行集成測試。使用黑盒測試措施測試

集成的功能，并且對此前的集成進行回歸測試。

3.確認測試:經集成測試后，已經按照設計把所有的模塊組裝成一種完整的軟件系統，

接口錯誤也已經基本排除了，接著就應當深入驗證軟件U勺有效性，這就是確認測試

II勺任務，即軟件的功能和性能如同顧客所合理期待的那樣。

4.系統測試：將已經確認的軟件、計算機硬件、外設、網絡等其他元素結合在一起，

進行信息系統H勺多種組裝測試和確認測試，系統測試是針對整個產品系統進行的測

試，目的是驗證系統與否滿足了需求規格的定義，找出與需求規格不符或與之矛盾

的地方，從而提高愈加完善的方案。

11.6什么是a測試？什么是B測試？

1.a測試時由一種頤客在開發者口勺場所進行日勺測試，軟件在開發者時顧客時，指導下”

進行測試。通過a測試后的軟件成為B版軟件。

2.B測試是指軟件開發企業組織各方面日勺經典顧客在平常工作中實際使用B版本，并

規定顧客匯報異常狀況、提出批評意見，然后軟件開發企業再對B版本進行改錯和

完善。

11.7什么是回歸測試？

回歸測試就是對已經進行過的測試的子集U勺重新執吁，以保證對程序的變化和修改，沒

有傳播非故意的副作用。

11.8簡述邊界值分析措施的作用。

長期日勺測試工作經驗告訴我們，大量的錯誤時發生在輸入或輸出范圍的邊界上，而不是

發生在輸入輸出范圍的內部。因此針對多種邊界狀況設計測試用例，可以查出更多的錯誤。

第十二章（略）

第十三章

13.1請討論時軟件維護成本居高不下的原因。怎樣盡量減少這些原因的影響？

1.

a）軟件的維護周期長；

b）需要維護口勺軟件往往沒有文檔、或文檔資料嚴重局限性、或軟件的變化未在對

應的了文檔中反應出來；

c）維護活動占用了其他軟件開發可用的資源，使資源的運用率減少；

d）某些修復或修改祈求得不到及時安排，使得客戶滿意率下降；

e）維護的成果把某些新的潛在日勺錯誤引入軟件，減少了軟件質量；

f）將軟件人員抽調到維護工作中，使得其他軟件開發過程受到干擾。

2.

a）確定質量管理目H勺和優先級；

b）使用提高軟件質量的技術和工具；

c）選擇可維護性高H勺程序設計語言；

d）完善程序文檔；

e）進行質量保證審查

13.2（略）

13.3軟件維護過程是怎樣進行的？為何要進行軟件可維聲性分析？

1.軟件維護過程包括：建立維護組織；確定維護過程；保管維護記錄；進行維萬評價

等四個階段。

2.可維護性是指理解、改正、調整和改善軟件的難易程度。進行可維護性分析有助于

做出對的的決定，進而采用對應日勺措施應對客戶的需求，對確實不能或者沒有進行

維護的價值的軟件堅決不進行維護，對于可以維護的軟件來說，可維護性分析有助

于我們理解軟件狀況，從而做出對應的維護措施

13.4（略）

13.5（略）

13.6（略）

13.7在重構和正向工程之間存在歐I細微不?樣是什么？

重構是指在統一抽象級別上轉換系統日勺描述形式；正向工程過程應用軟件工程的原

理、概念、技術和措施來重新開發某個既有的應用系統。從概念可以看出，重構是從一

種系統環境轉換到另一種系統環境，而正向工程則是重新開發，從零開始，沒有一定基

礎口勺。

13.8（略）

第十四章

14.1何謂軟件項目管理？軟件項目管理與老式項目管理均不一樣點與相似點？

軟件項目管理R勺對象是軟件工程項目。它所波及的范圍覆蓋了整個軟件工程過程。

為使軟