【正文】 　√　　　　　　　　　執(zhí)行效率　　√　　　　　　　　可擴充性　　　　　　　　　　√通用性　　　　　　√√√　√硬件獨立性　　　　　　√√　　　檢測性　　　√√√　　　　　模塊化　√　　√√√√√　√可操作性　　√　　　　　　√　安全性　　　√　　　　　　　自文檔化　　　　√√√√　　√簡單性　　　　√√　　　　√軟件系統(tǒng)獨立性　　　　　　√√　　　可追蹤性√　　　　　　　　　　易培訓(xùn)性　　　　　　　　　√　McCall等人提出的軟件質(zhì)量度量模型、軟件質(zhì)量要素和評價準則為軟件質(zhì)量管理奠定了基礎(chǔ)。軟件支持新用戶使用該系統(tǒng)的能力?？稍谲浖臋n之間實現(xiàn)正向/逆向的追蹤能力。程序與非標準的程序設(shè)計語言特征、操作系統(tǒng)特征以及其他環(huán)境約束無關(guān)的程度。理解程序的難易程度。源代碼提供有意義文檔的程度?？刂苹虮Ｗo程序和數(shù)據(jù)不受破壞的機制，以防止程序和數(shù)據(jù)受到意外的或蓄意的存取、使用、修改、毀壞或泄密。操作一個軟件的難易程度。劃分成邏輯上相對獨立的成分，具有良好的接口定義。監(jiān)視程序的運行，一旦發(fā)生錯誤，標識錯誤的程度。軟件同支持它運行的硬件系統(tǒng)不相關(guān)的程度。程序部件潛在應(yīng)用范圍的廣泛性。能夠?qū)Y(jié)構(gòu)設(shè)計、數(shù)據(jù)設(shè)計和過程設(shè)計進行擴充的程度。程序運行效率。系統(tǒng)在各種異常條件下提供繼續(xù)操作的能力。在程序中使用標準的數(shù)據(jù)結(jié)構(gòu)和類型。采用統(tǒng)一的概念、術(shù)語及符號，接口、規(guī)格說明等保持一致。程序源代碼的緊湊性。軟件不丟失各重要成分，完全實現(xiàn)系統(tǒng)所需功能。使用標準接口、協(xié)議和頻帶的程度。值越大表示精度越高。計算和控制的精度，是對無誤差程度的一種定量估計。檢查軟件需求、規(guī)格說明、標準、過程、指令、代碼及合同是否一致的難易程度。它們反映了軟件質(zhì)量的優(yōu)劣。定義評價準則的基礎(chǔ)是確定影響軟件質(zhì)量要素的屬性。例如，實時控制系統(tǒng)的可靠性、有效性是決定系統(tǒng)成敗的關(guān)鍵要素，必須全力保證，而軟件的可移植性、可重用性就不是主要的了；又如，設(shè)計通用的軟件工具對于可維護性、可移植性、可重用性應(yīng)該給予更多的注意，而有效性就不是影響系統(tǒng)成敗的關(guān)鍵要素了。各種軟件質(zhì)量要素之間的關(guān)系如表14－7所示。（6） 可互操作性。（5） 可測試性。圖14－6 McCall的軟件質(zhì)量要素（4） 靈活性。（3） 可用性。（2） 完整性。（1） 正確性。我們已介紹了軟件的可靠性、有效性、可維護性、可移植性和可重用性的概念。它們之間的關(guān)系如圖14－6所示。由于對軟件質(zhì)量理解的不斷深化，軟件質(zhì)量要素也不是一成不變的。例如，國際標準化組織（ISO）在1985年提出了軟件質(zhì)量度量（SQM）工作報告。隨后，用于定量地評價軟件質(zhì)量。1968年，Rubey和Hartwick提出了軟件某些屬性的度量方法。上述定義表明，軟件質(zhì)量依賴于軟件的內(nèi)部特征及組合。（3） 用戶對軟件產(chǎn)品的綜合反映程度。1983年，ADSI/IEEEstd729給出的軟件質(zhì)量定義是：軟件產(chǎn)品滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性，包括如下幾方面：（1） 軟件產(chǎn)品質(zhì)量滿足用戶要求的程度。因此，應(yīng)該對軟件質(zhì)量給出一個客觀的、科學(xué)的定義，并盡量予以量化。由于軟件開發(fā)人員、管理人員、維護人員和用戶在軟件開發(fā)、維護和使用過程中所處地位不同，他們對軟件質(zhì)量的理解和要求不同。大量軟件事故的慘痛教訓(xùn)時刻提醒人們千萬不能忽視軟件產(chǎn)品的質(zhì)量。軟件開發(fā)人員、維護人員、管理人員和用戶都十分重視軟件的質(zhì)量?；诠δ茳c和LOC度量已被發(fā)現(xiàn)是軟件開發(fā)工作量和成本的相對精確的判定，然而，為了將LOC和FP用于估算，必須建立歷史的信息基線。是否應(yīng)該將某個組的LOC/人月（或FP/人月）與另一個組的類似數(shù)據(jù)進行比較？管理者是否應(yīng)該根據(jù)這些度量來評價個人的表現(xiàn)？這些問題的答案毫無疑問是一個“不”字。 LOC和FP測量常常用于導(dǎo)出生產(chǎn)率度量。查看表可知，C++的一個LOC所提供的“功能性”（平均講）。很多研究試圖將FP和LOC測量聯(lián)系起來。CT的值按表14－5重新計算，F(xiàn)P的值可接原公式計算。算法定義為“特定計算機程序中所包含的一個界定的計算問題”。為了計算特征點，還要進行167。特征點度量適用于算法復(fù)雜性較高的應(yīng)用。為了解決這種情況，有學(xué)者提出了許多對功能點度量的擴展。為了適應(yīng)這類應(yīng)用，數(shù)據(jù)維（前面討論的信息域值）被強調(diào)而排除功能維及行為（控制）維。l 每人月完成的功能點（FP）數(shù)。l 每個功能點（FP）成本。一旦計算出功能點，則以類似LOC的方法來使用它們以規(guī)范化軟件生產(chǎn)率、質(zhì)量及其他屬性的測量：l 每個功能點（FP）的錯誤數(shù)。表14－3問題表問題Fi（1） 系統(tǒng)需要可靠的備份和恢復(fù)嗎？（2） 需要數(shù)據(jù)通信嗎？（3） 需要數(shù)據(jù)通信嗎？（4） 性能很關(guān)鍵嗎？（5） 系統(tǒng)是否在一個現(xiàn)存的、重負的操作環(huán)境中運行？（6） 系統(tǒng)需要聯(lián)機數(shù)據(jù)登錄？（7） 聯(lián)機數(shù)據(jù)登錄是是否需要在多屏幕或多操作之間切換以完成輸入？（8） 需要聯(lián)機更新文件嗎？（9） 輸入、輸出文件或查詢很復(fù)雜嗎？（10） 內(nèi)部處理復(fù)雜嗎？（11） 代碼需要被設(shè)計成可復(fù)用的嗎？（12） 設(shè)計中需要包括轉(zhuǎn)換及安裝嗎？（13） 系統(tǒng)的設(shè)計支持不同組織的多次安裝嗎？（14） 應(yīng)用的設(shè)計方便用戶修改和使用嗎？每個問題的回答是使用從0到5衡量的，具體見表14－4，復(fù)雜度調(diào)整值數(shù)值表。我們采用下面的關(guān)系式計算功能點（FP）：FP=總計數(shù)值CT*（+*∑Fi）其中“總計數(shù)值”是從圖143得到的所有FP條目的總和。采用功能點方法的組織建立一個標準以確定某個特定的條目是簡單的、平均的還是復(fù)雜的。計數(shù)所有機器可讀的接口（如存儲介質(zhì)上的數(shù)據(jù)文件），利用這些接口可以將信息從一個系統(tǒng)傳送到另一個系統(tǒng)。計數(shù)每個邏輯的主文件（即數(shù)據(jù)的一個邏輯組合，它可能是某個大型數(shù)據(jù)庫的一部分或是一個獨立的文件）。每一個不同的查詢都要計算。（3） 用戶查詢數(shù)。這里，輸出是指報表、屏幕、出錯消息，等等。（2）用戶輸出數(shù)。對每個用戶輸入進行計數(shù)，它們向軟件提供不同的面向應(yīng)用的數(shù)據(jù)。其中確定了五個信息域特征，并在表中合適的位置提供計算。由于該方法主要考慮程序的“功能性”和“實用性”，而不是對LOC計數(shù)，因而，在軟件設(shè)計初期就能夠估算出軟件項目的規(guī)模。因為“功能”不能直接測量，所以必須通過利用其他直接的測量來間接地導(dǎo)出。 面向功能的度量面向功能度量是由Albrecht于1979年首先提出來的，他建議一種稱為功能點的測量。在一個組織中，常用一個表格來記錄項目中面向規(guī)模的度量，如表14－1所示。每行代碼的平均成本C=S/LOC，即軟件每行代碼的平均成本，S用人民幣（或其它貨幣）進行表示。利用代碼行數(shù)不僅能度量軟件和規(guī)模，還可度量軟件開發(fā)的生成率、開發(fā)每行代碼的平均成本、文檔按代碼的比例關(guān)系、每千行代碼的軟件錯誤數(shù)等，采用代碼行數(shù)以LOC，常用千行代碼數(shù)K LOG（1 KLOG=103 LOC）來度量。 面向規(guī)模的度量面向規(guī)模軟件度量是通過規(guī)范化質(zhì)量和/或生產(chǎn)率的測量而得到的，這些測量是基于所產(chǎn)生的軟件的“規(guī)?！?。它們之間的關(guān)系如圖14－3所示圖14－3 軟件度量分類軟件生產(chǎn)率度量主要集中在軟件工程過程的輸出，軟件質(zhì)量度量可指明軟件滿足明確的和隱含的用戶需求的程度，技術(shù)度量主要集中在某些特征（如邏輯復(fù)雜性、模塊化程度）上，而不是軟件開發(fā)的全過程。建造軟件所需的成本和工作量、生產(chǎn)的代碼行數(shù)以及其他直接測量事相對容易收集到的，只要事先建立好測度的特定約定；然而，軟件的質(zhì)量和功能或其功效或可維護性是較難于評估的，只能間接測量。軟件度量也可以這樣分類。軟件外部屬性在軟件開發(fā)過程中很難測量和控制，但它是由軟件的內(nèi)部屬性決定的，因此有必要研究軟件的內(nèi)部屬性與外部屬性之間的關(guān)系，并通過軟件內(nèi)部屬性度量解決軟件某些外部屬性的度量問題，從而建立軟件工程度量系統(tǒng)。軟件工程的產(chǎn)品、過程資源都具有外部屬性和內(nèi)部屬性，外部屬性是面向管理者和用戶的屬性，體現(xiàn)了產(chǎn)品過程、資源與環(huán)境的關(guān)系，如成本、效益、程序員的生產(chǎn)率及軟件產(chǎn)品的可靠性、可用性、可維護性可移植性等。測度應(yīng)用于軟件過程，其目的是在一個連續(xù)的基礎(chǔ)上對它進行改進，即改進軟件過程；測度也可以用于整個軟件項目/產(chǎn)品中，輔助估算、質(zhì)量控制、生產(chǎn)率評估及項目控制。測度通過提供目標評價的機制從而使我們對目標做到更深的了解。 追蹤與控制 一旦適應(yīng)了項目開發(fā)計劃，就可以開始進行項目追蹤和項目控制，一旦項目出現(xiàn)進度/資源等變化，就需要對項目計劃進行調(diào)整以利于更好地完成項目，最壞情況可以對項目的交付日期進行修改。 5) 定義的結(jié)果 每個任務(wù)都應(yīng)有一個目標，軟件項目的目標通常是一個工作產(chǎn)品（如一個模塊的設(shè)計）或某個工作產(chǎn)品的一部分，通常將多個工作產(chǎn)品組合成“可交付產(chǎn)品”。 3) 時間分配 為每個任務(wù)確定其一定數(shù)量的工作時間，并需指定開始時間和結(jié)束時間。進度安排的原則為： 1) 任務(wù)劃分及定義 將項目劃分為子項目、任務(wù)、活動等可以管理的部分。這些步驟貫徹于軟件工程過程中。 風(fēng)險分析 現(xiàn)代項目管理的優(yōu)勢在于引進了風(fēng)險分析技術(shù)，由于當(dāng)前許多項目不進行風(fēng)險分析就進行開發(fā)，就存在了較大的項目風(fēng)險，每當(dāng)在進行一個軟件項目開發(fā)時，其人員、經(jīng)費、進度及用戶需求均存在著不確定的因素，如建立的軟件系統(tǒng)，其用戶需求是否確切地被理解，是否還存在有技術(shù)難題。 3) 項目在估算時可分解為可估算的小塊。 項目估算 在軟件項目管理過程中的關(guān)鍵活動就是制定項目計劃，而在做項目計劃時就需要對項目所需的人力（以人月為單位）、項目持續(xù)時間（以年份或月份為單位）、成本（以元為單位）進行估算?？晒芾淼倪M度安排從而，可在多個方案中選擇一個相對完善的方法，給出諸如交付期限、預(yù)算、個人能力、技術(shù)界面及其它許多因素構(gòu)成的限制。合理、精確的成本分析1）啟動軟件項目2）軟件度量3）軟件項目估算4）風(fēng)險分析5）進度安排6）項目組織7）軟件配置管理 啟動一個軟件項目在軟件項目啟動前，必須對該項目進行可行性分析，其中需明確項目的目標和范圍，并在此基礎(chǔ)上考慮候選的解決方案，估計新系統(tǒng)可能的開發(fā)和運行成本及其效益，同時給出該項目在技術(shù)和管理上的要求，在此基礎(chǔ)上，相關(guān)人員可確定。關(guān)鍵的問題要對軟件項目范圍，各階段/活動中可能存在的風(fēng)險，需要和資源（包括人、軟/硬件及其它資源），要實現(xiàn)的任務(wù)、經(jīng)歷的里程碑，花費的工作量及成本，進度安排等進行計劃及控制。圖14－2給出了一個軟件項目管理和通用方法。評估計劃的和實際的進度，收集和分析軟件項目度量，從項目組成員和客戶處獲取反饋，并記錄下所有發(fā)現(xiàn)。5） 進行事后的分析。本質(zhì)上，項目管理者和軟件小組的決策應(yīng)該是“保持其簡單”。此外，軟件過程和項目測度可以被收集并根據(jù)軟件開發(fā)組織的平均數(shù)據(jù)用于評估進展。3） 跟蹤進展。很多項目的啟動有一個很好的開始，但是，慢慢地開始瓦解。然后又通過建立合適的開發(fā)小組并給予小組完成工作所需的自主權(quán)、權(quán)力和技術(shù)而增強。管理者如何避免上述的問題呢？可采用以下的軟件項目方法：1） 在正確的基礎(chǔ)上開始工作。9） 項目組缺乏具有合適技能的人員。7） 用戶抵制。5） 業(yè)務(wù)需求發(fā)生變化（或未被很好地定義）。3） 沒有很好地管理變化。有如下10個信號指示一個信息系統(tǒng)項目正處于危險狀態(tài)之中：1） 軟件人員不了解他們的客戶的需要。為了避免項目失敗，軟件項目的管理者和建造產(chǎn)品的工程師必須避免一些常見的警告信號，了解關(guān)鍵的項目管理的成功因素，并采用開發(fā)計劃、監(jiān)控和控制項目的常用性方法。兩個項目都執(zhí)行了我們稱之為客戶通信的框架活動，但第一個項目組只執(zhí)行了第二個項目組一半的軟件工程工作任務(wù)。9） 和所有相關(guān)人員一起評審范圍文檔。7） 評審每一份小規(guī)約，確認其正確性、一致性和無二義性。5） 召開會議。3） 研究如何刻畫推薦的解決方案和已有的方法。這樣一個項目在客戶交流活動中可能需要下列工作任務(wù)：1） 評審客戶要求。它們代表了適于小型的、相對簡單的項目的一種過程分解。5） 根據(jù)需要修改范圍陳述。3） 共同給出范圍陳述。當(dāng)項目管理者問到下面的問題時過程分解就開始了：“我們?nèi)绾瓮瓿蛇@個CPF活動？”例如，一個小型的、相對簡單的項目在客戶交流活動中可能需要下列工作任務(wù)：1） 列出需澄清問題的清單。CPF是不變的，它充當(dāng)一個軟件組織所執(zhí)行的所有軟件工作的基礎(chǔ)。在每一種情形，本章前面所討論的CPF——客戶交流、計劃、風(fēng)險分析、工程、構(gòu)造及發(fā)布、客戶評估——均可以被適合于該范型。類似地，具有其他特性（如不確定的需求、突破性的技術(shù)、困難的客戶、明顯的復(fù)用潛力等）的項目將導(dǎo)致選擇其他過程模型。如果時間要求很緊且問題能夠被很好地劃分，原型實現(xiàn)模型可能是正確的選擇。公共過程框架活動軟件工程任務(wù)產(chǎn)品功能正文輸入編輯及格式設(shè)計自動復(fù)制編輯頁面布局能力自動建立索引及目錄文件管理文檔生成圖141 合并產(chǎn)品和過程 過程分解軟件項目組在選擇最適合項目的軟件工程范型以及選定的過程模型中所包含的軟件工程任務(wù)時，應(yīng)該有很大的靈活度。軟件工程工作任務(wù)（對于每一個框架活動）列在緊接著的行中。實質(zhì)上，產(chǎn)生了一個類似圖141所示的矩