專題七：軟件工程專題

1、軟件工程知識

1.1概述

軟件工程是指應用計算機科學、數學及管理科學等原理，以工程化的原則和方法來解決軟件

問題的工程。其目的是提高軟件生產率、提高軟件質量、減低軟件成本。

軟件工程是1968年在德國的NATO會議上提出的，希望用工程化的原則和方法來克服軟件危

機：血軟件危機就是軟件開發和維護過程中的各種問題，由于軟件開發階段缺乏好的方法的指導

和好的工具的輔助，而且缺少有關的文檔，使得大量的軟件難以維護。

軟件由計算機程序、數據及文檔組成，同時與硬件、數據庫人、過程等共同構成計算機系統。

軟件工程包括三個要素：方法、工具和過程。

軟件生命周期是指由軟件定義、軟件開發和軟件維護等階段組成的全過程，反映軟件生存期

內各種工作得組織以及各個階段如何銜接。下表歸納了軟件生存周期各個階段的任務、參與人員

和產生文檔。

階段任務參與人員產生文檔

軟件定義階段一一待開發軟件要“做什么”

系統分析確定待開發軟件的總體要求用戶、項目負責人、系可合并項目計劃書

和適用范圍，以及與之有關統分析員中

的硬件、支撐軟件的要求

軟件項目計劃確定待開發軟件的目標，對用戶、項目負責人、系可行性分析報告、

其進行可行性分析，并對資統分析員項目計劃書

源分配、進度安排等做出合

理的計劃

需求分析確定待開發軟件的功能、性用戶、項目負責人、系需求規格說明書

能、界面等要求，從而確定統分析員

系統的邏輯模型

軟件開發階段一一待開發軟件“怎么做”

概要設計模塊分解，確定軟件的結構，系統分析員、高級程序設計說明書、數據

軟模塊的功能和模塊間的接員說明書、模塊開發

件口，以及全局數據結構的設有示

設計

計詳細設計設計每個模塊的實現細節和高級程序員、程序員

局部數據結構的設計

編碼用某種程序語言為每個模塊高級程序員、程序員程序清單

編寫程序

軟件測試發現軟件中的錯誤，并加以高級程序員或系統分軟件測試計劃、軟

糾正析員（另一部門或單件測試用例說明，

位）軟件測試報告

軟件維護階段一開發后交付使用的軟件的維護

軟件維護使軟件適應外界環境的變維護人員維護計劃、維護報

化、實現功能的擴充和質量生

的改善而修改軟件

可行性分析的任務是從技術上、經濟上、使用上、法律上分析需解決的問題是否存在可行的解。

運行維護階段：改正性維護、適應性維護、完善性維護、預防性維護

主要的軟件開發方法有以下幾種方法：

?生命周期法：每一個軟件系統都有一定的生命周期。軟件的生命周期是指一個軟件系

統從其提出、調查到分析、設計和有效使用，直至被淘汰或取代的整個期間。軟件生

命周期法就是按軟件生命周期的各個階段劃分任務，按一定的規則和步驟，有效地進

行軟件開發的方法。

通常一個軟件系統的生命周期可分為五個階段：準備階段、分析階段、設計階段、實

施階段、運行與維護階段

?原型法：原型法是先根據用戶的最主要要求，開發出能實現系統最基本功能的一個原

型，再根據用戶對原型使用與評價的意見，反復修改完善原型，直到等到用戶滿意的

最終系統為止。

原型法分4個階段：確定用戶需求；設計原型；使用、評價原型；修改、完善原型。

1.2開發過程與分析

軟件開發模型：瀑布模型；增量模型：演化模型（快速原理）；螺旋模型：統一過程模型

?瀑布模型（經典生命周期）

1.線性流程

2.強制、系統、規范、可控

3.由義檔驅動

4.階段評審

5.適用：需求明確而穩定

□

□溝通

□策劃

□建模（分析,設計）

□構建（編碼，測試）

部署（交付,反饋）交付第"個增量

第2個增量

第1個增量交付第2個培量

交付第1個增增

項目時間

?快速原型（屬于一種演化模型）

1.原型：模擬某種產品的原始模型（“樣機”）。

2.獲得基本需求一快速分析設計一構造原型一用戶使用并反饋一修改或重建系統

3.適用：需求不明確

4.幫助用戶明確需求

5.幫助開發人員明確算法效率、兼容性等問題

6.原型可作為一-種技術，用于其它過程模型中。

?螺旋模型

1.風險驅動

2.整個生命周期

3.適用：大系統

?統一過程模型RUP/UP

1.適用：面向對象的web系統

2.五個階段：起始、細化、構建、轉換、生產。

3.RUP使用UML建模，它既是過程模型，也包含了一整套開發工具。

4.RUP用角色表述“誰做”,用制品表述“做什么”，用活動表述“怎么做”，用工作流表述

“什么時候做”。

5.用例驅動，以架構為核心，迭代且增量。

?敏捷開發

1.輕量級、精簡、快速

2.極限編程XP：小版本發布、結對編程、持續集成、原型、重構、測試驅動

需求分析是軟件生存周期中相當重要的一個階段。需求分析主要是確定待開發軟件的功能、

性能、數據、界面等要求。具體有以下幾點：

>確定軟件系統的綜合要求

>分析軟件系統的數據要求

>導出系統的邏輯模型

>修正項目開發計劃

>如有必要，可開發一個原型系統

需求分析

需求分析的基本原則是能夠表達和理解問題的信息域和功能域；以層次化的方式進行分解和

不斷細化：要給出系統的邏輯視圖和物理視圖。

軟件需求的方法：

?功能層次模型：一般來講就是系統的功能圖，模塊分布圖等描述整個系統的功能的分布和

功能的層次結構；

?數據流模型：就是以數據流為著眼點的分析方法得到的模型，主要通過數據在整個系統的

流動情況來確定系統的主要功能主線和流程；

?控制流模型：通過/解和界定系統中控制線，通過控制流的走向和控制的對象來確定系統

的功能分布和控制與被控制的關系；

結構化分析(SA)方法

是-一種面向數據流的需求分析方法，它適用于分析大型數據處理系統。結構化分析方法的基

本思想是自頂向下逐層分解，這樣做可以把一個大問題分解成若干個小問題，經過多次逐層分解,

每個最底層的問題都是足夠簡單、容易解決的，這個過程就是分解的過程。

SA的模型

1.數據字典是核心。

2.實體關系圖（ER圖）：用于數據建模。

3.數據流圖（DFD圖）：用于功能建模。

4.狀態遷移圖（STD圖）：用于行為建模。

結構化方法的分析結果由數據流圖DFD、數據詞典和加工邏輯說明幾個部分組成。

數據流圖DFD

基本成分有數據流（dataflow）加工（process）、文件（file）和源/宿（source/sink）。

■畫數據流圖的基本步驟：白外向內、白頂向下、逐層細化、完善求精：

■數據流圖的父圖與子圖要平衡，即輸入和輸出的數據流一致：

■數據流圖中的每個加工至少有一個輸入數據流和一個輸出數據流：

■局部的數據存儲不畫出來，只有當局部數據存儲作為某些數據加工之間的數據接口才畫

出，這有利于信息隱蔽；

■畫數據流的時候不畫控制流，兩者的區別就是控制流中沒有數據；

■一個加工的數據流與輸出流不應該同名：

■允許一個加工有多條數據流流向另一個加工，也允許一個加工有兩個相同的輸出流向兩個

不同的加工：

■保持數據守恒：一個加工的所有輸出數據必須能從該加工的所有的輸入流中獲得：

■在整套數據流圖中，每個文件都必須既有讀文件的數據流也有寫文件的數據流；

軟件開發過程中的軟件工程原則（8個）：

>抽象；

>自頂向下、逐層細化；

>信息隱蔽和數據封裝：

>模塊化：

>局部化；

>確定性；

>一致性和標準化；

>完備性和可驗證性；

軟件工程基本原理（7個）：

■按軟件生存周期分階段指定計劃并認真實施：

■堅持進行階段評審：

■堅持嚴格的產品控制；

■使用現代程序設計技術；

■明確責任，使得工作結果能夠得到清楚的審查；

■用人少而精；

■不斷改進開發過程：

1.3軟件設計

軟件設計原則：軟件設計的原則對提高軟件的設計質量有很大的幫助。

?抽象

抽象是指忽視?個主題中與當前目標無關的那些方面，以哽更充分地注意與當前目標有關的方

面。過程抽象和數據抽象是常用的兩種主要抽象手段。

?模塊化

模塊化是指將一個待開發的軟件分解成若干個小的簡單的部分一一模塊，每個模塊可獨立地開

發、測試、最后組裝成完整的軟件。這是一種復雜問題的“分而治之”的原則。

模塊是指執行某一特定任務的數據結構和程序代碼。一個模塊有它的外部特征和內部特征。

.信息隱蔽

信息隱蔽是開發整體程序結構時使用的法則，即將每個程序的成分隱蔽或封裝在?個單一的設計

模塊中，定義每一個模塊時盡可能少地顯露其內部的處理。信息隱蔽原則對提高軟件的可修改性、

可測試性和可移植性都有重要的作用。

?模塊獨立

模塊獨立是指每個模塊完成一個相對獨立的子功能，并且與其他模塊之間的聯系簡單。衡量模塊

獨立程度的度量標準有兩個：低耦合和高內聚。

耦合

耦合是指模塊之間聯系的緊密程度。耦合度越高則模塊的獨立性越差。

從低到高依次耦合方式。

?數據耦合：模塊A調用模塊B時，通過簡單的數據參數來交換信息。

?標記耦合：參數表傳遞復雜的數據結構信息。

?控制耦合：模塊A通過傳送開關、標志等控制信息、，明顯地控制模塊B的功能。

?外部耦合：一組模塊訪問同一個全局簡單變量。

?公共耦合：一組模塊訪問同一個公共數據環境（復雜數據）。

?內容耦合：模塊A直接訪問模塊B的內部數據：模塊A非正常入口轉到模塊B內部：兩個模

塊有一部分程序代碼重疊；一個模塊有多個入口。

內聚

內聚是指模塊內部各元素之間聯系的緊密程度，內聚度越低模塊的獨立性越差。

從低到高依次內聚種類。

?偶然內聚：指模塊內的各處理元素之間沒有任何聯系。

?邏輯內聚：指模塊內執行幾個邏輯上相似的功能，通過參數確定該模塊完成哪一個功能。

?時間內聚：把需要同時執行的動作組合在一起的模塊。

?通信內聚：指模塊內所有處理元素都在同一個數據結構上操作，或者各處理使用相同的輸入

數據或者產生相同的輸出數據。

?順序內聚：指模塊中各個處理元素都密切相關于同一功能且必須順序執行，前一個功能元素

的輸出就是下一個功能元素的輸入。

?功能內聚：模塊內所有元素共同完成一個功能，缺一不可。

?重構

許多敏捷方法都建議采用重構，即不改變代碼的外部行為，只修改其內部結構，達到改進。

模塊分解原則：

>滿足信息隱蔽；

>盡量內聚度高，模塊間偶合度低；

>模塊大小在（50T00語句）：

>模塊調用深度不能過大；

>模塊的扇入（直接調用該模塊）應盡量大，扇出（直接調用下級模塊數）不宜過大：

>設計單人口和單出口的模塊：

>模塊的作用域應在控制域之內：

作用域：受模塊內一個判定影響的所有的模塊的集合；

控制域：該模塊本身和被該模塊直接或間接調用的所有的模塊的集合；

>模塊的功能應是可以預測的，相同輸入得到相同輸出

結構化設計方法

結構化設計（SD）方法是一種面向數據流的設計方法，它可以與SA方法銜接。

結構化設計采用結構圖（SC）來描述程序的結構。基本成分有模塊、調用和輸入/輸出數據。

結構圖：

寬度

在需求分析階段用SA方法產生了數據流圖（DFD）。面向數據流的設計可以方便的將DFD

轉換成程序結構圖。DFD從系統的輸入數據流到系統的輸出數據流的一連串連續變換形成一條信

息流。DH）的信息流大體可分為兩種類型：變換流和事務流。與之對應的也存在兩種分析，變換

分析和事務分析。變換分析是從變換流型的DFD導出程序結構圖，而事務分析則是從事務流行型

的DFD導出程序結構圖。

SD方法的具體設計步驟為：

>復查并精化數據流圖

>確定DFD的信息流類型

>根據信息流類型分別將變換流或事務流轉換成程序結構圖

>根據軟件設計的原則對程序結構圖作改進

結構化程序設計

結構化程序（SP）設計采用自頂向下逐步求精的設計方法和單入口單出口的控制結構。

結構化程序設計的描述工具主要有圖形描述工具、語言描述工具和表格描述工具。常用的圖形描

述工具有程序流程圖、盒圖（NS圖）利問題分析圖（PAD）0典型的語言描述工具是PDL（program

designlanguage）（,典型的表格描述工具是判定表和判定樹。

Jackson方法是以數據結構為設計基礎，設計目標是得出對程序處理過程的描述，其設

計過程是從描繪數據結構的Jackson圖推導出描繪程序結構的Jackson圖。這種方法最適合于詳

細設計階段使用。

Jackson方法的具體設計步驟為：

>分析并確定輸入和輸出的數據的邏輯結構，并用Jackson圖表示

>找出輸入數據結構與輸出數據結構間有對應關系的數據單元

>從描述數據結構的Jackson圖導出描述程序結構的Jackson圖

L4軟件測試

對源程序最基本的質量要求是正確性和可靠性，此外還很注重軟件的易使用性、易維護性和

易移植性。軟件測試的工作量約占軟件開發總工作量的40*以上，其目的是盡可能多的發現軟件

產品（主要是指程序）中的錯誤和塊陷。

測試流程

制定測試計劃--設計測試用例一-執行測試--分析測試結果-一評估與總結

；重未評審］:董汗評畝單元測試索委測證「驗收測試

集成測試確認測試

測試計劃測試腳本開發測試結果分析和報告

測試執行

測試原則

在軟件測試工作中應注意并遵循的一些原則:

1.測試的標準都是建立在用戶需求之上；

2.測試必須基于“質量第一”的思想去開展;

3.事先定義好產品的質量標準；

4.軟件項目一啟動，軟件測試也就是開始；

5.窮舉測試是不可能的；

6.第三方進行測試會更客觀，更有效；

7.軟件測試計劃是做好軟件測試工作的前提;

8.重視測試用例：

9.對于錯誤較多的程序段，應進行更深入的測試。

軟件測試是白底向匕逐步集成的過程，低一級測試為上一級測試準備條件：

測試的關鍵是測試用例的設計，其方法可分為兩類：

白盒測試：

白盒測試是根據程序的內部邏輯來設計測試用例，常用的技術是邏輯覆蓋，即考察用例測試數據

運行被測程序時對程序邏輯的覆蓋程度。

主要的覆蓋標準有6種：

I.語句覆蓋

指選擇足夠的測試用例，使被測語句的每個語句至少執行一次。

II.判定覆蓋

指選擇足夠的測試用例，使每個判定的所有可能結果至少已現一次。

IH.條件覆蓋

指選&足夠的測試用例，使判定中的每個條件的所有可能結果至少出現一次。

IV.判定/條件覆蓋

指選擇足夠的測試用例，使判定中的每個條件的所有可能結果至少出現一次，并且每個判定中條

件結果的所有可能組合也至少出現一次。

V.條件組合覆蓋

指選擇足夠的測試用例，使每個判定中條件結果的所有可能組合至少出現一次。

VI路徑覆蓋

指選擇足夠的測試用例，使流程圖中的每條路徑至少經過一次。

黑盒測試：

黑盒測試時根據規格說明所規定的功能來設計測試用例，它不考慮程序的內部結構和處理過程。

常用的黑盒測試技術有：

>等價類劃分

>邊值劃分

>錯誤猜測

軟件測試的主要步驟有單元測試、集成測試和確認測試。

1.單元測試：

主要用來發現編碼和詳細設計中產生的錯誤，一般在編碼階段，采用白盒測試。

2.集成測試（也稱組裝測試）：

主要用來發現設計階段產生的錯誤，是對各模塊組裝而成的程序進行測試，主要檢查模塊間的接

口和通信，采用黑盒測試。

集成測試按集成方式又可分成非漸增式集成和漸增式集成，而漸增式集成又可分成自頂向下集成

和自底向上集成。

3.確認測試：

檢查軟件的功能、性能和其他特征是否與用戶需求一致，它以需求規格說明書作測成為依據。

1.5軟件開發工具與環境（CASE）

用來輔助軟件開發、運行、維護、管理和支持等過程中的活動的軟件稱為軟件工具，通常也

稱為CASE（計算機輔助軟件工程）工具。

整個軟件開發過程要使用很多開發工具，其中包括分析工具、設計工具、編程工具、測試工

具、維護工具等等。

軟件開瓦工具是指支持軟件產品開發的軟件系統，它由軟件工具集和環境集成機智構成。工

具集包括支持軟件開發相關過程、活動、任務的軟件工具：環境集成機智為工具集成和軟件開發、

維護和管理提供統一的支持。

軟件開發環境是把一組相關的工具集成在環境中，提供數據集成、控制集成和界面集成等機制。

其中:

>數據集成機制：提供統?的數據模式和數據接口規范，需要相互協同的工具通過這種統一

的規范交換數據。數據集成可由共享文件、共享數據結構或共享信息庫等不同的層次；

>控制集成機制：支持各工具或各開發活動之間的通信、切換、調度和協同工作，并且支持

軟件開發過程的描述、執行和轉接；通常消息傳送的方式實現控制的集成。

>界面集成機制使這些工具具有統一的界面風格，從而為軟件開發、維護、管理等過程的各

項活動提供連續的、一致的全方位支持。

集成型軟件開發環境由工具集和環境集成機制組成，這種環境應該具有開放性和可剪裁性：

環境集成機制的核心是環境數據庫。

1.6軟件維護和軟件管理

軟件維護階段是指從軟件交付使用到軟件被淘汰為止的整個時期，它是在軟件交付使月后，

為了改正軟件中隱藏的錯誤，或者為了使軟件適應新的環境，或者為了擴充和完善軟件的功能或

性能而修改軟件的過程.根據引起軟件維護的原因，軟件維護通常可分成改正性維護.適應性維

護、完善性維護、預防性維護。

?改京性維護：是指在使用過程中發現了隱蔽的錯誤后，為了診斷和改正這些隱蔽錯誤而修

改軟件的活動。

?適應性維護：是指為了適用變化了的環境而修改軟件的活動。

?完善性維護：是指為了擴充或完善原有軟件的功能或性能而修改軟件的活動。

?預防性維護：是指為了提高軟件的可維護性和可靠性、為未來的進一步改進打下基礎而修

改軟件的活動。

軟件項目的管理工作可以分位四個方面：軟件項目的計劃、軟件項目的組織、軟件項目的

領導和軟件項目的控制.

1軟件項目的計劃

軟件開發項目的計劃包括定義項"的目標，以及達到E標的力法。他涉及到項目實施的各個

環節，帶有全局的性質，是戰略性的。計劃應力求完備，要考慮到一些未知因素和不確定因素，

考慮到可能的修改。計劃應力求準確，盡可能提高所依據的數據的可靠程度。主要工作集中在軟

件項目的估算、軟件開發成本的估算和軟件項目進度安排。軟件項目計劃的目標是提供一個能使

項目管理人員對資源、成本和進度做出合理估算的框架。這些估算應在軟件項目開始時的一段有

限時間內作出，并隨著項目的進展進行更新。

2軟件項目的估算

軟件項目管理過程開始于項目的計劃，在做項目計劃時，第一項活動是估算。現在已經使用

的使用技術是時間和工作量的估算。因為估算是其他項目計劃活動的基石，而且項目計劃又未軟

件工程過程提供了工作方向，所以我們不能沒有計劃就著手開發，否則就會陷入肓目性。

估算本身帶有風險，估算資源、成本和項目進度時需要經驗、有用的歷史信息、足夠的定量

數據和作定量度量的勇氣。估算的精確程度受到多方面的影響。首先，項目的復雜性對于增加軟

件計劃的不確定性影響很大，復雜性越高，估算的風險就越高。復雜性是相對度量的，他與項目

參加人員的經驗有關，比如如果讓搞MIS的項目組去搞操作系統設計顯然增加了復雜性。其次，

項目的規模對于估算的精確性和功效的影響也比較大，因為隨著軟件規模的擴大，軟件相同元素

之間的相互依賴、相互影響也迅速增加，因而估算時進行向題分解也會變得更加困難。還有項目

的結構化程度也影響項目估算的風險，這里的結構性是指功能分解的簡便性和處理信息的層次

性，結構化程度提高，進行精確估算的能力就提高，相應風險將減少。此外，歷史信息的有效性

也影響估算的風險，在對過去的項目進行這綜合的軟件度量之后，就可以借用來比較準確地進行

估算。影響估算的因素遠不止這些，比如用戶需求的頻繁變更給估算帶來非常大的影響。

估算的依據是軟件的范圍，包括功能，性能、限制、接口和可靠性。在估算開始之前，應對

軟件的功能進行評價，并對其進行適當的細化以便提供更詳細的細節。由于成本和進度的估算都

與功能有關，因此常常采用功能分解的辦法。性能的考慮主要包括處理和響應時間的需求。約束

條件則標識外部硬件、可用存儲和其他現有系統對軟件的限制。

另外軟件項目計劃還要完成資源估算，包括人力資源、硬件資源和軟件資源。在考慮各種軟

件開發資源時最重要的是人，必須考慮人員的技術水平、專業、人數以及在開發過程各階段對各

種人員的需要。硬件資源作為一種工具投入。軟件資源包括各種幫助開發的軟件工具，比如編程

工具、管理工具、測試工具，還有操作系統和數據庫等。

工作兩估算是最普遍使用的技術。經過功能分解之后，可以估計出每?個項H任務的分解都

需要花費若干人年，總計之后就知道軟件項目總體工作量。下面就是一個示意性工作量估算表。

斐格1某軟件系統工作量估算表（單位:人電

任務求分析］設印一編碼|測試小iF

用戶定義2510.58.5

系統定義2510.58.5

廣告預定41020.516.5

劃版520100.535.5

制作和組版353112

總計164517381

軟件開發成本的估算

軟件開發成本主要是指軟件開發過程所花費的工作量及其相應的代價。它不同于其他物理產

品的成本，它主要包括人的勞動的消耗，人的勞動的消耗所需的代價就是軟件產品的開發成本。

開發成本的估算方法有很多種，象簡單的代碼行技術，任務分解技術，自動估計成本技術，

專家判定技術，還有參數方程法，標準值法，以及COCOMO模型法。其中COCOMO(Constructive

CostModel)模型法是一種精確、易于使用的成本估算方法，該模型按其詳細程度分為三級：基

本C0C0M0模型、中間COCOMO模型和詳細COCO.MO模型

軟件項目進度安排

軟件項目的進度安排主要是考慮軟件交付用戶使用的這一段開發時間的安排。進度安排的準

確程度可能比成本估計的準確程度更重要。軟件產品可以靠重新定價或者靠大量的銷售來彌補成

本的增加，但進度安排的落空會導致市場機會的喪失或者用戶不滿意,而且也會導致成本的增加。

因此在考慮進度安排時要把人員的工作量與花費的時間聯系起來，合理分配工作量，利用進度安

排的有效分析方法嚴密監視軟件開發的進展情況，以使得軟件開發的進度不致被拖延。

在進行進度安排時要考慮的一個主要問題是任務的并行性問題。當參加項目的人數不止一人

是軟件開發工作就會出現并行情況。因為并行任務是同時發生的所以進度計劃表必須決定任務之

間的從屬關系，確定各個任務的先后次序和銜接，確定各個任務完成的持續時間。另外還應注意

關鍵路徑的任務，這樣可以確定在進度安排中應保證的重點。常用的進度安排方法有兩種，即甘

特圖(GanttChart)法和工程網絡法。

3.軟件項目的組織

參加軟件開發的人員如何組織起來，使他們發揮最大的工作效率，對成功地完成軟件項目極

為重要。

組織結構

開發組織采用什么形式由軟件項目的特點決定，I可時也與參加人員的素質有關。通常有三種

組織結構模式：

1.按課題組劃分的模式：把開發人員按課題組成小組，小組成員自始至終承擔課題的各項

任務。該模式適用于規模不大的項目，并且要求小組成員在各方面有技術專長。

2.按職能劃分的模式：把開發項目的軟件人員按任務的工作階段劃分為若干工作小組。要

開發的軟件在每個專業小組完成階段加工后沿工序流水線向下傳遞。這種流水作業的方式使用于

多項目并行的情況。

3.矩陣形模型：這種模式是以上兩種模式的復合。一方面按工作性質成立一些專門小組，

另一方面每一個項目都有它的經理人員負責。每一個軟件開發人員屬于某一個專門小組，有參加

某一個項目的工作。該模式的優點有一方面參加專門組的成員可以在組內交流在各個項目中取得

的經驗，這更有利于發揮專業人員的作用；另一方面，各個項目有專門的人員負責，有利于軟件

項1=1的完成。這種模式比較適合于規模比較大的項目。

組織結構的最后一層是程序設計小組的組織形式。通常認為程序設計工作是按獨立的方式進

行的，程序人員獨立地完成任務。但這并不意味著相互之間沒有聯系。一般在人數比較少時組員

之間的聯系比較簡單，但隨著人數的增加，相互之間的聯系變得負責起來。小組內部人員的組織

形式對對生產率有著十分重要的影響。

常見的小組組織形式有三種，這三種形式可以靈活使月。

1.主程序員制小組：相當于組長負責制，小組的核心由一位主程序員，另外配備兩到三位

技術員、一位后援工程師組成。這種組織結構突出主程序員的領導，強調主程序員與其他技術人

員的聯系。

2.民主制小組：在民主制小組中，遇到問題可以在組員之間平等地交換換意見，工作組目標的制

定以及決定的作出都由全體人員參加。這種組織形式強調發揮每個成員的積極性，并要求每個成員發

揮主動精神和協作精神。

3.層次式小組：在層次式小組中，組內人員分位三級：組長(項目負責人)一人負責全組

工作，他直接領導兩到三名高級程序員，每位高級程序員通過基層小組，管理若干位程序員。這

種結構比較適合于項目本身就是層次結構的課題。

人員配備

合理地配備人員是成功地完成軟件項目的切實保證。所謂合理地配備人員應包括按不同階段

適時運用人員，恰當掌握用人標準。一般來說，軟件項目不同階段不同層次技術人員的參與情況

是不一樣的。下圖是典型的軟件開發人員參與情況曲線。

高級技術人員

轆人員

初級技術人員

項目階段

圖1軟件項目人員參與情況圖

在人力配備問題匕由子配置不當，很容易造成人力資源的浪費，并延誤工期。特別是采用

恒定人員配備方案時在項目的開始和最后都會出現人力過剩，而在中期又會出現人力不足的情

況。

4.軟件項目的領導

5.軟件項目的控制

對后面兩個主題以后再討論。其實本文所討論的東西大多還沒有涉及太多管理學方面的內

容，但這方面確實有許多值得研究的東西，由于時間關系穴能深入下去。姑且作為一個引子吧!

1.7面向對象技術

1.7.1基本概念

面向對象(object-oriented,00)方法是以客觀世界中的對象為中心，其分析和設計思想

符合人們的思維方式，分析和設計的結果與客觀世界的實際比較接近，容易被人們所接受。下面

列舉幾個面向對象設計方法中的重要術語，它們構成而向對象的程序設計語言的核心。

?對象(Object)

對象是和有數據及可對這些數據施加的操作結合在一起所構成的獨立單位的總稱。一個對彖通常

可由對象名、屬性和操作三部分組成。

對象的劃分判定標準：

1、子對象之間獨立性要高，即耦合度盡量達到最低，(理想的情況是達到組件化的程度)：

2、子對象相對其他劃分方法，更易于處理。所以對于復雜的大系統，一般都要經過多次的嘗

試，以盡量能找到較優的劃分方案。對于比較簡單的系統，E-R轉換也能的到較為滿意的劃

分。

?實例(Instance)

實例是由某個特定類所描述的?個對象。

?類(Class)

類是一組具有相同屬性和相同操作的對象的集合。類是面向對象的程序設計語言提供的可再用軟

件成分。

?方法(Method)

對象所能執行的操作稱為方法。方法是類中定義的函數，描述對象執行操作的算法。

?消息（Message）

消息是要求某個對象執行類中定義的某個操作的規格說明。一個消息通常包括接受對象名、調用

的操作名和適當的參數（如有必要）。

主要特點：

?封裝性

封裝性是一種信息隱蔽技術，它使系統分析員能夠清咂地標明他們所提供的服務界面，用戶和應

用程序員則只看得見對象提供的操作功能（即封裝面上的信息），看不到其中的數據或操作代碼

細節。

?多態性

多態性是指同一個操作作用于不同的對象可以有不同的解釋，產生不同的執行結果。

?繼承性

繼承是指在某個類的層次關聯中，不同的類共享屬性和操作的一種機制。一個父類可以有多個了?

類。父類描述了這些子類的公共屬性和操作，子類中還可以定義其自己的屬性和操作。如果一個

子類只有唯一的一個父類，這種繼承稱為單一繼承。如果一個子類有多個父類，可以從多個父類

中繼承特性，這種繼承稱為多重繼承。

1.7.2面向對象的分析方法

面向對象的系統分析設計，看起來其實也很簡單，步驟大概如下：

（1）從項目開始，進行步驟（2）。

（2）對系統進行分析，加果它在一定的要求下可解決，則停止分析，進行設計；如果它在一定

的要求下不可解決，則對它進行劃分。

（3）步驟（2）如果有分析結果，則對其中每一個子對象，進行步驟（2）。

邊界條件（也即上面提到的“一定要求”，對象劃分的原則）：

?子對象之間獨立性要高，即耦合度盡量達到最低，（理想的情況是達到組件化的程度）：

?子對象相對其他劃分方法，更易于處理（如實現，維護等）。

當前常見的面向對象的方法很多，下面簡單介紹三種：

PeterCoard和EdwardYoardon的00A和00D方法

00A（面向對象分析）模型由5個層次和5個活動組成：

5個層次：主題層、對象類層、結構層、屬性層、服務層

5個活動：標識對象類、標識結構、定義主題、定義屬性、定義服務

在這種方法中定義兩種對象類之間的結構：

分類結構一一反映了一般與特殊的關系

組裝結構一一反映了對象之間整體與部分的關系

00A中的5個層次和5個活動繼續貫穿在00D（面向對象設計）過程中。00D模型由4個部分，

即：

>問題域

>人機交互

>任務管理

>數據管理

Booth的00D方法

Booth認為軟件開發是一個螺旋上升的過程。在螺旋上升的每個周期中，有4個步驟：

>標識類和對象

>確定它們的含義

>標識它們之間的關系

>說明每一個類的界面和實現

OMT方法

OMT（對象建模技術）定義了3種模型：

>對象模蟄

描述系統中對象的靜態結構、對象之間的關系、對象的屬性、對象的操作。它為動態模

型和功能模型提供了基本的框架。用對象圖表示。

>動態模型：

描述與時間利操作順序有關的系統特征一一激發事件、事件序列、確定事件先后關系的

狀態以及事件和狀態的組織。用狀態圖表示。

>功能模型：

描述與值的變換有關的系統特征一一功能、映射、約束和函數依賴。用數據流圖表示。

OMT方法有4個步驟

分析?：這是OMT方法的第一步，其目的是建立可理解的現實世界模型。

系統設計：確定整個系統的體系結構，形成求解問題和建立解答的高層次策略。

對象設計：在分析的基礎上，對象設計階段建立基于分析模型的設計模型，考慮實現的細節。

實現:將對象設計階段開發的對象類及其關系轉換成特定的程序設計語言、數據庫或硬件的實現。

1.7.3面向對象設計原則

面向對象設計相關原則：

1.開閉原則(theOpenClosedPrincipleOCP)

一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。因此在進行面向龍象設

計時要盡量考慮接口封裝機制、抽象機制和多態技術。該原則同樣適合于非面向對象設計的方法,

是軟件工程設計方法的重要原則之一。

2.替換原則(theLiskovSubstitutionPrincipleLSP)

子類應當可以替換父類并出現在父類能夠出現的任何地方。這個原則是Liskov于1987年提

出的設計原則。它同樣可以從BertrandMeyer的DBC(DesignbyContract)的概念推出。

3.依賴原則(theDependencyInversionPrincipleDIP)

在進行業務設計時，與特定業務有關的依賴關系應該盡量依賴接口和抽象類，而不是依賴于

具體類。具體類只負責相關業務的實現，修改具體類不影響與特定業務有關的依賴關系。

為此，我們在進行業務設計時，應盡量在接口或抽象類中定義業務方法的原型，并通過具體

的實現類(子類)來實現該業務方法，業務方法內容的修改將不會影響到運行時業務方法的調用。

4.接口分離原則(IheInterfaceSegregationPrincipleISP)

采用多個與特定客戶類有關的接口比采用一個通用的涵蓋多個業務方法的接口要好。

ISP原則是另外?個支持諸如COM等組件化的使能技術。缺少ISP,組件、類的可用性和移

植性將大打折扣。

1.8軟件質量(重點)

軟件質吊是指反映軟件系統或軟件產品滿足規定或隱含需求的能力的特征和特性全體。

卜面從管理的角度列出了影響軟件質量的主要因素。

質量因素定義

系統滿足規格說明和用戶目標的程序，即在預定環境卜.能正確的完成

正確性

預期功能的程序

在硬件發生故障、輸入的數據無效或操作錯誤等意外環境下，系統能

產健壯性

做出適當響應的程序

口口

效率為了完成預定的功能，系統需要的計算資源的多少

運

時未經授權的人使用軟件或數據的企圖，系統能夠控制(禁止)的程

行完整性(安全性)

序

可用性系統在完成預定應該完成的功能時令人滿意的程度

風險按預定的成本和進度將系統開發處理，并且為用戶滿意的概率

產可理解性理解和使用該系統的容易程度

品可維修性診斷和改正在運行現場發現的錯誤所需要的工作量的多少

修靈活性(適應性)修改或改進正在運行的系統需要的工作量的多少

改可測試性軟件容易測試的程度

產把程序從一種硬件配置和（或）軟件系統環境轉移到另一種配置和環

可移植性

品境時，需要的工作量多少

轉可再用性在其他應用中該程序可以被再次使用的程度（或范圍）

移互運行性把該系統和另一個系統結合起來需要的工作量的多少

高質雇[:軟件的特性：

?滿足用戶的需求。這是最重要的一點，一個軟件如果不能夠滿足用戶的需要，設計的再好,

采用的技術再先進，乜沒有任何的意義。所以這一點非常的樸實，但卻是軟件質量的第一

個評判標準。

?合理進度、成本、功能關系。軟件開發中所有的管理都是圍繞著這幾個要素在做文章的，

如何在特定的時間內，以特定的成本，開發出特定功能的軟件。三者之間存在一種微妙的

平衡。一個高質量的軟件的開發過程中，項目成員一定能夠客觀的對待這三個因素，并通

過有效的計劃、管理、控制，使得三者之間達成一種平衡，保證產出的最大化。

?具備擴展性和靈活性，能夠適應一定程度的需求變化。當今的社會已經變成一種變化速度

極快的設計了。變化就會對軟件產生沖擊，所以?個質量優秀的軟件，應該能夠在?定程

度上適應這種變化，并保持軟件的穩定。

?能夠有效的處理例外的情況。寫過軟件的人都知道，實現主體功能的工作量其實不大，真

正的工作量都在處理各種例外。所以，一個軟件如果能夠足夠的強壯、足夠的魯棒，能夠

承受各種的非法情況的沖擊，這個軟件就是高質量的。

?保持成本和性能的平衡。性能往往來源于客尸的非功能需求，是軟件質量的一個重要的評

價因素。但是性能問題在任何地方都存在，所以需要客觀的看待它。例如，一段性能不錯

的代碼可能可讀性很差，這就需要進行平衡，如果這段代碼的性能是整個軟件的關鍵，那

么取高性能而舍棄可讀性，反之則取可讀性而舍棄高性能。一個優秀的軟件能夠保持成本

和性能之間的平衡。

?能夠可持續的發展。很少有軟件組織只開發一個軟件的，所以，一個優秀的軟件在開發完

成后，可以形成知識沉淀，為軟件組織的長期發展貢獻力量。這是一個優秀的軟件應該要

能夠做到的。

1.8.1八項質量管理原則

為了成功地領導和運作一個組織,需要采用一種系統和透明的方式進行管理。針對所有相

關方的需求，實施并保持持續改進其業績的管理體系，使組織獲得成功。組織為實現質量目標，

應遵循以下八項質量管理原則：

原則1：以顧客為中心

組織依存于其顧客。因此，組織應理解顧客當前的和未來的需求，滿足顧客要求并爭取超越顧

客期望。

1、組織實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

原則2：領導作用

領導將本組織的宗旨、方向和內部環境統一起來，并創造使員工能夠充分參與實現組織目標

的環境。

1、組織實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

原則3：全員參與

各級人員是組織之本。只有他們的充分參與，才能使他們的才干為組織帶來最大的收益。

1、織實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

原則4：過程方法

過程方法的原則不僅適用于某些較簡單的過程，也適用于由許多過程構成的過程網絡。在應

用于質量管理體系時，2000版IS09000族標準建立了一個過程模式。此模式把管理職責、資源

管理、產品實現、測量、分析與改進作為體系的四大主要過程，描述其相互關系，并以顧客要求

為輸入，提供給顧客的產品為輸出，通過信息反饋來測定的顧客滿意度，評價質量管理體系的業

績。

1、實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

原則5：管理的系統方法

針對設定的目標，識別、理解并管理一個由相互關連的過程所組成的體系，有助于提高組織

的有效性和效率。

IS0/DIS9000的3.3列出了建立和實施質量管理體系的十三個步驟：

1、實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

原則6：持續改進

持續改進是組織的一個永恒的目標。

1、實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

原則7：基于事實的決策方法

對數據和信息的邏輯分析或直覺判斷是有效決策的基礎。

以事實為依據做決策，可防止決策失誤。在對信息和資料做科學分析時，統計技術是最重要的工

具之一。統計技術可以用來測量、分析和說明產品和過程的變異性。統計技術可以為持續改進的決

策提供依據。

1、實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

原則8：互利的供方關系

通過互利的關系，增強組織及其供方創造價值的能力。

供方提供的產品將對組織向顧客提供滿意的產品可能產生重要的影響，一次處理好與供方的

關系，影響到組織能否持續穩定地提供顧客滿意地產品.對供方不能只講控制，不講合作互利.

特別對關鍵供方，更要建立互利關系。這對組織和供方雙方都是有利的。

1、實施本原則的主要利益

2、組織實施本原則時一般要采取的主要措施

3、本原則在標準中的體現

1.8.2十三個步驟

確定順容的需宓和井考J?那些提

期至是果的改進

建立組限的質量方

I為實做已確定的改進.

針和目標亞寸故降、過程和資源進

??劃

X.”

確定實?目標

所端的和職責

實施改進計劃

「對蚪不;施賣說肉

量目標的有效性確

需泛改講豺一里

「澈菌藏疥答…次

確定每個過程的現

行再減性

I-

對照預期結果.評價實

際結果

確定防止不合格并

消除產生原因的指

施

I評審改進活動，以確定

I適宜的后續措施

I_____________________

軟件質量保證是指為了保證軟件系統或軟件產品最大限度的滿足用戶要求而進行％有計

劃、有組織的活動，其目的是產生高質量的軟件。目前有多種軟件質量模型來描述軟件質量特性,

如IS0/IEC9126軟件質量模型、McCall軟件質量模型等。

1.8.3軟件質量特性

1.McCall軟件質量模型

可靠性完整性

2.Boehm質量模型

設笛獨立性I

用你n：7E-?hn

T禿區g

??JHUHH一致檔他壯n

軟件戒性

^TA^fXIV)\N

可計澗itt

乂＞1測試rt1返；《^絲閑

、量可存取性j

”物，戶竹II'通fjn

行修改性H.nSn

Qlt善蚪化性

1mn

m*性

可擴充性

3.ISO/IEC9126軟件質量模型

GB/T16260-2003軟件工程產品質量

1.8.4軟件質量管理

概念：軟件質量管理：指保證軟件滿足其目標要求所需要的過程，它包括編制質量計戈J、質

量控制、質量保證等過程。

質量控制：為了保證每件工作產品都滿足對它的需求而進行的一系列評審模型、檢查代碼和

測試活動。質量控制是整個制造過程的一部分，由開發團隊進行。

質量保證：為管理層提供能反映產品質量的數據，從而獲得產品質量是否符合預定目標的認

識和信心。質量保證是貫穿整個軟件過程的普適性活動，曰質保人員進行。

軟件質量管理體系

質量管理體系質量管理體系質量管理體系

要求業績改進指南審核綱要

技術評審

技術評審是軟件過程早期最有效的杳錯機制。

在軟件開發過程中的不同階段對需求分析模型、設計模型、源代碼和測試用例等過程工作產品進

行評審，能起到發現錯誤（進而消除）的作用。

輪查（郵件分發）走查

EmailPass-aroundWalkthrough

----------------------------------------------------r

tt

臨時評審互為復審會議審查

andom（同行評審）Inspection

Peer-to-peer

1.9軟件配置管理

軟件配件管理（SCMSoftwareConfigurationManagement）是IS09001和CMMLove12

中的重要組成元素，它在軟件產品開發的生命周期中，提供了結構化的、有序化