9003軟件工程_期末_李振宏老師 50124整體設計 50124整體設計 5011軟件工程_軟件工程學概述 5011軟件工程_軟件工程學概述 詳見50125詳細設計 詳見50125詳細設計 詳見50

五、結構化程序設計方法的發展過程。

• 經典的結構程序設計：只容許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環這3種基本控制結構；

• 擴展的結構程序設計：除了上述3種基本控制結構以外，還容許使用DO-CASE型多分支結構和DO-UNTIL型循環結構；

• 修正的結構程序設計：除上述結構之外，還容許使用LEAVE(或BREAK)結構。

六、流程圖與N_S圖如何使用。###

七、可行性研究應該從哪幾個方面進行。

詳見50122可行性研究

探索若干種可供選擇的主要解法(即系統實現方案)。從下述三方面研究每種解法的可行性：

(1) 技術可行性，使用現有的技術能實現這個系統嗎?

(2) 經濟可行性，這個系統的經濟效益能超過它的開發成本嗎?

(3) 操做可行性，系統的操做方式在這個用戶組織內行得通嗎?

八、數據流圖的基本符號有哪幾種？

詳見50122可行性研究

如圖2.4(a)（見書31頁）所示，數據流圖有四種基本符號：正方形(或立方體)表示數據的源點或終點；圓角矩形(或圓形)表明變換數據的處理；開口矩形(或兩條平行橫線)表明數據存儲；箭頭表示數據流，即特定數據的流動方向。

注意，數據流與程序流程圖(參看本書第5章)中用箭頭表示的控制流有本質不一樣，千萬不要混淆。

在數據流圖中應該描繪全部可能的數據流向，而不該該描繪出現某個數據流的條件（沒法表示分支條件或循環）。

處理並不必定是一個程序。一個處理框能夠表明一系列程序、單個程序或者程序的一個模塊；它甚至能夠表明用穿孔機穿孔或目視檢查數據正確性等人工處理過程。

一個數據存儲也並不等同於一個文件，它能夠表示一個文件、文件的一部分、數據庫的元素或記錄的一部分等；數據能夠存儲在磁盤、磁帶、磁鼓、主存、微縮膠片、穿孔卡片及其餘任何介質上(包括人腦)。

數據存儲和數據流都是數據，僅僅所處的狀態不一樣。數據存儲是處於靜止狀態的數據，數據流是處於運動中的數據。

一般在數據流圖中忽略出錯處理，也不包括諸如打開或關閉文件之類的內務處理。

數據流圖的基本要點是描繪「作什麼」而不考慮「怎樣作」。

有時數據的源點和終點相同，若是隻用一個符號表明數據的源點和終點，則至少將有兩個箭頭和這個符號相連(一個進一個出)，可能其中一條箭頭線至關長，這將下降數據流圖的清晰度。另外一種表示方法是再重複畫一個一樣的符號(正方形或立方體)表示數據的終點。

有時數據存儲也須要重複，以增長數據流圖的清晰程度。爲了不可能引發的誤解，若是表明同一個事物的一樣符號在圖中出如今n個地方，則在這個符號的一個角上畫（n-1）條短斜線作標記。

除了上述4種基本符號以外，有時也使用幾種附加符號。圖2.4(b)給出了這些附加符號的含義。

九、面向數據流的設計方法如何進行？

詳見50122可行性研究 2.4.2 例子

十、Jackson方法有何特色？

分析輸入輸出數據的邏輯結構，列出全部操做和條件，用僞代碼表示程序

Jackson結構程序設計方法基本上由下述5個步驟組成。
(1) 分析並肯定輸入數據和輸出數據的邏輯結構，並用Jackson圖描繪這些數據結構。
(2) 找出輸入數據結構和輸出數據結構中有對應關係的數據單元。

(3) 用下述3條規則從描繪數據結構的Jackson圖導出描繪程序結構的Jackson圖。
　　① 爲每對有對應關係的數據單元，按照它們在數據結構圖中的層次在程序結構圖的相應層次畫一個處理框
　　② 根據輸入數據結構中剩餘的每一個數據單元所處的層次，在程序結構圖的相應層次分別爲它們畫上對應的處理框。
　　③ 根據輸出數據結構中剩餘的每一個數據單元所處的層次，在程序結構圖的相應層次分別爲它們畫上對應的處理框。

(4) 列出全部操做和條件(包括分支條件和循環結束條件)，而且把它們分配到程序結構圖的適當位置。
(5) 用僞碼錶示程序。
Jackson方法中使用的僞碼和Jackson圖是徹底對應的，下面是和3種基本結構對應的僞碼。

十一、白盒測試與黑盒測試各有何特色？

白盒測試技術：用白盒方法測試軟件時設計測試數據的典型技術。

黑盒測試技術：用黑盒方法測試軟件時設計測試數據的典型技術。

白盒測試

設計測試方案是測試階段的關鍵技術問題。

測試方案：

•包括測試目的（預約要測試的具體功能），

•應該輸入的測試數據和預期的結果。

測試用例：

•由測試輸入數據及與之對應的輸出結果組成。

•測試用例設計的好壞直接決定了測試的效果和結果。所以在軟件測試活動中最關鍵的步驟就是設計有效的測試用例。（由於不可能進行窮盡的測試）

•測試用例能夠針對黑盒測試設計用例，也能夠針對白盒測試設計用例。

主要用於軟件驗證。

用程序設計的控制結構導出測試用例。

黑盒測試

黑盒測試着重測試軟件功能。

• 黑盒測試不能取代白盒測試，是與白盒測試互補的測試方法，用於發現白盒測試不易發現的錯誤。

• 黑盒測試發現的錯誤類型：

　　①功能不正確或遺漏了功能；

　　②界面錯誤；

　　③數據結構錯誤或外部數據庫訪問錯誤；

　　 ④性能錯誤；

　　⑤初始化和終止錯誤。

白盒測試主要用於測試過程的早期，

黑盒測試主要用於測試過程的後期。

黑盒測試也稱爲功能測試,它着眼於程序的外部特徵,而不考慮程序的內部邏輯結構。測試者把被測程序當作一個黑盒,不用關心程序的內部結構。黑盒測試是在程序接口處進行測試，它只檢查程序功能是否能按照規格說明書的規定正常使用，程序是否能適當地接收輸入數據產生正確的輸出信息，而且保持外部信息(如數據庫或文件)的完整性。黑盒測試主要採用的技術有:等價分類法、邊界值分析法、錯誤推測法和因果圖等技術。

白盒測試是測試者瞭解被測程序的內部結構和處理過程,對程序的全部邏輯路徑進行測試,在不一樣點檢查程序狀態,肯定實際狀態與預期狀態是否一致。白盒測試主要採用的技術有：路徑測試技術和事務處理流程技術，對包含有大量邏輯判斷或條件組合的程序採用基於邏輯的測試技術。

白盒測試：按照程序內部的邏輯測試程序，檢測程序中的主要執行通路是否都能按預約要求正確工做
黑盒測試：在程序接口進行的測試，只檢查程序功能是否能按照規格說明書的規定正常使用，程序是否能適當地接收輸入數據併產生正確的輸出信息，程序運行過程當中可否保持外部信息的完整性。
白盒測試的方法：邏輯覆蓋、控制結構測試
黑盒測試的方法：等價劃分、邊界值分析、錯誤推測

十二、整體設計有何特色？

詳見50124整體設計

整體設計任務

• 系統方案設計

劃分出組成系統的物理元素——程序、文件、數據庫、人工過程和文檔等等，可是每一個物理元素仍然處於黑盒子級。

• 體系結構設計

設計軟件的結構，肯定系統中每一個程序是由哪些模塊組成的，以及這些模塊相互間的關係。

1三、模塊的做用域與控制域

詳見50124整體設計

模塊的做用域應該在控制域以內

• 模塊的做用域：受該模塊內一個斷定影響的全部模塊的集合。

• 模塊的控制域：模塊自己以及全部直接或間接從屬於它的模塊的集合。

例如，在圖5.2中模塊A的控制域是A、B、C、D、E、F等模塊的集合。

模塊A的控制域必定是其下模塊BCDEF，做用域可能糾纏到G，固然這樣是不合適的

受斷定影響的模塊應在作出斷定的那個模塊的控制域以內。

圖5.2 模塊的做用域和控制域

1四、模塊的扇入、扇出、模塊圖的深度、寬度？

詳見50124整體設計

深度、寬度、扇出和扇入都應適當

• 深度：表示軟件結構中控制的層數。

能粗略地標誌一個系統的大小和複雜程度。若是層數過多，應考慮管理模塊是否過度簡單，可否適當合併。

• 寬度：軟件結構內同一個層次上的模塊總數的最大值。

寬度越大系統越複雜。對寬度影響最大的因素是模塊的扇出。

• 扇出：是一個模塊直接控制(調用)的模塊數目。

扇出過大意味着模塊過度複雜，須要控制和協調的下級模塊過多；扇出太小(例如老是1)也很差。

一般是3或4(上限是5～9)。

扇出太大：缺少中間層次，應適當增長中間層次的控制模塊。

扇出過小：把下級模塊進一步分解成若干個子功能模塊，或者合併到它的上級模塊中去。

分解或合併模塊應符合問題結構，不能違背模塊獨立原理。

• 扇入：代表有多少個上級模塊。扇入越大則共享該模塊的上級模塊數目越多，這是有好處的。

好的軟件結構一般頂層扇出比較高，中層扇出較少，底層模塊有高扇入。

系統的模塊結構呈現爲「葫蘆形」。

1五、PAD圖如何使用

PAD是問題分析圖(problem analysis diagram) 。

它用二維樹形結構的圖來表示程序的控制流。

圖6.5給出PAD圖的基本符號。

圖6.5 PAD圖的基本符號

PAD圖的主要優勢以下：

(1) 使用PAD符號設計的程序必然是結構化程序。(2) PAD圖所描繪的程序結構十分清晰。

最左面的豎線是程序的主線，即第一層結構。

隨着程序層次的增長，PAD圖逐漸向右延伸。

每增長一個層次，圖形向右擴展一條豎線。圖中豎線的總條數就是程序的層次數。

(3) PAD圖表現的程序邏輯，易讀、易懂、易記。

程序從圖中最左豎線上端的結點開始執行，自上而下，從左向右順序執行，遍歷全部結點。

(4) 容易將PAD圖轉換成高級語言源程序，這種轉換可用軟件工具自動完成。

(5) 便可表示程序邏輯，也可描繪數據結構。

(6) 支持自頂向下、逐步求精方法的使用。

開始時能夠定義一個抽象的程序，隨着設計的深刻，使用def符號逐步增長細節，直至完成詳細設計，如圖6.6所示。

圖6.6 使用PAD圖提供的定義功能來逐步求精的例子

示例

1六、軟件的可靠性如何定義

軟件可靠性：是程序在給定的時間間隔內，按照規格說明書的規定成功地運行的機率。

隨着運行時間的增長，運行時出現程序故障的機率也將增長，可靠性隨着給定的時間間隔的加大而減小。

按照IEEE的規定

錯誤：是由開發人員形成的軟件差錯（bug）。

故障：是由錯誤引發的軟件的不正確行爲。

1七、程序設計語言有哪三種類型，各有何特色？

機器語言：由「0」和「1」組成的指令序列交由計算機執行的語言，可直接被計算機執行

彙編語言：彙編語言編碼須要把軟件設計翻譯成機器操做的序列

高級語言：與具體計算機無關，不針對具體計算機系統。高級語言程序能夠在多種計算機上編譯後執行，能夠直接、有效地控制計算機硬件，易於產生速度快、容量小的高效率目標程序，高級語言寫程序比用匯編語言寫程序生產率能夠提升好幾倍

1八、軟件調試方法有哪些？

調試的目標：是尋找軟件錯誤的緣由並改正錯誤。通常說來，有下列途徑能夠採用：

•試探法

•回溯法

•對分查找法

•概括法

•演繹法

1.試探法

分析錯誤徵兆，猜想發生錯誤的大概位置，而後利用有關的調試技術進一步得到錯誤信息。這種策略每每是緩慢而低效的。

2. 回溯法

•首先檢查錯誤徵兆，肯定最早發現錯誤的位置，而後人工沿程序的控制流往回追蹤源程序代碼，直到找出錯誤根源或肯定故障範圍爲止。

•回溯法對於小程序而言是一種比較好的調試策略。可是對於大程序，其回溯的路徑數目會變得很大，以致使完全回溯成爲不可能。

•回溯法的另外一種形式是正向追蹤，即便用插入打印語句的方法檢查一系列中間結果，以肯定最早出現錯誤的地方。

3.對分查找法

在程序的中點附近輸入某些變量的正確值(如利用賦值語句或輸入語句)，而後觀察程序的輸出。若輸出結果正確，則說明錯誤出如今程序的前半部分；不然，說明程序的後半部分有錯。對於程序中有錯的那部分再重複使用這個方法，直到把錯誤範圍縮小到容易診斷的程度爲止。

4.概括法

概括法：是從個別推斷全體，即從線索(錯誤徵兆)出發，經過分析這些線索之間的關係而找出故障。這種方法主要有如下四個步驟：

①收集已有的使程序出錯與不出錯的全部數據。

②整理這些數據，以便發現規律或矛盾。

③提出關於故障的若干假設。

④證實假設的合理性，根據假設排除故障

5.演繹法

•演繹法是從通常原理或前提出發，通過刪除和精化的過程，最後推導出結論。

•用演繹法排錯時，首先要列出全部可能形成出錯的緣由和假設，而後逐個排除，最後證實剩下的緣由確實是錯誤的根源。演繹法排錯主要有如下四個步驟：

①設想全部可能產生錯誤的緣由。

②利用已有的數據排除不正確的假設。

③精化剩下的假設。

④證實假設的合理性，根據假設排除故障。

1九、白盒測試與黑盒測試各有哪些方法？

白盒測試的主要方法

• 邏輯驅動測試（邏輯覆蓋）

• 基本路徑測試

黑盒測試技術：

•等價劃分

•邊界值分析

20、面向對象的軟件開發中，多態性、繼承性如何理解？

多態性
在面向對象的軟件技術中，多態性是指子類對象能夠像父類對象那樣使用，一樣的消息既能夠發送給父類對象也能夠發送給子類對象。即，在類等級的不一樣層次中能夠共享(公用)一個行爲(方法)的名字，然而不一樣層次中的每一個類卻各自按本身的須要來實現這個行爲。
多態性機制不只增長了面向對象軟件系統的靈活性，進一步減小了信息冗餘，並且顯著提升了軟件的可重用性和可擴充性。

繼承性

簡單來講就是使子類的對象擁有父類的所有屬性和行爲，同時能夠增添本身的所特有的屬性和行爲。這樣能夠節省寫共同具備的屬性和方法代碼的時間，有利於代碼的複用，這就是繼承的基本思想。軟件的代碼使用繼承思想能夠縮短軟件開發的時間，複用那些已經定義好的類能夠提升系統和軟件的性能，減小系統和軟件在使用過程當中出現錯誤的概率。一個類能夠是其餘類的父類，爲其餘類提供屬性和行爲，也能夠是其餘類的子類，繼承父類的屬性和方法，子類的實例都是父類的實例，但不能說父類的實例是子類的實例。

2一、什麼是軟件危機？

軟件危機：是指在計算機軟件的開發和維護過程當中所遇到的一系列嚴重問題。
這些問題毫不僅僅是不能正常運行的軟件才具備的，實際上，幾乎全部軟件都不一樣程度地存在這些問題。

2二、軟件工程方法學的三要素及分類？

軟件工程方法學包含3個要素：
方法、工具和過程。
方法：是完成軟件開發的各項任務的技術方法，回答「怎樣作」的問題；
工具：是爲運用方法而提供的自動的或半自動的軟件工程支撐環境；
過程：是爲了得到高質量的軟件所須要完成的一系列任務的框架，它規定了完成各項任務的工做步驟。

目前使用得最普遍的軟件工程方法學，分別是傳統方法學和麪向對象方法學。

1. 傳統方法學
傳統方法學：也稱爲生命週期方法學或結構化範型。
它採用結構化技術(結構化分析、結構化設計和結構化實現)來完成軟件開發的各項任務。
這種方法學把軟件生命週期的全過程依次劃分爲若干個階段，而後順序地完成每一個階段的任務。

　目前，傳統方法學仍然是人們在開發軟件時使用得十分普遍的軟件工程方法學。
此外，要全面瞭解面向對象方法學，先要了解傳統方法學。

傳統方法學優勢（生命週期方法學或結構化範型）
    把軟件生命週期劃分紅若干個階段，每一個階段的任務相對獨立，並且比較簡單，便於不一樣人員分工協做，從而下降了整個軟件開發工程的困難程度；
    在每一個階段結束以前都從技術和管理兩個角度進行嚴格的審查，保證了軟件的質量，特別是提升了軟件的可維護性。
    總之，採用生命週期方法學能夠大大提升軟件開發的成功率，軟件開發的生產率也能明顯提升。

2. 面向對象方法學
    當軟件規模龐大，或者對軟件的需求是模糊的，或軟件需求會隨時間而變化的時候，使用傳統方法學開發軟件每每不成功。
    此外，使用傳統方法學開發出的軟件，維護起來仍然很困難。
緣由：
    這種技術要麼面向行爲(即對數據的操做)，要麼面向數據，把數據和操做人爲地分離成兩個獨立的部分，天然會增長軟件開發與維護的難度。

面向對象方法學具備下述4個要點。
(1) 把對象(object)做爲融合了數據及在數據上的操做行爲的統一的軟件構件。用對象分解取代了傳統方法的功能分解。
(2) 把全部對象都劃分紅類(class)。
(3) 父類與子類的繼承關係。
    把若干個相關類組成一個層次結構的系統，下層派生類自動擁有上層基類中定義的數據和操做。
(4) 對象彼此間僅能經過發送消息互相聯繫。
        對象的全部私有信息都被封裝在該對象內，不能從外界直接訪問，這就是一般所說的封裝性。

面向對象方法學優勢
面向對象方法學的出發點和基本原則，是儘可能模擬人類習慣的思惟方式，從通常到特殊，從特殊到通常，使開發軟件的方法與過程儘量接近人類認識世界解決問題的方法與過程。傳統方法學強調自頂向下順序地完成軟件開發的各階段任務。事實上，人類認識的過程，是一個漸進的過程，通過屢次反覆才能逐步深化。
運用面向對象方法學的開發軟件，最終的軟件產品由許多較小的、基本上獨立的對象組成，下降了軟件產品的複雜性，提升了軟件的可理解性，簡化了軟件的開發和維護工做。

軟件重用。對象是相對獨立的實體，容易在之後的軟件產品中重複使用。
繼承性和多態性，進一步提升了面向對象軟件的可重用性。

2三、實體聯繫圖如何繪製？ ###

詳見50123需求分析 3.4

2四、需求分析階段應該使用哪幾種模型對系統進行建模?

詳見50123需求分析

根據結構化分析準則，需求分析過程應該創建3種模型，它們分別是數據模型、功能模型和行爲模型。

數據模型

實體－聯繫圖，描繪數據對象及數據對象之間的關係，用於創建數據模型。

功能模型

數據流圖，描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具備變化數據的功能，是創建功能模型的基礎。

行爲模型

3.6節狀態轉換圖（狀態圖），指明做爲外部事件結果的系統行爲。描繪了系統的各類行爲模式(稱爲「狀態」)和在不一樣狀態間轉換的方式。是行爲建模的基礎。

2五、軟件維護有哪些類型？

詳見50127維護

四種維護類型：

改正性維護

適應性維護

完善性維護

預防性維護

1.改正性維護

在軟件交付使用後，因開發時測試的不完全、不徹底，必然會有部分隱藏的錯誤遺留到運行階段。

這些隱藏下來的錯誤在某些特定的使用環境下就會暴露出來。

爲了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程。

2.適應性維護

在使用過程當中，外部環境、數據環境可能發生變化。

外部環境（新的硬、軟件配置）

數據環境（數據庫、數據格式、數據輸入/輸出方式、數據存儲介質）

適應性維護：爲使軟件適應這種變化，而去修改軟件的過程。

3.完善性維護

•在軟件的使用過程當中，用戶每每會對軟件提出新的功能與性能要求。

•完善性維護：

爲了知足上述要求，須要修改或再開發軟件而進行的完善性的維護活動。以擴充軟件功能、加強軟件性能、改進加工效率、提升軟件的可維護性。

•完善性維護不必定是救火式的緊急維修，能夠是有計劃、有預謀的一種再開發活動。

4.預防性維護

•預防性維護：

爲了提升軟件的可維護性、可靠性等，爲之後進一步改進軟件打下良好基礎而修改軟件的維護活動。

•預防性維護的定義：

採用先進的軟件工程方法對須要維護的軟件或軟件中的某一部分（從新）進行設計、編制和測試的過程。

國外的統計數字代表：

完善性維護佔所有維護活動的50%～66%，

改正性維護佔17%～21%，

適應性維護佔18%～25%，

其餘維護活動只佔4%左右。

完善性維護佔了幾乎一半的工做量。

可見：

大部分維護工做是改變和增強軟件，不是糾錯。

2六、利率的計算（計複利，不計複利） ###

P本金和利息

S利率

n年

R利息

非複利：第n年本金和利息 P=A*S%*n+A

複利：第n年本金和利息 P=A*（1+S%）ⁿ

2七、軟件測試的任務、目的和類型

測試的正肯定義是：「爲了發現程序中的錯誤而執行程序的過程」。

軟件測試的目標
G.Myers給出了關於測試的一些規則，這些規則也能夠看做是測試的目標或定義。

(1) 測試是爲了發現程序中的錯誤而執行程序的過程；

(2) 好的測試方案是很可能發現迄今爲止還沒有發現的錯誤的測試方案；

(3) 成功的測試是發現了至今爲止還沒有發現的錯誤的測試。

測試是在精心控制的環境下執行程序，以發現程序中的錯誤，給出程序可靠性的鑑定。

軟件測試準則

（1）全部測試都應該能追溯到用戶需求。

軟件測試的目標是發現錯誤，最嚴重的錯誤是致使程序不能知足用戶需求。

（2）應該遠在測試開始以前就制定出測試計劃。

在完成需求模型時，就着手製定測試計劃，

在創建了設計模型後，就開始設計詳細的測試方案。

（3）應該從「小規模」測試開始，並逐步進行「大規模」測試。

先測試單個程序模塊，再測試集成模塊，最後在整個系統中尋找錯誤。

（4）應該由獨立的第三方從事測試工做。

軟件工程師不能承擔所有測試工做，主要承擔模塊測試工做。

（5）窮舉測試是不可能的。

窮舉測試：把程序全部可能的執行路徑都檢查一遍的測試。

即便是一箇中等規模的程序，其執行路徑的排列數也十分龐大。所以，測試只能證實程序中有錯誤，不能證實程序中沒有錯誤。

類型

•黑盒測試：指在軟件界面上進行的測試。通常用來證明軟件功能的可操做性；證明能很好的接收輸入，並正確地產生輸出；以及證明對外部信息完整性的保持。

•白盒測試：對程序細節進行嚴密檢驗，對軟件的邏輯路徑進行測試。

現有的軟件項目組的組織方式不少，一般，組織軟件開發人員的方法，取決於所承擔的項目的特色、以往的組織經驗以及管理者的見解和喜愛。下面介紹3種典型的組織方式。

民主製程序員組

民主製程序員組的一個重要特色是，小組成員徹底平等，享有充分民主，經過協商作出技術決策。所以，小組成員之間的通訊是平行的，若是小組內有n個成員，則可能的通訊信道共有n(n-1)/2條。

程序設計小組的人數不能太多,不然組員間彼此通訊的時間將多於程序設計時間。此外,一般不能把一個軟件系統劃分紅大量獨立的單元,所以,若是程序設計小組人數太多,則每一個組員所負責開發的程序單元與系統其餘部分的界面將是複雜的,不只出現接口錯誤的可能性增長,並且軟件測試將既困難又費時間。

通常說來，程序設計小組的規模應該比較小,以2～8名成員爲宜。若是項目規模很大,用一個小組不能在預約時間內完成開發任務,則應該使用多個程序設計小組,每一個小組承擔工程項目的一部分任務，在必定程度上獨立自主地完成各自的任務。系統的整體設計應該可以保證由各個小組負責開發的各部分之間的接口是良好定義的,而且是儘量簡單的。

小組規模小,不只能夠減小通訊問題,並且還有其餘好處。例如,容易肯定小組的質量標準,並且用民主方式肯定的標準更容易被你們遵照;組員間關係密切,可以互相學習等等。

民主製程序員組一般採用非正式的組織方式，也就是說，雖然名義上有一個組長，可是他和組內其餘成員完成一樣的任務。在這樣的小組中，由全體討論協商決定應該完成的工做，而且根據每一個人的能力和經驗分配適當的任務。

民主製程序員組的主要優勢是，組員們對發現程序錯誤持積極的態度，這種態度有助於更快速地發現錯誤，從而致使高質量的代碼。

民主製程序員組的另外一個優勢是，組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利於攻克技術難關。所以，當有難題須要解決時，也就是說，當所要開發的軟件的技術難度較高時，採用民主製程序員組是適宜的。

若是組內多數成員是經驗豐富技術熟練的程序員,那麼上述非正式的組織方式可能會很是成功。在這樣的小組內組員享有充分民主,經過協商,在自願的基礎上做出決定,所以可以加強團結、提升工做效率。可是,若是組內多數成員技術水平不高,或是缺少經驗的新手,那麼這種非正式的組織方式也有嚴重缺點：因爲沒有明確的權威指導開發工程的進行,組員間將缺少必要的協調,最終可能致使工程失敗。

爲了使少數經驗豐富、技術高超的程序員在軟件開發過程當中可以發揮更大做用，程序設計小組也能夠採用下一小節中介紹的另一種組織形式。

主程序員組

美國IBM公司在20世紀70年代初期開始採用主程序員組的組織方式。採用這種組織方式主要出於下述幾點考慮：

(1) 軟件開發人員多數比較缺少經驗；

(2) 程序設計過程當中有許多事務性的工做，例如，大量信息的存儲和更新；

(3) 多渠道通訊很費時間，將下降程序員的生產率。

主程序員組用經驗多、技術好、能力強的程序員做爲主程序員，同時，利用人和計算機在事務性工做方面給主程序員提供充分支持，並且全部通訊都經過一兩我的進行。這種組織方式相似於外科手術小組的組織：主刀大夫對手術全面負責，而且完成制訂手術方案、開刀等關鍵工做，同時又有麻醉師、護士長等技術熟練的專門人員協助和配合他的工做。此外，必要時手術組還要請其餘領域的專家（例如，心臟科醫生或婦產科醫生）協助。

上述比喻突出了主程序員組的兩個重要特性：

（1）專業化。該組每名成員僅完成他們受過專業訓練的那些工做。

（2）層次性。主刀大夫指揮每名組員工做，並對手術全面負責。

當時，典型的主程序員組的組織形式如圖13.5所示。該組由主程序員、後備程序員、編程祕書以及1~3名程序員組成。在必要的時候，該組還有其餘領域的專家協助。

圖13.5 主程序員組的結構

主程序員組核心人員的分工以下所述：

（1）主程序員既是成功的管理人員又是經驗豐富、技術好、能力強的高級程序員，負責體系結構設計和關鍵部分（或複雜部分）的詳細設計，而且負責指導其餘程序員完成詳細設計和編碼工做。如圖13.5所示，程序員之間沒有通訊渠道，全部接口問題都由主程序員處理。主程序員對每行代碼的質量負責，所以，他還要對組內其餘成員的工做成果進行復查。

（2）後備程序員也應該技術熟練並且富於經驗，他協助主程序員工做而且在必要時（例如，主程序員生病、出差或「跳槽」）接替主程序員的工做。所以，後備程序員必須在各方面都和主程序員同樣優秀，而且對本項目的瞭解也應該和主程序員同樣深刻。平時，後備程序員的工做主要是，設計測試方案、分析測試結果及獨立於設計過程的其餘工做。

（3）編程祕書負責完成與項目有關的所有事務性工做，例如，維護項目資料庫和項目文檔，編譯、連接、執行源程序和測試用例。

注意，上面介紹的是20世紀70年代初期的主程序員組組織結構，如今的狀況已經和當時大不相同了，程序員已經有了本身的終端或工做站，他們本身完成代碼的輸入、編輯、編譯、連接和測試等工做，無須由編程祕書統一作這些工做。典型的主程序員組的現代形式將在下一小節介紹。

雖然圖13.5所示的主程序員組的組織方式提及來有很多優勢，可是，它在許多方面倒是不切實際的。

首先，如前所述，主程序員應該是高級程序員和優秀管理者的結合體。承擔主程序員工做須要同時具有這兩方面的才能，可是，在現實社會中這樣的人才並很少見。一般，既缺少成功的管理者也缺少技術熟練的程序員。

其次，後備程序員更難找。人們指望後備程序員像主程序員同樣優秀，可是，他們必須坐在「替補席」上，拿着較低的工資等待隨時接替主程序員的工做。幾乎沒有一個高級程序員或高級管理人員願意接受這樣的工做。

第三，編程祕書也很難找到。專業的軟件技術人員通常都厭煩平常的事務性工做，可是，人們卻指望編程祕書成天只幹這類工做。

咱們須要一種更合理、更現實的組織程序員組的方法，這種方法應該能充分結合民主製程序員組和主程序員組的優勢，而且能用於實現更大規模的軟件產品。

現代程序員組

民主製程序員組的一個主要優勢，是小組成員都對發現程序錯誤持積極、主動的態度。可是，使用主程序員組的組織方式時，主程序員對每行代碼的質量負責，所以，他必須參與全部代碼審查工做。因爲主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工做就會把所發現的程序錯誤與小組成員的工做業績聯繫起來，從而形成小組成員出現不肯意發現錯誤的心理。

解決上述問題的方法是，取消主程序員的大部分行政管理工做。前面已經指出，很難找到既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工做，不只解決了小組成員不肯意發現程序錯誤的心理問題，也使得尋找主程序員的人選再也不那麼困難。因而，實際的「主程序員」應該由兩我的共同擔任：一個技術負責人，負責小組的技術活動；一個行政負責人，負責全部非技術性事務的管理決策。這樣的組織結構如圖13.6所示。技術組長天然要參與所有代碼審查工做，由於他要對代碼的各方面質量負責；相反，行政組長不能夠參與代碼審查工做，由於他的職責是對程序員的業績進行評價。行政組長應該在常規調度會議上了解每名組員的技術能力和工做業績。

圖13.6 現代程序員組的結構

在開始工做以前明確劃分技術組長和行政組長的管理權限是很重要的。可是，即便已經作了明確分工，有時也會出現職責不清的矛盾。例如，考慮年度休假問題，行政組長有權批准某個程序員休年假的申請，由於這是一個非技術性問題，可是技術組長可能立刻否決了這個申請，由於已經接近預約的項目結束日期，目前人手很是緊張。解決這類問題的辦法是求助於更高層的管理人員，對行政組長和技術組長都認爲是屬於本身職責範圍內的事務，制定一個處理方案。

因爲程序員組成員人數不宜過多，當軟件項目規模較大時，應該把程序員分紅若干個小組，採用圖13.7所示的組織結構。該圖描繪的是技術管理組織結構，非技術管理組織結構與此相似。由圖能夠看出，產品開發做爲一個總體是在項目經理的指導下進行的，程序員向他們的組長彙報工做，而組長則向項目經理彙報工做。當產品規模更大時，能夠適當增長中間管理層次。

圖13.7 大型項目的技術管理組織結構

把民主製程序員組和主程序員組的優勢結合起來的另外一種方法，是在合適的地方採用分散作決定的方法，如圖13.8所示。這樣作有利於造成暢通的通訊渠道，以便充分發揮每一個程序員的積極性和主動性，集思廣益攻克技術難關。這種組織方式對於適合採用民主方法的那類問題（例如，研究性項目或遇到技術難題須要用集體智慧攻關）很是有效。儘管這種組織方式適當地發揚了民主，可是上下級之間的箭頭（即管理關係）仍然是向下的，也就是說，是在集中指導下發揚民主。顯然，若是程序員能夠指揮項目經理，則只會引發混亂。

圖13.8 包含分散決策的組織方式

3二、軟件項目規模的估計有幾種方法？

詳見5018軟件項目管理

估算軟件規模

13.1.1 代碼行技術

代碼行技術是比較簡單的定量估算軟件規模的方法。這種方法依據以往開發相似產品的經驗和歷史數據，估計實現一個功能所須要的源程序行數。當有以往開發相似產品的歷史數據可供參考時，用這種方法估計出的數值仍是比較準確的。把實現每一個功能所須要的源程序行數累加起來，就可獲得實現整個軟件所須要的源程序行數。

爲了使得對程序規模的估計值更接近實際值，能夠由多名有經驗的軟件工程師分別作出估計。每一個人都估計程序的最小規模(a)、最大規模(b)和最可能的規模(m)，分別算出這3種規模的平均值,和以後，再用下式計算程序規模的估計值：

L= (13.1)

用代碼行技術估算軟件規模時，當程序較小時經常使用的單位是代碼行數（LOC），當程序較大時經常使用的單位是千行代碼數（KLOC）。

代碼行技術的主要優勢是，代碼是全部軟件開發項目都有的「產品」，並且很容易計算代碼行數。代碼行技術的缺點是：源程序僅是軟件配置的一個成分，用它的規模表明整個軟件的規模彷佛不太合理；用不一樣語言實現同一個軟件所須要的代碼行數並不相同；這種方法不適用於非過程語言。爲了克服代碼行技術的缺點，人們又提出了功能點技術。

13.1.2 功能點技術

功能點技術依據對軟件信息域特性和軟件複雜性的評估結果，估算軟件規模。這種方法用功能點（FP）爲單位度量軟件規模。

1. 信息域特性

功能點技術定義了信息域的5個特性，分別是輸入項數(Inp)、輸出項數(Out)、查詢數(Inq)、主文件數(Maf)和外部接口數(Inf)。下面講述這5個特性的含義。

（1）輸入項數：用戶向軟件輸入的項數，這些輸入給軟件提供面向應用的數據。輸入不一樣於查詢，後者單獨計數，不計入輸入項數中。

（2）輸出項數：軟件向用戶輸出的項數，它們向用戶提供面向應用的信息，例如，報表和出錯信息等。報表內的數據項不單獨計數。

（3）查詢數：查詢便是一次聯機輸入，它致使軟件以聯機輸出方式產生某種即時響應。

（4）主文件數：邏輯主文件（即數據的一個邏輯組合，它多是大型數據庫的一部分或是一個獨立的文件）的數目。

（5）外部接口數：機器可讀的所有接口（例如，磁盤或磁帶上的數據文件）的數量，用這些接口把信息傳送給另外一個系統。

2. 估算功能點的步驟

用下述3個步驟，可估算出一個軟件的功能點數（即軟件規模）。

（1）計算未調整的功能點數UFP

首先，把產品信息域的每一個特性(即Inp、Out、Inq、Maf和Inf)都分類爲簡單級、平均級或複雜級，並根據其等級爲每一個特性分配一個功能點數（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個複雜級的輸入項分配6個功能點）。

而後，用下式計算未調整的功能點數UFP： UFP=a₁×Inp+a₂×Out+a₃×Inq+a₄×Maf+a₅×Inf

其中，a_i(1≤i≤5)是信息域特性係數，其值由相應特性的複雜級別決定，如表13.1（見書297頁）所示。

(2) 計算技術複雜性因子TCF

這一步驟度量14種技術因素對軟件規模的影響程度。這些因素包括高處理率、性能標準（例如，響應時間）、聯機更新等，在表13.2（見書297頁）中列出了所有技術因素，並用F_i(1≤i≤14)表明這些因素。根據軟件的特色，爲每一個因素分配一個從0（不存在或對軟件規模無影響）到5（有很大影響）的值。而後，用下式計算技術因素對軟件規模的綜合影響程度DI：

DI=

技術複雜性因子TCF由下式計算：

TCF=0.65+0.01×DI

由於DI的值在0~70之間，因此TCF的值在0.65~1.35之間。

（3）計算功能點數FP

用下式計算功能點數FP：

FP=UFP×TCF

功能點數與所用的編程語言無關，看起來功能點技術比代碼行技術更合理一些。可是，在判斷信息域特性複雜級別和技術因素的影響程度時，存在着至關大的主觀因素。

3三、能力成熟度模型中成熟度有哪5個等級，各有何特色？

詳見5018軟件項目管理

能力成熟度的5個等級從低到高依次是：

初始級（又稱爲1級），

軟件過程的特徵是無序的，有時甚至是混亂的。幾乎沒有什麼過程是通過定義的（即沒有一個定型的過程模型），項目可否成功徹底取決於開發人員的我的能力。

可重複級（又稱爲2級），

軟件機構創建了基本的項目管理過程(過程模型),可跟蹤成本、進度、功能和質量。已經創建起必要的過程規範，對新項目的策劃和管理過程是基於之前相似項目的實踐經驗，使得有相似應用經驗的軟件項目可以再次取得成功。達到2級的一個目標是使項目管理過程穩定，從而使得軟件機構能重複之前在成功項目中所進行過的軟件項目工程實踐。

處於2級成熟度的軟件機構的過程能力能夠歸納爲，軟件項目的策劃和跟蹤是穩定的，已經爲一個有紀律的管理過程提供了可重複之前成功實踐的項目環境。軟件項目工程活動處於項目管理體系的有效控制之下，執行着基於之前項目的準則且合乎現實的計劃。

已定義級（又稱爲3級），

軟件機構已經定義了完整的軟件過程（過程模型），軟件過程已經文檔化和標準化。全部項目組都使用文檔化的、通過批准的過程來開發和維護軟件。這一級包含了第2級的所有特徵。
在第3級成熟度的軟件機構中，有一個固定的過程小組從事軟件過程工程活動。當須要時，過程小組能夠利用過程模型進行過程例化活動，從而得到一個針對某個特定的軟件項目的過程實例，並投入過程運做而開展有效的軟件項目工程實踐。同時，過程小組還能夠推動軟件機構的過程改進活動。在該軟件機構內實施了培訓計劃，可以保證全體項目負責人和項目開發人員具備完成承擔的任務所要求的知識和技能。

處於3級成熟度的軟件機構的過程能力能夠歸納爲，不管是管理活動仍是工程活動都是穩定的。軟件開發的成本和進度以及產品的功能和質量都受到控制，並且軟件產品的質量具備可追溯性。這種能力是基於在軟件機構中對已定義的過程模型的活動、人員和職責都有共同的理解。

已管理級（又稱爲4級）

軟件機構對軟件過程（過程模型和過程實例）和軟件產品都創建了定量的質量目標，全部項目的重要的過程活動都是可度量的。該軟件機構收集了過程度量和產品度量的方法並加以運用，能夠定量地瞭解和控制軟件過程和軟件產品，併爲評定項目的過程質量和產品質量奠基了基礎。這一級包含了第3級的所有特徵。

處於4級成熟度的軟件機構的過程能力能夠歸納爲，軟件過程是可度量的，軟件過程在可度量的範圍內運行。這一級的過程能力容許軟件機構在定量的範圍內預測過程和產品質量趨勢，在發生偏離時能夠及時採起措施予以糾正，而且能夠預期軟件產品是高質量的。

優化級（又稱爲5級）

軟件機構集中精力持續不斷地改進軟件過程。這一級的軟件機構是一個以防止出現缺陷爲目標的機構，它有能力識別軟件過程要素的薄弱環節，並有足夠的手段改進它們。在這樣的機構中，能夠得到關於軟件過程有效性的統計數據，利用這些數據能夠對新技術進行成本/效益分析，並能夠優化出在軟件工程實踐中可以採用的最佳新技術。這一級包含了第4級的所有特徵。

這一級的軟件機構能夠經過對過程實例性能的分析和肯定產生某一缺陷的緣由，來防止再次出現這種類型的缺陷；經過對任何一個過程實例的分析所得到的經驗教訓均可以成爲該軟件機構優化其過程模型的有效依據，從而使其餘項目的過程實例獲得優化。這樣的軟件機構能夠經過從過程實施中得到的定量的反饋信息，在採用新思想和新技術的同時測試它們，以不斷地改進和優化軟件過程。

處於5級成熟度的軟件機構的過程能力能夠歸納爲，軟件過程是可優化的。這一級的軟件機構可以持續不斷地改進其過程能力，既對現行的過程實例不斷地改進和優化，又藉助於所採用的新技術和新方法來實現將來的過程改進。
一些統計數字代表，提升一個完整的成熟度等級大約須要花18個月到3年的時間，可是從第1級上升到第2級有時要花3年甚至5年時間。這說明要向一個迄今仍處於混亂的和被動的行動方式的軟件機構灌輸系統化的方式，將多麼困難。

附錄

1、單項選擇（每題2分，共30分）

一、整體設計目的是肯定整個系統的（）。

A、規模 B、測試方案

C、費用 D、功能及模塊結構

二、模塊在同一段時間內完成各類初始化工做，這屬於（）。

A、偶然內聚 B、邏輯內聚

C、時間內聚 D、過程內聚

三、開發軟件所需高成本和產品的低質量之間有着尖銳的矛盾,這種現象稱( )

A. 軟件工程 B. 軟件週期

C. 軟件危機 D. 軟件產生

四、軟件詳細設計的主要任務是肯定每一個模塊的（）

A、算法和使用的數據結構 B、外部接口

C、功能 D、編程

五、軟件結構圖的形態特徵能反映程序重用率的是（）

A、深度 B、寬度

C、扇入 D、扇出

六、爲了提升模塊的獨立性，模塊內部最好是（）

A、邏輯內聚 B、時間內聚

C、功能內聚 D、通訊內聚

7．程序的三種基本控制結構是。

A 過程、子程序、和分程序

B 順序、選擇和循環

C 遞歸、堆棧和隊列

D 調用、返回和轉移

8．可行性研究要進行一次需求分析。

A．詳細的 B.全面的 C.簡化的，壓縮的 D.完全的

9．（）產生軟件危機的緣由主要與兩個方面的問題有關：

A.軟件在計算機中很難識別，存在磁盤中也看不到。

B.軟件設計對人的智商要求很高，也要求很高的資金投入。

C.軟件產品自己的特色與其它工業產品不同，並且在軟件的開發和維護過程當中用的方法不正確。

D.軟件很難理解，硬件也很複雜。

10．（）軟件開發瀑布模型中的軟件定義時期各個階段依次是：

可行性研究，問題定義，需求分析。
問題定義，可行性研究，需求分析。
可行性研究，需求分析，問題定義。
以上順序都不對。

11．（）可行性研究主要從如下幾個方面進行研究：

技術可行性，經濟可行性，操做(社會)可行性。
技術可行性，經濟可行性，系統可行性。
經濟可行性，系統可行性，操做可行性。
經濟可行性，系統可行性，時間可行性。

12． ( ) 耦合是對軟件不一樣模塊之間互連程度的度量。各類耦合按從強到弱排列以下：

內容耦合，控制耦合，數據耦合，公共環境耦合。
內容耦合，控制耦合，公共環境耦合，數據耦合。
內容耦合，公共環境耦合，控制耦合，數據耦合。
控制耦合，內容耦合，數據耦合，公共環境耦合。

13．（）在詳細設計階段所使用到的設計工具是：

程序流程圖，PAD圖，N-S圖，斷定表，斷定樹.
數據流圖，Yourdon 圖，程序流程圖，PAD圖，N-S圖，HIPO圖。
斷定表，斷定樹，數據流圖，系統流程圖，程序流程圖，PAD圖，N-S圖。
斷定表，斷定樹，數據流圖，系統流程圖，程序流程圖，層次圖。

14.（）按照軟件工程的原則，模塊的做用域和模塊的控制域之間的關係是：

A.模塊的做用域應在模塊的控制域以內。

B.模塊的控制域應在模塊的做用域以內。

C.模塊的控制域與模塊的做用域互相獨立。

D.以上說法都不對。

15. 1960年末Dijkstra提倡的（）是一種有效的提升程序設計效率的方法。

A) 標準化程序設計

B) 模塊化程序設計

C) 多道程序設計

D) 結構化程序設計

2、填空題（每空2分，共12分）

1. 模塊的獨立程度能夠由兩個定性標準度量，這兩個標準分別稱爲（內聚）和（耦合）。

2．整體設計的第二項任務是設計軟件的結構，即肯定（ 功能和模塊結構）。

3．若是模塊內全部元素都使用同一個輸入數據和產生同一個輸出，稱爲（通訊）內聚。

4．數據流程圖按照信息流的類型主要分爲（ 事務流 ）、（ 變換流 ）兩種。

三、名詞解釋（每題6分，共24分）

一、軟件工程

詳見5011軟件工程_軟件工程學概述
歸納地說，
軟件工程：是指導計算機軟件開發和維護的一門工程學科。
採用工程的概念、原理、技術和方法來開發與維護軟件，把通過時間考驗而證實正確的管理技術和當前可以獲得的最好的技術方法結合起來，以經濟地開發出高質量的軟件並有效地維護它，這就是軟件工程。

人們曾經給軟件工程下過許多定義，下面給出兩個典型的定義。
1968年在第一屆NATO會議上曾經給出了軟件工程的一個早期定義：「軟件工程就是爲了經濟地得到可靠的且能在實際機器上有效地運行的軟件，而創建和使用完善的工程原理。」
這個定義不只指出了軟件工程的目標是經濟地開發出高質量的軟件，並且強調了軟件工程是一門工程學科，它應該創建並使用完善的工程原理。
1993年IEEE進一步給出了一個更全面更具體的定義：「軟件工程是： ①把系統的、規範的、可度量的途徑應用於軟件開發、運行和維護過程，也就是把工程應用於軟件； ②研究①中提到的途徑。」

二、模塊

詳見50124整體設計
模塊：是由邊界元素限定的相鄰程序元素（例如，數聽說明，可執行的語句）的序列，並且有一個整體標識符表明它。按照模塊的定義，過程、函數、子程序和宏等，均可做爲模塊。

3．軟件生命週期