1. 敏捷核心價值觀
2001年2月，17位著名軟件專家聯合起草了敏捷軟件開發宣言，標誌著“敏捷流派”的誕生。這份宣言由4個核心價值觀組成。
（1） “個體交互”勝過“過程和工具”
人是軟件項目獲得成功最為重要的因素，當然，不好的過程和工具也可以使最優秀的團隊成員失去效用。團隊成員的合作、溝通以及交互能力要比單純的軟件編程能力更為重要；合適的工具對於成功來說也非常重要，但工具的作用不可被過分地誇大。敏捷過程強調：團隊的構建(包括個體、交互等)要比項目環境(包括過程、工具)的構建重要得多，應該首先致力於構建團隊，然後再讓團隊基於需要來配置環境。
（2） “可以使用的軟件”勝過“麵麵俱到的文檔”
軟件開發最終交付給用戶可以工作的軟件而不是文檔，否則應該稱之為文檔開發而不是軟件開發。沒有文檔的軟件是一種災難，但過多的麵麵俱到的文檔比過少的文檔更糟。敏捷過程強調：軟件開發的主要和中心活動是創建可以工作的軟件，僅當有迫切需要並且具有重大意義時，才進行文檔編製，且編製的內部文檔應盡量短小並且主題突出。
（3） “客戶合作”勝過“合同談判”
客戶不可能做到一次性地將他們的需求完整清晰地表述在合同當中，在開發過程中甚至交付後，客戶需求還可能隨時發生變化。敏捷過程強調，開發團隊與客戶緊密協作，全方位地滿足客戶需求，為開發團隊和客戶的協同工作方式提供指導的合同才是最好的合同。
（4） “響應變化”勝過“遵循計劃”
軟件開發過程總會有變化，這是客觀存在的現實。一個軟件過程必須反映現實，因此，軟件過程應該有足夠的能力及時響應變化。敏捷過程強調，項目計劃必須有足夠的靈活性和可塑性，在形勢發生變化時能迅速調整，以適應業務、技術等方麵的變化。
為了貫徹上述4個價值觀，敏捷宣言還提出有別於傳統過程的12個原則。
●優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。
●即使到了開發的後期，也歡迎改變需求，敏捷過程利用變化來為客戶創造競爭優勢。
●經常性交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
●在整個項目開發期間，業務人員和開發人員應該每天都工作在一起。
●使用積極的開發人員進行項目，給他們提供所需的環境和支持，並且信任他們能夠完成工作。
●在團隊內部，最具有效果並且富有效率的傳遞信息的方法，是麵對麵的交談。
●能工作的軟件是首要的進度度量標準。
●敏捷過程提倡可持續的開發速度，投資人、開發人員和用戶應該能夠保持一個長期穩定的步調。
●不斷地關注優秀設計的技能和好的設計會增強敏捷能力。
●簡單（盡可能減少工作量）是最重要的。
●最好的架構、需求和設計都來自於自組織的團隊。
●團隊要定期總結如何提高效率，然後相應地調整自己的行為。
2. 極限編程
在敏捷的所有方法中，極限編程（eXtreme Programming，XP）是最負盛名的一個，其名稱中“極限”二字的含義是指把好的開發實踐運用到極致，它消除了大多數重量型過程中過於繁瑣和僵化的內容，建立了一個漸進的開發過程，使軟件能以盡可能快的速度開發出來，向客戶提供最高的效益。目前，極限編程已經成為一個典型的開發方法，廣泛應用於需求模糊且經常改變的場合。
圖212描述了極限編程的整體開發過程。首先，項目組針對客戶代表提出的“用戶故事”（用戶故事類似於功能用例，但比用例更簡單，僅描述功能需求）進行討論，提出隱喻，在此項活動中可能需要對體係結構進行“試探”，即提出相關技術難點的試探性解決方案；然後，項目組在隱喻和用戶故事的基礎上，根據客戶的要求，設定優先級，製定交付計劃，這一過程中為保證交付計劃的可行性，需要對某些技術難點進行試探；接下來開始多個迭代開發過程，根據交付計劃製定每次的迭代計劃，以結對編程的方式完成每次迭代開發任務，通過“站立會議”解決遇到的問題、調整迭代計劃等；最後將開發出的軟件經過驗收測試後交付用戶使用。
圖212極限編程的整體開發過程
極限編程在很多方麵都和傳統意義上的軟件過程不同，具體執行時，它有12個有效的開發實踐，隻有完全引用了以下12個實踐，才是真正使用了極限編程，隻引用部分並不代表使用了極限編程。下麵簡述極限編程的12個開發實踐。
（1） 完整的團隊
所有的小組成員應在同一個工作地點工作，成員中必須有一個現場用戶，由他提出需求，確定開發優先級，通常還設一個“教練”角色，教練指導極限編程方法的實施，以及與外部的溝通和協調。
（2） 滾動計劃
計劃是持續的、循序漸進的。一般每隔兩周，開發人員就為下一個兩周修訂滾動計劃。開發人員針對一些候選特性估算成本，客戶則根據成本和應用價值來選擇要求實現的特性，最終形成下一個兩周計劃。
（3） 客戶測試
針對每個所期望的特性，按客戶的要求使用腳本語言，定義出驗收測試方案，以通過驗收測試來表明該特性可以工作。
（4） 簡單設計
保持設計內容恰好和當前的係統功能相匹配，並能通過所有的測試，不包含任何重複，能表達出編寫者想表達的所有東西，並且包含盡可能少的代碼，避免過度設計。
（5） 結對編程
所有的產品軟件都是由兩個程序員，並排坐在一起在同一台機器上構建。
（6） 測試驅動
在實施設計和編程之前，先擬定一個測試目標，然後以通過測試作為設計和編碼的目標，通過之後再考慮重構和優化。
（7） 改進設計
隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的幹淨、具有表達力。
（8） 持續集成
總是使係統完整地被集成。
（9） 代碼集體所有
任何結對的程序員都可以在任何時候改進任何代碼，沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其他方麵的開發。
（10） 編碼標準
係統開發人員遵守共同的編碼標準，代碼看起來就好像是被單獨一人編寫的。
（11） 隱喻
隱喻是整個係統的全局視圖，它是係統的未來影像，它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那麼就知道該模塊是錯誤的。
（12） 可持續的開發速度
隻有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，把項目看作是馬拉鬆長跑，而不是全速短跑。
2.4軟件過程改進與CMM
CMM（Capability Maturity Model：能力成熟度模型）是1984年美國國會與美國主要的公司和研究中心合作創立的一個由聯邦資助的非營利組織——軟件工程研究所（Software Engineering Institute,SEI，設立在卡內基梅隆大學）的一個早期研究成果，用於評價軟件機構的軟件過程能力成熟度的模型，所以在當時它被稱為軟件過程成熟度模型。
多年來，軟件開發項目不能按期完成，軟件產品的質量不能令客戶滿意，再加上軟件開發成本經常超出預算，這些是許多軟件開發組織都遇到過的難題。不少人試圖通過采用新的軟件開發技術來解決在軟件生產率和軟件質量等方麵存在的問題，但效果並不令人十分滿意。很多事實表明沒有一個規範化的管理，先進的技術和工具並不能發揮應有的作用，於是人們認識到，必須要重視對軟件過程的管理。CMM的基本思想就是幫助軟件開發組織建立一個有規律的、成熟的軟件過程，使其能開發出質量更好的軟件，使更多的軟件項目免受時間和費用超支之苦。圖213CMM框架（5級模型）
1. CMM的框架
由於對軟件過程的改進不可能在一夜之間完成，每個成功的改進需要一個從幼稚走向成熟的蛻變過程。CMM為軟件開發組織的過程能力提供了一個階梯式的進化框架，如圖213所示，共有5級。第一級是一個起點，任何軟件組織都處於這個起點，並由該起點向第二級邁進。除第一級外，其他每一級都設定一組目標，達到了這個目標，則表明軟件組織達到了這個能力成熟度等級，可以向下一個級別邁進。
這5個等級是層層遞進的關係，第一級等級最低，第五級等級最高，達到高級別的一定能達到低級別的要求。如滿足第三級的要求，就一定能滿足第一級和第二級的要求。
2. 能力成熟度等級
CMM將軟件過程的成熟度分為5個等級，從低到高依次是：初始級、可重複級、已定義級、已管理級和優化級。這5個等級定義了一個有序的尺度，用以測量軟件組織的軟件過程成熟度和評價其軟件過程能力，還能幫助軟件組織把應做的改進工作排出優先次序。下麵介紹能力成熟度的這5個等級。
（1） 初始級
軟件過程的特點是無秩序的，甚至是混亂的。幾乎沒有什麼過程是經過妥善定義的，成功往往依賴於個人或小組的努力。
處於這個等級的軟件組織，基本上沒有健全的軟件工程管理製度。如果一個項目碰巧由一個有能力的管理員和一個優秀的軟件開發組承擔，則這個項目成功的可能性較大。但通常的情況是，由於缺乏健全的總體管理和詳細計劃，延期交付和費用超支的情況經常發生。管理方式屬於反應式，主要用來應付危機，而不是執行事先計劃好的任務，軟件過程完全取決於當前的人員配備，開發結果不可預測。
（2） 可重複級
建立了基本的項目管理過程來跟蹤成本、進度和功能特性。製定了必要的過程紀律，能重複早先類似應用項目取得的成功。
這一級，有些基本的軟件項目管理行為、設計和管理技術，是基於相似產品中的經驗確定的，因此稱為“可重複”。這一級采取了一些措施，如仔細地跟蹤費用和進度，方便管理人員在問題出現時可及時發現，並立即采取補救行動，不像初始級那樣處於危機狀態下才采取行動。
（3） 已定義級
已將管理和工程活動兩方麵的軟件過程文檔化、標準化，並綜合成該機構的標準軟件過程。所有項目均使用經批準、剪裁的標準軟件過程來開發和維護軟件。
在這一級，已經為軟件過程編製了完整的文檔。對軟件過程的管理方麵和技術方麵都明確地作了定義，並按需要不斷地改進軟件過程。已經采用評審的辦法來保證軟件的質量，也采用一些計算機輔助工具和環境提高軟件質量和生產率。
（4） 已管理級
收集對軟件過程和產品質量的詳細度量值，對軟件過程和產品都有定量的理解和控製。
處於這一級的軟件組織已經能夠為每個項目設定質量和生產目標，並不斷地測量這兩個量，當偏離目標太多時，就采取行動來修正。管理級是可度量、可預測的軟件過程。
（5） 優化級
整個組織關注軟件過程改進的持續性、預見及增強自身，防止缺陷及問題的發生。過程的量化反饋和先進的新思想、新技術促使過程不斷改進。
處於這一級的軟件組織的目標是持續地改進軟件過程。這樣的組織使用統計質量和過程控製技術。從各個方麵獲得的知識將運用在未來的項目中，從而使軟件過程進入良性循環，使生產率和質量穩步提高。
綜合以上內容，可以得出以下結論。初始級是混沌不清的過程；可重複級是經過訓練的軟件過程；已定義級是標準一致的軟件過程；已管理級是可預測的軟件過程；優化級是能持續改善的軟件過程。為幫助理解這5個等級，可以拿食物進化過程作類比，最早我們的祖先對於食物是沒有概念的，抓到什麼就吃什麼，這就好比“初始級”；後來，經過很多次的經驗積累，發現有些東西不能隨便亂吃，如鮮豔的蘑菇誤食後會腹瀉甚至死亡，因此會給自己製定一些過程紀律，這就好比“可重複級”；再到後麵，發展到每天固定三餐製，不是什麼時候餓就什麼時候吃，應該說有了一定的標準，這就好比“已定義級”；再往後，在一日三餐的基礎上進一步量化，為保證膳食結構的合理性，為每一頓製定具體的葷素比例，這就好比“已管理級”；到了今天，人們開始關注食物對未來自身健康的潛在影響，開始提倡綠色食品、有機食品等，強調持續地優化改進，這就好比“優化級”。
3. 關鍵過程域
CMM並不詳細描述所有與軟件開發和維護相關的過程，但是，有一些過程是決定過程能力的關鍵因素，這就是CMM所說的“關鍵過程域”（Key Process Area，KPA）。在CMM中，每個能力成熟度等級（第一級除外）規定了不同的關鍵過程域，一個軟件組織如果希望達到某一個能力成熟度級別，就必須完全滿足此級別關鍵過程域所規定的要求，即滿足關鍵過程域的目標。
在CMM中一共有18個關鍵過程域，分布在第二至第五級中，如圖214所示。需要提醒的是：關鍵過程域是累加的，每一個級別的關鍵過程域包含本級框中的描述以及下級所有框中的描述。
圖214CMM關鍵過程域
2.5本章小結
本章的內容圍繞軟件過程展開，首先是軟件過程的概述，包括軟件過程的定義、軟件過程所包含的生命周期階段以及軟件過程與軟件工程間的關係；其次是對軟件過程模型的介紹，包括瀑布模型、快速原型模型、增量模型、螺旋模型和噴泉模型；然後介紹了軟件過程的新發展，這裏重點敘述了兩種新過程模型，即統一過程模型和敏捷過程模型；最後介紹了軟件過程能力成熟度模型。
習題
一、 單選題
1 瀑布模型是（）。
A. 適用於需求被清晰定義的情況B. 一種需要快速構造可運行程序的好方法
C. 一種不適用於商業產品的創新模型D. 目前業界最流行的過程模型
2 增量模型是（）。
A. 適用於需求被清晰定義的情況B. 一種需要快速構造核心產品的好方法
C. 一種不適用於商業產品的創新模型D. 已不能用於現代環境的過時模型
3 原型化模型是（）。
A. 適用於客戶需求被明確定義的情況
B. 適用於客戶需求難以清楚定義的情況
C. 提供一個精確表述的形式化規格說明
D. 很難產生有意義產品的一種冒險模型
4 下麵的（）不是敏捷開發方法的特點。
A. 軟件開發應該遵循嚴格受控的過程和詳細的項目規劃
B. 客戶應該和開發團隊在一起密切地工作
C. 通過高度迭代和增量式的軟件開發過程響應變化
D. 通過頻繁地提供可以工作的軟件來搜集人們對產品的反饋
5 包含風險分析的軟件過程模型是（）。
A. 瀑布模型B. 螺旋模型
C. 增量模型D. 噴泉模型
6 軟件過程是（）。
A. 特定的開發模型B. 一種軟件求解的計算邏輯
C. 軟件開發活動的集合D. 軟件生命周期模型
7 CMM模型將軟件過程的能力成熟度分為5個等級，在（）使用定量分析來不斷改進和管理軟件過程。
A. 已管理級B. 優化級
C. 已定義級D. 可重複級
8 瀑布模型把軟件生命周期劃分為軟件定義、軟件開發和（）三個時期，而每一時期又可細分為若幹個更小的階段。
A. 詳細設計B. 運行和維護
C. 可行性分析D. 編程與測試
9 一種以用戶為動力，以對象作為驅動的模型，適用於麵向對象的開發方法的模型是（）。
A. 增量模型B. 螺旋模型
C. 噴泉模型D. 智能模型
10 軟件開發的需求分析階段的主要任務是（）。
A. 獲得係統完整的功能及性能要求B. 獲得係統的邏輯解決方案
C. 明確係統的邊界D. 對係統能否進行下去做出決策
二、 簡答題
1 對比瀑布模型、快速原型模型、增量模型和螺旋模型。
2 RUP包含哪些核心工作流和哪些核心支持工作流？
3 XP是一種什麼樣的模型？
4 請簡述軟件過程。
5 請簡述CMM的作用。
6 請簡述CMM軟件過程成熟度的5個級別，以及每個級別對應的標準。
7 請簡述軟件過程與軟件工程的關係。
8 什麼是軟件生命周期？
9 軟件生命周期包含哪8個階段？
【微信掃碼】
本章參考答案&相關資源
第3章軟件項目管理第3章軟件項目管理
軟件開發是一種組織良好、管理嚴格、各類人員協同配合、共同完成的工程項目。從學科上來說，曆史上出現的“軟件危機”促使了軟件工程這門學科的誕生。軟件工程這門學科既從技術方麵又從管理方麵研究如何更好地開發和維護計算機軟件。從實踐上來說，軟件項目的成功率很低，不成功的軟件項目案例比比皆是。在經曆了許多大型軟件工程項目的失敗之後，人們才認識到軟件項目管理的重要性。事實上，這些項目的失敗並不隻有技術上的原因，更多地還有管理上的原因。軟件項目管理能夠顯著提高軟件項目成功率。著名的軟件工程基本原理強調了軟件項目管理的重要性，要求用分階段的生命周期計劃嚴格管理、堅持進行階段評審、實行嚴格的產品控製、結果應能清楚地審查。
美國的項目管理協會（Project Management Institute，PMI）認為項目是在一段時間內，為了創造某種獨特的產品或者服務而采取的一種努力。而軟件項目是由一個任務集合（包括軟件工程工作任務、裏程碑和交付的產品）組成的工程，按照項目管理的一般方式進行定義、開發和維護軟件。軟件項目具有開發進度和質量很難估計和度量、生產效率難以預測和保證、項目周期長、複雜度高，需求可能經常變化、不確定性因素多等特點。因此，為了實現軟件項目的成功，將項目管理的思想引入到軟件工程領域，就形成了軟件項目管理。軟件項目管理是項目管理中一個特殊領域，它是以軟件工程項目為管理對象，涉及的範圍覆蓋了整個軟件工程過程。它運用相關的知識、技術和工具，對人員、產品、過程和項目進行分析和管理的活動，以使軟件項目能夠按照預定的成本、進度、質量按期完成。軟件項目管理主要包括人員組織與管理、軟件項目計劃、軟件度量、軟件配置管理、軟件質量保證、軟件過程能力評估、風險管理等。
3.1人員管理和團隊協作
軟件開發是對智力創造要求較高的一項工作，相對於工具或技術來說，軟件人員的素質和組織管理是保證軟件項目成功的更為重要的因素。如何充分發揮員工的聰明才智，對於項目的成敗起著至關重要的作用。美國卡內基梅隆大學的軟件工程研究所開發了人員管理能力成熟度模型(PCCMM)。開發這個模型的目的在於通過對人員的管理，提高軟件組織承擔日益複雜的軟件開發能力。
多數軟件的規模很大，單個軟件開發人員無法在給定的期限內完成開發工作，因此，必須把多名軟件開發人員合理地組成項目團隊，使他們有效的分工協作共同完成開發項目工作。項目團隊由承擔不同角色與職責的人員組成，項目團隊成員可能具備不同的技能，可能是全職也可能是兼職的，團隊人數可能隨項目進展而增加或減少。人員的組織管理是否得當，也是影響軟件開發項目質量的決定因素。
在微軟公司的成功經驗中，最值得研究的就是如何得到優秀的員工，以及如何讓員工發揮自己的能力。因此，軟件開發的管理應處處體現“以人為本”的思想，注重發現和培養有創造力的、技術水平高的人員，並使這些人員保持高昂的鬥誌和不斷的創新。
3.1.1參與項目的人員
參與軟件過程的人員可以分為以下五類，見表31所示。表31參與項目的人員
人員類別職責 高級管理者確定項目做還是不做，確定業務問題，這些問題往往對項目產生很大影響。項目經理負責計劃、激勵、組織、控製軟件開發人員。開發人員負責開發一個軟件產品或服務的技術。客戶負責說明待開發軟件需求。最終用戶軟件發布成為產品後直接與軟件進行交互。每個軟件項目都有上述人員的參與，在開發移動APP和WebApp時，其內容創作方麵還需要其他非技術人員的參與。為了獲得高效率，軟件項目團隊必須以能夠發揮每個人的技術和能力的方式進行組織，這是項目經理的任務。
3.1.2項目經理
1. 對項目經理的技能要求
（1） 項目管理知識與技能。項目經理需要製訂項目計劃、控製項目成本、確保項目質量，需要具備項目管理專業知識。
（2） 人際關係技能。這是項目經理麵臨的最大挑戰，項目經理對上需要彙報進展，對下需要向項目成員分配任務，對外要與客戶溝通，需要具備良好的人際關係技能。
（3） 情境領導技能。項目經理需要不斷激勵項目員工。管理因人而異，需要針對項目組中不同成員的不同需求，在不同情境下因需而變。
（4） 談判與溝通的技能。無論是與客戶還是與員工相處，項目經理大部分的時間都在談判和溝通。
（5） 客戶關係與谘詢技能。項目經理不僅具備技術能力，而且需要與客戶交流，根據客戶需求，為客戶量身定做項目方案。
（6） 商業頭腦和財務技能。企業目標是通過項目管理實現的，項目經理需要把項目放在整個企業戰略中考慮，項目經理需要了解項目的投資回收期，純收入等財務指標。
（7） 解決問題技能。項目經理能夠製定解決方案，能夠把從過去項目中學到的經驗應用到新環境中。如果最初的方案沒有解決問題，能夠靈活地改變方向。
(8) 新技能。很多項目以前都沒有遇到過，這往往需要項目經理具備創新能力。
(9) 團隊建設技能。有計劃有組織地增強團隊成員之間的溝通交流，增進彼此的了解與信賴，在工作中分工合作更為默契，對團隊目標認同更統一明確，完成團隊工作更為高效快捷，圍繞這一目標所從事的所有工作都稱為團隊建設。
2. 履行的職責
項目經理是項目的主要負責人，對項目全權管理，項目經理的職責主要有以下幾個方麵：
（1） 審核軟件項目的立項文檔。
（2） 細化軟件開發計劃，實施任務分配。
（3） 結合用戶需求報告完善項目計劃。
（4） 配合係統設計師完成係統設計。
（5） 組織程序員編寫代碼與調試。
（6） 組織項目成員編寫相關手冊。
（7） 完成項目報告的總結工作。
3.1.3團隊協作
團隊是由若幹個成員組成的一個群體，他們具有互補的技能，對一個共同目的、績效目標及方法做出承擔並彼此負責。團隊並不是簡單地把一組人聚集在一起。例如，足球隊、樂隊，這些團隊的特點是：設定具有挑戰性的團隊目標，具有一致的具體目標；營造一種支持性的環境（溝通交流，團隊學習），讓每一個位成員的才能與角色匹配；團隊成員有自豪感；相互依賴相互協作共同完成任務。
一個軟件項目的好壞很大程度上體現在軟件項目團隊的建設和管理上。團隊的組織和管理主要包括人員規劃、項目團隊組建、項目團隊建設和項目團隊管理四個方麵。首先要識別和記錄項目角色、職責、所需技能，並編製人員需求規劃。然後根據項目人員需求規劃，通過有效手段獲得項目所需人員，組建項目團隊。通過一些活動，提高團隊的個人工作能力，促進團隊互動和改善團隊氛圍，增強團隊成員之間的信任感和凝聚力，從而保證更好的協作和更高的效率以提高項目業績。
3.1.4人員分工
軟件開發過程涉及各種活動，例如需求定義和分析、係統設計、程序設計、編碼、測試等，每個開發人員擅長軟件開發的某個方麵，所以整個開發需要多種不同角色的分工協作。係統分析員的主要工作是獲取和定義係統的需求，在係統分析的基礎上，係統設計人員(係統架構師)與係統分析員一起工作，確定係統的整體結構；設計與實現階段，設計人員與編程人員一起完成代碼編寫工作；測試階段，程序員負責單元測試，測試人員負責集成測試和係統測試；在係統交付階段，培訓人員負責係統培訓工作；係統交付使用後，就會進入係統維護階段。各種角色開發人員將參與係統缺陷修複和新功能開發。一般軟件開發過程中各類人員分工如表32所示。表32軟件開發過程中各類人員分工
需求定義和分析係統設計程序設計編程實現單元測試集成測試係統測試係統交付維護係統分析員係統分析員，係統架構師程序員，係統架構師高級程序員和初級程序員程序員，測試人員測試人員測試人員培訓人員各類人員在項目初期，首先要做好項目人員規劃，例如表33顯示了某個項目的人員需求計劃。人員需求規劃包括人員類型、人員數量、到位時間要求、退出時間安排、技能要求及獲取方式等。製定了人員需求計劃之後，就開始選擇或獲得團隊成員。表33人員需求計劃
序號人員類型數量到位時
間要求退出時
間安排技能要求獲取方式1需求分析22014.12014.61. 熟悉銀行業務
2. 熟悉公司的研發業務流程外部招
聘1人2架構設計師12014.12014.61. 熟悉架構設計部門協調3設計人員52014.12014.61. 熟悉JAVA 語言
2. 熟悉UML設計工具部門協調4高級程序員22014.32014.10初級程序員82014.42014.111. 熟悉Oracle數據庫，熟悉Oracle包和存儲過程的使用，熟練掌握常用的PL\/SQL語法和語句
2. 熟悉UML基礎知識，能夠根據設計人員的設計模型進行編碼
3. 掌握麵向對象基礎知識，對麵向對象設計有一定程度的理解外協2人5測試人員32014.32014.10熟悉銀行業務，具備測試基礎知識部門協調軟件開發各階段需要的人員數量是不同的。通常在項目的初期需要的人員並不多，但其業務水平和技術要高，在項目的中後期需要較多的人員參與，其中大多是一些有專門技術的人員（如編程和測試）。在項目臨近結束時候，隻需要少量人員參與即可。
如果一個軟件項目從開始到結束都保持一個恒定的人員數量，那麼就會出現初期人員的浪費和中後期人員的不足，導致要額外增加人員，甚至導致整個進度的延遲。圖31描述了恒定人員數量導致的問題。
圖31恒定人員數量導致的問題
案例描述：假如開發網上銀行係統的公司項目經理，希望利用Internet，幫助銀行通過Internet向客戶提供開戶、銷戶、查詢、對賬、行內轉賬、跨行轉賬、信貸、網上證券、投資理財等傳統服務項目，使客戶可以足不出戶就能夠安全便捷地管理活期和定期存款、支票、信用卡及個人投資等。你需要組建一個開發團隊，基於公司現有的技術開發一個新產品。
顯然，人員管理的首要任務是從公司內部或者外部選擇合適的團隊成員，如何選擇團隊成員及選擇的標準是需要重點考慮。由於這個係統是為銀行和銀行客戶服務的，所以需求分析人員必須熟悉銀行業務，善於和銀行管理人員溝通；同時，這個產品基於Web技術，所以開發人員中要有人對Web技術熟悉和相關項目的軟件開發經驗。
3.1.5項目團隊組建
建立一支優秀的開發團隊，首先要選擇合適的人，要避免選擇了合格但不合適的人。選擇合適的成員主要考慮技術因素和非技術因素兩大類。技術因素包括教育背景、應用領域經驗、平台經驗、編輯語言經驗、解決問題的能力。非技術因素包括溝通能力、適用性、工作態度、個性和興趣等。除技術條件之外，候選人的工作態度、性格和能力是非常關鍵的因素。解決技術難題的能力至關重要，通常會被優先考慮，較強的解決問題能力或許可以彌補其他方麵的不足。由於項目成員要經常和其他人員、管理者、客戶進行口頭和書麵的交流，所以溝通能力是一個必須要考察的因素。適用性可以從候選人的各種經曆中進行判斷，這個因素可以反映一個人的學習能力。項目人員要有積極的工作態度，樂於學習新技術。由於軟件開發需要團隊的協作，所以候選人必須與團隊成員關係融洽。工作態度和個性這兩個因素很重要，但是較難評估。
在組建項目團隊的時候，不僅要了解不同類型的人員性格特征是不同的，而且應該考慮團隊中的技術、經驗和個性是否整體均衡，選擇性格互補的成員組成的團隊可能比僅僅根據技術能力選擇成員的團隊更有效率。例如，西遊記西天取經的項目中，缺少唐僧，這個團隊有可能成為烏合之眾，不會有什麼遠大的前程；缺了孫悟空，很難想象這個團隊是如何艱難前行的，唐僧的遠大抱負很可能會化為烏有；少了八戒，這個團隊就會顯得枯燥無趣；沒有沙僧，許多事務性的工作就沒有人去做，團隊的核心和穩定就存在一定的問題。因此，團隊成員之間互為補充，缺一不可。
3.1.6團隊組織模式
不同的團隊組織方式會影響團隊的決定、信息交換的方式以及開發小組和小組外的信息交流。圖32民主式結構
1. 民主式結構
如圖32所示的民主式結構中，團隊成員完全平等，享有充分民主，成員之間通過協商做出決定，名義上的組長與其他成員沒有任何區別。項目工作由全體討論協商決定，並根據每個人的能力和經驗分配。這種模式特別適合於規模小、能力強、習慣於共同工作的軟件開發組。優點是有高度的凝聚力，同等的項目參與權,能夠互相學習，可以激發大家的創造力，有利於攻克技術難關。但這種結構缺乏明確的權威領導，很難處理意見分歧的情況，在組內多數成員技術水平不高或者缺乏經驗的情況下，不適合采用。
2. 主程序員式結構
這種結構主要是出於以下幾點考慮：
●多數開發成員是缺乏經驗的。
●軟件開發中還有許多事務性的工作。
●多渠道通信費時間，降低程序員的生產率。
《人月神話》一書中提到了主程序員式的結構，主程序員式的組織結構如圖33所示。
圖33主程序員式結構
這種結構以主程序員為核心，主程序員既是項目管理者也是技術負責人，對團體其他成員的職能進行專業化分工。借鑒外科手術隊伍組織結構，主程序員就像是主刀醫生，負責所有開發決策，完成主要模塊的設計和實現工作，並指導其他程序員完成詳細設計和編碼工作。後備程序員作為替補，在必要時，可以替代主程序員。後備程序員應對項目有深入的了解，在開發過程中主要工作是設計測試方案、分析測試結果以及獨立於設計過程的其他工作。其他程序員完成主程序員分配的任務。秘書負責事務性工作，例如維護項目資料庫、項目文檔並進行初步的測試工作。在這種模式中，強調主程序員的領導作用，所有程序員都聽從主程序員的安排，隻和主程序員交流和溝通，降低了項目溝通的複雜度，然而在現實中具有高超的軟件技術能力且具有良好的管理能力的軟件人才很稀少。
3. 矩陣式結構
在大型的軟件企業中，有一種層次化矩陣式結構，這種結構將技術與管理工作分離，技術負責人負責技術上的決策，管理負責人負責非技術性事務的管理決策和績效評價。如圖34所示。圖34矩陣式結構
項目經理負責整個項目過程的管理和績效評價，另外還有專門的技術負責人負責軟件開發的技術決策和方案設計。開發人員按不同角色分工協作完成開發任務，這個模式解決了技術和管理無法兼備的問題，但是團隊成員受到雙重領導，明確劃分技術人員和管理人員權限是十分重要的。這種矩陣式結構中的程序員組成人數不宜過多。當軟件規模較大時，應該把程序員分成若幹小組，采用如圖35所示的組織結構。該圖描述的是技術管理組織結構，非技術管理組織結構與此類似。
圖35大型項目的技術管理組織結構
不管采用哪種組織結構，為了提高團隊的效率，需要進行績效評估。績效評估是通過對團隊成員工作績效的考察與評估，反映團隊成員的實際能力和業績以及對某種工作職位的適應度，為物質獎勵、人員調配、精神激勵提供依據。績效評估應該是多維度的，一個維度是完成任務維度，項目經理從進度、質量、已完成的工作量、難度係數、創新性等方麵，給出好、中、差三個級別的評價。對任務工作量的評估，軟件項目沒有像其他工程例如建築工程那樣的定額，實際上要靠項目經理的個人經驗進行評估。關於質量，可以從代碼規範情況、注釋、BUG率、運行性能、技術文檔方麵、測試報告、用戶評價幾方麵考察。第二個維度是團隊貢獻維度，采用團隊內部互評的方式，評出團隊中最好的20%、中間70%和最需要改進的10%。第三個維度是自我對完成任務和對項目的貢獻評價。這個三維評價體係反映了個人工作情況和對團隊的貢獻。做好績效評估，可以有效地激發員工的積極性，改進個人的工作績效，最終使團隊整體績效的提升。如果評價不合理，就會影響人員士氣、穩定性、後續的合作和產品質量，所以必須認真對待慎重考慮。
3.1.7項目溝通
溝通是為了達到一定的目的，將信息、思想、情感在個人或群體之間進行傳遞或交流的過程。人們通過溝通交換有意義有價值的各種信息以便把事情高效率地辦好。溝通是保持項目順利進行的潤滑劑。
團隊成員溝通的複雜性可以從以下幾種情況進行分析：
第一情況，一個農夫可以在3天內拾完一塊地裏的棉花，同樣的棉花地，是否可以通過增加人手，用3個人一天拾完。這種情況應該可以做到。
第二情況，一頭大象需要孕育22個月，才能生下一頭小象，增加大象的數量是否可以加快這個過程，顯然增加大象對於生產小象完全無濟於事。
第三種情況，假設開發某個模塊，需要一個程序員3個月的工作量，那麼是否可以認為3個程序員在一個月內完成，一般情況3個人開發一個模塊的效率，不可能是3個人開發效率的之和，因為在協作的過程中，個人的工作效率都會有些降低，產生這種情況的根本原因在於人們對於分解後的子任務，需要進行溝通和交流。
對於類似拾棉花這種任務來說，可以把它分解給不同的參與人員，而且他們之前不需要相互的交流，增加人手確實可以大大增加工作進度。
對於生產小象這種任務，由於次序上的限製，任務完全不能分解，增加人手對進度沒有任何幫助。軟件開發中也有這種任務。對於可以分解但子任務之間需要相互溝通和交流的任務，必須在計劃工作時考慮溝通所增加的工作量。雖然增加人手可以加快進度，但是每個人的效率都會受到影響。對於一些關係錯綜複雜的任務，溝通增加的工作量可能完全抵消對原有任務的分解所產生的作用。
軟件開發是一項關係錯綜複雜的工作，隨著人員的增加，溝通與交流的工作量也會極大增加，它很快會消耗掉任務分解所節省下來的個人時間。人與人之間的溝通渠道看起來像是連接參與者之間的電話線數目，隨著項目成員數量的增加，溝通渠道的數量是按照n(n-1)\/2的方式遞增。例如：兩個人之間的溝通渠道是一個，三個人之間的溝通渠道增加到3個，4個人之間的溝通渠道會增加到6個，溝通的工作量增加了一倍。《人月神話》中有個Brooks法則：向一個進度延遲的軟件項目中增加人員可能會使其進展更加延遲。所以趕進度的最好方法不是增加人手而是通過加班增加時間。由於溝通的複雜性，一個軟件項目人員規模在3到7人比較合適，最多不要超過10人。
在實際工作中，由於多方麵因素的影響，信息往往被丟失或曲解，使得信息不能被有效地傳遞，從而造成溝通的障礙，因此需要進行項目溝通管理。項目溝通管理確保項目信息及時且恰當地收集和傳遞，是對項目信息的內容、傳遞方式和傳遞過程等進行管理的活動。
對於項目團隊內部的溝通來說，團隊成員需要清楚地知道自己的分工和職責與其他部分的關係。在進行任務分配時，需要說明需要完成的成果、評價標準和完成期限。在項目進展中，需要定期召開會議，實現項目信息共享和做出決策。例如項目啟動會議、成員進度彙報、項目進展會議。一次富有成效的項目工作會議，可以及時通報項目進展情況，發現潛在的問題，或者討論問題的解法方法，有利於增強團隊的凝聚力和實現項目目標。
會議是管理工作得以貫徹實施的中介手段。會議在項目溝通管理中起到重要作用。常見的項目會議包括項目啟動會議、項目計劃會議，項目階段進展會議、項目技術評審會議、項目組內部會議等。
項目啟動會議是項目立項之後至關重要的第一次召開的全體會議,必要時可以邀請客戶和主管經理參加。會議的目的是讓團隊成員對該項目的整體情況和各自的工作職責有一個清晰的認識和了解，為日後協同開展工作做準備，同時獲得領導對項目資源的承諾和保證。
項目啟動會議的主要內容包括以下幾個方麵：
（1） 介紹項目總體情況：項目目標及其重要意義、規模、總體進度、項目主要幹係人信息、項目的基本需求、可交付的成果。
（2） 介紹項目團隊成員及分工，重點在於使大家互相認識，明確團隊組織形式和工作模式，建立團隊成員期望；強調團隊成員相互協作的必要性；要求團隊成員承擔起各自的職責，並賦予其尋求幫助的權力。
（3） 介紹項目經理提前製定的項目計劃草案。
（4） 確定取得成功的關鍵要素。
（5） 討論製定信息分享計劃，並於團隊及相關群體協商確認。
（6） 建立關於計劃決策、追蹤決策、管理變動決策、彙報關係決策等基本規則。項目會議的形式對於重大項目要精心準備，集中開會1到2天，主要是進行項目前期介紹與建立基本規則，對於一般項目要簡單有效，主要是介紹項目範圍與成員互相自我介紹。
項目計劃會議一般發生在每一個階段開始時，項目團隊要共同製定當前階段的項目計劃，把工作任務分配給項目成員，並要求對完成時間做出承諾，使項目團隊對項目進度達成共識。
項目階段進展會議向項目幹係人和高層管理者彙報項目進展，解決需要高層管理者支持的問題。項目階段進展會議應該定期召開，一般每月或每季度進行一次。
項目組工作例會應該在每日或者每周召開，檢查通報項目組成員的工作進展，了解成員在工作中遇到的困難並尋找資源進行解決。如果解決方案涉及計劃變更，還要對整個項目計劃進行修訂，確定後續的工作計劃。
在項目溝通管理過程中，要不斷跟蹤項目的進展情況，彙總項目在進度、成本、工作量和產品質量等績效數據，形成項目績效報告，績效報告通常使用文字說明、曲線、圖形和報表等形式進行描述。現在有許多軟件工具可以用於管理和顯示項目的各種信息。
隨著網絡的發展，遠程協作開發成為一種普遍的做法，這種開發沒有時空的限製，比麵對麵一起工作更為高效、自由。但由於缺少在一起交流，缺少親切感，不經常交流、反饋比較慢的問題，在團隊沒有建立起默契之前，成員之間的交流可能會有負麵的影響。要想克服遠程給協作開發帶來的障礙，就要盡可能在日常表達中保證清楚地表達，保持經常不斷交流，要保持交流的及時性，保持立即反饋和文件共享。
3.2項目規劃
項目規劃是對軟件項目實施所涉及的活動、資源、任務、進度等進行規劃。項目規劃的目標是多快好省地完成項目，按時交付是軟件項目的最大挑戰。所以合理地安排進度是軟件項目規劃的關鍵內容。
項目規劃具有指導項目的實施，記載項目規劃的前提假設，記載根據選擇的方案做出的決策，促進項目涉及人員之間的溝通，確定項目管理的內容、範圍和時間等作用。項目規劃可在項目投標階段、項目開始階段和項目過程中進行。項目投標階段是為了爭取一個開發軟件係統的合同，幫助管理者判斷是否有完成這項工作所需要的資源，並計算出向客戶開出的軟件報價。項目的開始階段規劃主要是確定參加此項工作的人員，並將工作分解成幾個子項目，並進一步估計工作量。在項目過程階段規劃主要是定期地根據獲取的經驗和項目進展的監督信息修改計劃。
因此，項目規劃主要回答下列問題：
（1） 為什麼要開發這個係統？所有與項目相關人員都應該了解軟件開發工作的理由是否有效。開發該係統值得花費這些人力、時間和費用嗎？
（2） 項目要做什麼？定義項目所需的任務集，工作的具體內容，一定時期的工作重點。
（3） 如何做？如何完成這些工作和任務，定義項目的管理策略和技術策略。
（4） 誰去做？規定軟件團隊每個成員的角色和責任。
（5） 什麼時候做開發？團隊製定項目進度，標識出何時開展項目任務以及何時到達裏程牌。
（6） 成本是多少？每種資源和經費需要多少？對這個問題，需要在對前麵問題回答的基礎上通過估算得到。
（7） 相關的機構組織位於何處？並非所有角色和責任均屬於軟件團隊，客戶、用戶和其他利益相關者也有責任。各項工作進行的環境，以及應該達到什麼質量等一係列問題。
3.2.1項目規劃的過程
項目規劃是一個迭代的過程，一般要經過下列步驟：
●規定項目範圍。即問題描述、確定軟件範圍、明確係統應該解決的問題、係統的功能、約束、性能、接口、目標環境和交付驗收標準。
●確定項目的可行性。
●風險分析。
●確定需要的人力資源、可複用的軟件資源、識別環境資源。
●估算工作量和成本。為了估算工作量和成本，需要分解問題，使用麵向規模、功能點或麵向用例、麵向對象的估算方法進行估算。
●製定項目進度計劃。為了製定項目進度計劃，需要確定項目中必要的任務集合，定義任務網絡，使用進度計劃工具製定時間表，還要定義進度跟蹤機製。
下麵以個人網上銀行係統為例來簡單介紹項目規劃過程。
第一步：描述係統應該說明的問題，係統的目標、環境、交付和驗收標準等問題。問題描述是對係統所表述問題的共同認識，通常是由項目團隊和客戶共同開發形成的，它定義了問題提出的背景、需要支持的功能和性能以及係統運行的目標環境等。
（1） 問題背景
網上銀行是依靠信息技術和Internet的一種新型銀行服務手段，它借助Internet遍布全球的優勢及其不間斷運行、信息傳遞快捷的優勢，突破了傳統銀行的局限性，為用戶提供了全方位、全天候的現代化服務。
（2） 項目目標
個人網上銀行作為網上銀行的一個重要組成部分，主要是為個人用戶提供網上銀行的服務。
（3） 功能需求
個人網上銀行的主要功能包括：賬戶信息查詢和維護，賬戶轉賬（彙款），生活繳費，投資理財產品管理、基金產品管理、信用卡管理6大功能。
賬戶信息查詢和維護是網上銀行的一項基本功能。該功能清晰的列出用戶在該行所有賬戶的賬戶餘額、賬戶明細情況，支持賬戶掛失。
賬戶轉賬（彙款）包括行內同城轉賬及異地彙款。對於用戶客戶端來說，隻要個人賬戶在網點申請成為網銀的簽約用戶之後，客戶登錄個人網上銀行係統就可以進行轉賬彙款。對於需要定期向某個賬戶進行轉賬的需求，還可以通過查詢轉賬記錄，查找要轉賬的賬戶，避免每次都輸入對方賬戶信息。對於銀行端來說，根據用戶轉賬的類型確定收取相應的轉賬手續費。
生活繳費主要指水、電、煤氣和電話費的繳納，以及手機充值等。當用戶需要繳費時，個人登錄網上銀行係統，選擇相應的繳費項，輸入水、電、煤氣、電話費單的用戶號，選擇資金劃出賬號即可進行繳納。
理財產品管理需要用戶在銀行網點進行簽約確認後才可使用。用戶可以選擇相應的理財產品進行購買，用戶還可以查詢自己的理財產品信息。
基金產品管理是指銀行代銷的各類基金產品，用戶可以對基金進行查詢、對比和購買，也可以查詢個人基金信息。
信用卡管理指的是銀行信用卡賬戶的開卡、消費賬單查詢、消費積分查詢等。
（4） 非功能需求
係統能夠支持10 000個用戶並發訪問，支持Windows和Linux兩種操作係統。在正常的網絡環境下，係統的響應速度應該在5秒以內。係統交付的源代碼格式規範、風格統一，易於閱讀和維護；交付的文檔齊全，統一格式且符合國家標準。係統應該保證安全可靠，易操作、易學習。
（5） 其他
服務器和數據庫等運行環境要求使用開源軟件係統，個人網上銀行係統需要在××××年××月××日之前交付。
對於問題描述中的功能需求，還要進一步說明用戶和係統交互的一係列場景及用戶使用軟件的界麵原型，可以用用例圖描述。
第二步：可行性分析。采用當前的Web技術和數據庫技術完全可以在規定的時間要求和預算範圍內可以完成。（後麵章節介紹估算方法）個人網上銀行可以集成到網上銀行係統之中。
第三步：在粗略的需求分析的基礎上，給出係統的頂層設計，頂層設計描述了最初從係統到子係統的分解，它描述了係統的軟件體係結構。
頂層設計的步驟包括明確設計目標，初始的子係統分解，設計目標的進一步分解和求精，將分解的子係統分給不同的團隊或開發人員，讓他們協商定義子係統之間的接口。步驟如圖36所示。
圖36頂層設計步驟
需要強調的是子係統分解應該是高層的，專注於功能，並要保持穩定。每一個子係統可以分配給一個團隊或一個人，由他負責其定義、詳細設計和實現。因此，個人網上銀行係統的頂層設計示意圖如圖37所示。
圖37個人網上銀行頂層設計示意圖
根據需求描述，個人網上銀行係統設計采用了開放的技術體係，係統的整體架構核心是服務端，而客戶端是遵循規範的多種瀏覽器，包括（IE，Firefox等）。個人網上銀行客戶端和服務器端的安全機製，采用的是基於SSL的https協議。SSL需要CA(Certification Authority，承擔網上銀行中安全電子交易認證服務）證書實現非對稱加密。客戶端可以使安裝了Windows或者Linux係統的電腦，並且安裝了相應的瀏覽器，且客戶端首先要到服務器端下載證書，來保證對數據的加密能正常進行，保證數據傳輸的不可竊取和監聽性，保證數據安全地送到客戶端。
第四步：定義項目工作分解，將項目整體分解成較小的易於管理和控製的若幹子項目或工作單元，分解要足夠詳細，足以支持項目將來的活動。
如何分解？分解項目工作有不同的方法，常用的方法是基於功能的分解，如圖38所示。
圖38基於功能的分解
項目分解的原則是要盡量降低耦合，降低集成時的困難。個人網上銀行係統有6大功能，假如團隊有5個人，把賬戶信息查詢和維護功能分給成員A去完成,把賬戶轉賬（彙款）分給成員B去完成，把生活繳費功能分給成員C去完成，把投資理財產品管理和基金產品管理分給成員D去完成，把信用卡管理功能分給成員E去完成。這樣的工作分解好不好？生活繳費功能比較獨立，可以分給一個人去做，其餘部分雖然在功能上可以分割，但是在開發過程中由於代碼和數據庫設計上的耦合，例如成員A和成員B都涉及賬戶，這樣一個人的設計修改可能會影響其他人。既熟悉前端開發和後端開發的人員在團隊很難找到。所以這種按功能分解的方案，在開發的時候把分別開發的模塊集成到一起很困難。
另一種分解基於係統產品結構的分解，即分解成前端、後端和數據存取模塊。把個人用戶頁麵和銀行管理員頁麵分別分給成員A和B，RESTFUL API模塊分給成員C，數據存取模塊分給成員D，成員E負責數據庫的設計、實施和並承擔功能測試工作。這種分解可以使開發人員專注於前端、後端和數據庫的開發，不同模塊之間通過接口訪問，相對來說耦合性比較低。
第五步：建立初始項目計劃表，在項目工作分解的基礎上，進一步估算活動所需要的時間和資源，並按照一定的順序對這些活動進行組織和調度，創建項目的進度計劃表（進度安排表示方法後續章節介紹）。
在這個過程中首先要識別項目裏有哪些任務及任務之間的關係。由開發人員估算完成任務的時間，最終創建項目的進度表。這個過程如圖39所示。
圖39創建項目進度表的過程
需要注意的是，製定進度計劃需要在資源、時間、實現功能之間不斷平衡，並需要定期更新。
由於在項目早期中存在較多的不確定性，所以項目規劃不可能在項目一開始就全部一次詳細地完成，需要在各種規劃過程中不斷完善。在發現新的項目信息時，需要識別或解決新發現的依賴關係、風險、機會、假設和製約因素。在製定規劃的過程中不斷發現新信息，這些新信息將對已經編製的計劃產生影響。隨著收集和了解到的新信息或特征的增加，當分析調查的工作可以基本覆蓋項目所有可預見的環節時，規劃工作可以基本結束。項目規劃是動態的，不是一成不變的。規劃期間無法預測項目生命周期中發生的變更。在項目執行期間批準的變更可能影響項目規劃，這些重大變化發生後，需要及時修改更新項目規劃。
3.2.2項目規劃方法
在項目實施過程中，分階段使項目規劃逐步詳細，逐步深入。這種方法的好處是可以減少項目初期規劃的工作量，在項目開始階段隻對馬上要啟動的一個階段做詳細規劃，其後續階段隻做粗略估計。第一個階段將要完成時，開始第二個階段的規劃，這樣以此類推，直到最後一個階段完成。
在製定一個項目規劃之前，需要具備以下一些條件：
（1） 整個項目要能夠按照工作內容進行詳細的分解，盡可能分解成獨立的可衡量的活動。
（2） 根據工作組合關係、產品結構、擁有的資源（設備與人員）以及管理目標等，能夠組成項目活動的先後順序。
（3） 每項任務或活動的時間、成本都要估計出來，並盡可能詳細。
3.2.3軟件度量
合理的規劃是建立在項目估算上的，而估算的基礎是軟件度量。軟件度量是一個對軟件屬性及其規格的量化測度。對軟件產品的直接測量包括產生的代碼行（LOC)、運行速度、存儲容量以及某段時間內報告的缺陷；而間接測量包括功能、質量、複雜性、效率、可靠性、可維護性等。
構造軟件所需的成本和工作量、產生的代碼行數以及其他直接測量都是相對容易。但軟件的質量和功能、效率或可維護性則很難獲得，隻能間接地測量。
1. 麵向規模的度量
麵向規模的度量是對軟件和軟件開發過程的直接度量。例如可以建立如表34所示的麵向規模測量表，記錄過去幾年完成的每一個軟件項目和關於這些項目的相應麵向規模的測量數據。表34麵向規模的度量
項目規模（千行）工作量
（人月）成本（103元）文檔頁數
（／頁）錯誤數（／個）缺陷（／個）開發人數
（\/人）alpha12 10024168365134293beta27 200624401 224321865gamma20 200433141 050256646對於每一個項目，可以根據表格中列出的基本數據進行麵向規模的生產率和質量的度量。例如，可以根據表34對所有的項目計算出平均值，即:生產率＝規模／工作量平均成本＝總成本／規模
質量＝錯誤數／規模平均文檔＝文檔頁數／規模如果項目負責人已經正確地估計了新項目的代碼行，然後使用該項目開發組原來的平均生產率就可以估算出新項目所需的工作量等數據。但由於項目複雜度的不同，這種估計方法往往與實際工作量有一定的差距。
2. 麵向功能的度量
鑒於相同功能，不同語言實現存在代碼量的差異，且軟件需求為麵向功能描述，Albrecht提出了麵向功能點FP(Function Point)的度量。
麵向功能點的度量是基於5個信息域的特征數，以及軟件複雜性估計進行的間接度量。用於功能點度量的5個信息域特征如圖310所示.
圖310軟件信息域
表35給出了5個信息域的特征及含義，這5個信息域特征的值都能通過直接測量得到。將這些測量值填入到表36。表35信息域特征含義
特征名含義外部輸入數對每個用戶輸入進行計數，他們向軟件提供不同的麵向應用的數據。 外部輸出數各個用戶輸出是為用戶提供的麵向應用的輸出信息，它們均應計數。這裏的輸出是指報告、屏幕信息、錯誤信息等，在報告中的各數據項不應再分別計數。外部查詢數用戶執行一次聯機輸入即查詢，它導致軟件以聯機輸出的方式產生實時的響應。每一個不同的查詢都要計算。內部邏輯文件數對每個邏輯上的主文件進行計數（即數據的一個邏輯組合，可能是某個大型數據庫的一部分或是一個獨立的文件）。外部接口文件數對所有機器可讀的接口（如存儲介質上的數據文件）進行計數，利用這些接口可以將信息從一個係統傳送到另一個係統。一旦收集到上述數據，就可以統計出軟件的總計數CT。對每一個計數乘以表示該計數複雜程度的加權因子，再求和得到CT，如表36所示。軟件組織可以建立一個標準以確定某個特定的條目是簡單、中間還是複雜的。表36特征計數表
測量參數特征值加權因子簡單中間複雜特征值×加權因子外部輸入數×3×4×6=外部輸出數×4×5×7=外部查詢數×3×4×6=內部邏輯文件數×7×10×15=外部接口文件數×5×7×10=總計CT表37計算功能點的校正值
序號問題Fi∈[0，5]1係統是否需要可靠的備份和恢複?2是否需要數據通信？3是否有分布式處理的功能?4性能是否是關鍵?5係統是否將運行在現有的高度實用化的操作環境中?6係統是否要求聯機數據項？7聯機數據項是否要求建立在多重窗口顯示或多操作之間切換以完成輸入?8是否聯機更新主文件?9輸入、輸出、文件、查詢是否複雜？10內部處理過程是否複雜?11程序代碼是否要設計成可複用的?12設計中是否包含變換和安裝嗎?13係統是否要設計成多種安裝形式安裝在不同的機構中?14應用係統是否要設計成便於修改和易於用戶使用?合計表38複雜性取值表
值定義值定義0沒有影響3普通影響1偶有影響4較大影響2輕微影響5嚴重影響計算軟件的功能點（FP）使用的公式為 FP＝CT×[0.65+0.01×SUM(Fi)]，其中，CT是軟件的總計數，根據表36計算；Fi(i∈[1，14])是複雜性校正值，它們應通過逐一回答表37中的問題來確定；Fi的取值範圍是0到5如表38所示；SUM(Fi)是求和函數。
FP與程序設計語言無關，對於使用傳統語言和非過程語言的應用係統來說，比較理想的。但該方法的計算主觀性較強。
功能點度量是為了商用信息係統應用軟件而設計的。事實上，以上內容並非固定不變。例如，對某些算法複雜的應用問題，就應該增加對軟件特征即“算法”進行計數。因而，必須根據實際應用情況來決定功能點的度量方式，並進行計算。
針對這種情況，Jones將其擴充，提出在功能點度量的基礎上，增加對軟件“算法”特征的計數。該方法適合於實時處理、過程控製、嵌入式軟件等算法複雜性高的應用。值得注意的是，特征點與功能點表示的是同一件事，即軟件提供的“功能性”或“實用性”。事實上，對於傳統的工程計算或信息係統應用，兩種度量會得出相同的FP值。在較複雜的實時係統中，特征點計數常常比功能點確定的計數高出20％～35％。
代碼行和功能點之間的關係依賴於實現軟件所采用的程序設計語言及設計的質量。很多研究試圖將FP和LOC測量關聯起來。表39給出了在不同的程序設計語言中實現一個功能點所需的平均代碼行數的粗略估算。表39幾種程序設計語言實一個功能點所需的代碼行數的粗略估算
程序設計語言LOC\/FP平均值中值低值高值ASP51541569Assembler1199825320C979939333C++50532580C#54592970Java53531448HTML34401055PL\/SQL37351360Visual Basic42442060COBOL615523297由這些數據可以看出,Java的一個LOC所提供的“功能”大約是C的一個LOC所提供“功能”的2.6倍。利用表39包含的信息。隻要知道了程序設計語言的語句行，就可以“逆向”估算出現有軟件的功能點數量。
3. 麵向對象的度量
Lorenz和Kidd提出了一些用於麵向對象軟件項目的度量。例如，場景腳本的數量、關鍵類的數量、支持類的數量，每個關鍵類的平均支持類的數量、子係統的數量。為了將上述這些度量有效地應用於麵向對象的軟件工程環境中，必須將它們隨同項目測量(例如，花費的工作量、發現的錯誤和缺陷、建立的模型或文檔資料)一起收集。隨著完成項目數量的增長和數據庫規模的增長，提供的麵向對象測量和項目測量之間的關係將有助於項目的估算。
4. 麵向用例的度量
用例被廣泛地用於描述客戶層或業務領域的需求，這些需求中隱含著軟件的特性和功能。與LOC或FP類似，在重大的建模活動和構建活動開始之前，就允許使用用例進行估算。用例描述了(至少是間接地)用戶可見的功能和特性，這些用例是係統的基本需求。用例與程序設計語言無關，它比功能點方法要簡單一些。如圖311所示的用例圖，表明業務係統中，涉及Customer的功能有3個。
圖311用例圖
3.2.4軟件項目估算
建築工程中，人們需要知道要花多少錢、多少時間和大概需要多少工程量的情況才開始建房。軟件項目估算是對完成項目交付物的資源、成本和時間進行預算和估計的過程。對於軟件項目來說，估算的最大挑戰是項目的複雜性和不確定性。軟件規模越大，複雜性越高，不確定性就越大。需求的不確定性會對項目估算產生很大影響；沒有可靠的曆史數據使得項目估算缺少參照物。估算資源、成本和進度時需要經驗、有用的曆史信息、足夠的定量數據和做定量預測的勇氣。另外，估算本身也帶有風險。隨著經驗越來越多，估算就會越來越準確。
軟件項目估算的首要原則是對結果進行估計，而不是活動。估算具有不確定性，但估計時要基於事實，考慮風險做出合理的調整，確保對完成時間有信心。
一、 項目開發中需要的資源
開發一個軟件項目所需要的資源可以分為人員、可複用的軟件構件及開發環境(硬件和軟件工具)三類。
對於人力資源，需要先確定軟件範圍，選擇完成開發所需的技能和專業，還要確定團隊需要哪些職位。如果團隊成員地理上不在一個地方，還要說明每個人所處的位置。至於需要的人員數量要在估算出開發工作量（多少人月）後才能確定。
對於可複用軟件資源，Bennatan建議在製定計劃時應該考慮四種軟件資源：成品構件(能夠從第三方或者從以往項目中獲得的現成軟件)；具有完全經驗的構件(為以前項目開發的，具有與當前項目要構建的軟件類似的規格說明、設計、代碼或測試數據)；具有部分經驗的構件（為以前項目開發的，具有與當前項目要構建的軟件相關的規格說明、設計、代碼或測試數據，但是需要做很多修改)；以及新構件(軟件團隊為了滿足當前項目的特定要求，專門開發的軟件構件)。
對於環境資源通常稱為軟件工程環境，它集成了硬件和軟件工具。硬件提供支持軟件工具的平台，軟件工具是高效完成軟件項目所必需的。硬件是作為軟件開發項目的一種工具而投入的，有三種硬件資源：
（1） 宿主機(Host Machine)，軟件開發時使用的計算機及外部設備。
（2） 目標機(Target Machine)，運行已開發成功軟件的計算機及外部設備。
（3） 其他硬件設備，即專用軟件開發時需要的特殊硬件資源。
軟件工具主要有以下幾類：
① 業務係統技術工具；② 項目管理工具；③ 支持工具；④ 分析和設計工具；⑤ 編程工具；⑥ 組裝和測試工具；⑦ 模擬工具和原型化工具；⑧ 維護工具；⑨ 框架工具。
二、 項目估算方法
（1） 專家判斷是一種估算方法。通過借鑒曆史信息，專家提供項目估算所需要的信息，或根據以往類型項目的經驗，給出相關參數的估算。
（2） 參數估算。通過對大量的項目曆史數據進行統計分析，使用項目特性參數建立經驗模型，估算諸如成本、預算和持續時間等活動參數。
（3） 根據已經完成的類似項目進行估算。
（4） 使用比較簡單的分解技術，生成項目的成本和工作量估算。
（5） 使用一個或多個經驗模型來進行軟件成本和工作量的估算。
如果當前項目與以前的某個項目相似，並且項目的其他影響因素(客戶、商業條件、軟件工程環境、交付期限)也大致相同，第三種方法就能很好地發揮作用。遺憾的是，過去的經驗並不總是能夠指明未來的結果。
軟件成本估算的基礎是曆史數據，曆史數據的基礎是度量數據。如果沒有曆史數據，估算就建立在不穩定的基礎上。
三、 分解技術
分解是“分而治之”地把複雜問題分解成一組易於解決的較小問題，再定義他們的特性。分解有過程分解和問題分解兩類分解方法，但是在進行估算之前，要理解將要開發的軟件範圍並估算其規模。
1. 估算軟件規模
有許多因素決定或影響軟件估算的準確性，例如：待開發軟件規模估算的準確性；以往軟件項目度量數據的可用性；項目計劃中軟件團隊能力的強弱；產品需求的穩定性和支持軟件工作的環境等。
在項目計劃中，規模是指軟件項目的可量化結果。規模可以用代碼行和功能點來表示。對規模的估算要考慮項目類型以及應用領域、要交付的功能、要交付的構件數量、對現有構件的修改程度。
代碼行技術是一種簡單而直觀的軟件規模估算方法，它從過去開發類似產品的經驗和曆史數據出發，估算出所開發軟件的代碼行數。開發人員需要給出軟件的範圍描述，並進一步將軟件分解成一些盡量小且可分別獨立估算的子功能，通過估算每一個子功能並將其代碼行數累加得到整個係統的代碼行數。
估算時，要求評估人員給出樂觀的（a）、可能的（m）、悲觀的（b）三種情況，並采用以下公式計算估算結果，其中 L 是軟件的代碼行數，ld為對期望值偏離的均方差。單位是行代碼 LOC 或千行代碼kLOC。L=(a+4m+b)\/6ld=∑ni=1(b－a6)2計算代碼行應遵循以下原則：
① 保證每個計算的“源代碼行”隻包含一個源語句；
② 計算所有交付的、可執行的語句；
③ 數據定義隻計算一次；
④ 不計算注釋行；
⑤ 不計算諸如測試行、測試用例、開發工具、原型工具等使用的調試代碼或臨時代碼；
⑥ 在每一個出現的地方，每條宏的調用、激活或包含都作為源代碼的一部分。
在估算出代碼行數，還可以進一步度量軟件的生產率、每行代碼的單元成本、每千行代碼的錯誤個數等。
（1） 生產率P=L\/PM其中，L為軟件的代碼行數，PM為軟件開發的工作量，單位為人月；P為生產率，單位為每人月完成的代碼行數。
（2） 單位成本C=S\/L其中，S為軟件開發總成本，C是每行代碼的平均成本。
（3） 代碼出錯率EQR=N\/L
其中，N為軟件的錯誤總數；EQR是每千行代碼的平均錯誤數。
代碼行技術的優點是簡單方便，在曆史數據可靠的情況下可以很快估算出比較準確的代碼行數；其缺點是這種方法需要依賴比較詳細的功能分解結果，難以在開發初期進行估算，其估算結果與所用的開發語言緊密相關，且無法適用於非過程語言。
2. 基於問題的估算
首先從界定的軟件範圍陳述入手，嚐試將範圍陳述分解成一些可分別獨立進行估算的功能。然後，估算每個功能的LOC或FP(即估算變量)。當然，計劃人員也可以選擇其他元素進行規模估算，例如，類或對象、變更、受影響的業務過程。最後，將生產率度量(例如，LOC／pm（人月）或FP／pm)和適當的估算變量結合，導出每個功能的成本或工作量。將所有功能的估算合計起來. 即可得到整個項目的總估算。
軟件組織的生產率度量常常是變化的。一般情況下，應該采用平均的LOC\/pm或FP\/pm。在收集項目的生產率度量時，一定要劃分項目類型，這樣才能計算出特定領域的平均值。估算一個新項目時，先要找到新項目對應的領域，然後再使用適當領域生產率的平均值進行估算。
LOC估算（代碼行）和FP估算（功能點）技術的不同之處在於LOC估算要求分解的越詳細越好，分解的越詳細估算也越準確。而FP估算關注的不是功能，而是5個信息域特性——輸入、輸出、數據文件、查詢和外部接口，以及14種複雜度校正值。然後，利用這些估算結果導出FP值，使用該值與以往的數據結合來進行估算。
基於3.2.1節中個人網上銀行係統的問題描述和主要功能需求，對該係統進行估算。該項目按照功能可以分解為如下的6個子項目：
●賬戶信息查詢和維護。
●賬戶轉賬（彙款）。
●生活繳費。
●投資理財產品管理。
●基金產品管理。
●信用卡管理。
按照LOC的分解技術，得到表310所示的估算表。表中給出6個子項目的代碼行的樂觀、悲觀、可能的估算值，並利用代碼行公式計算出各子項目代碼行的加權平均值後得到整個項目的代碼行估算值為6581。表310基於LOC的估算
功能樂觀值可能值悲觀值加權平均賬戶信息查詢和維護8001 1001 5001 116賬戶轉賬（彙款）7501 0501 4501 066生活繳費6508501 300891投資理財產品管理8201 2001 5201 190基金產品管理8101 1501 4501 143信用卡管理8201 1701 5401 173總計6 581根據以往類似項目的開發經驗，開發該類係統的團隊平均生產率如果為800LOC\/PM（人月），則該項目的工作量為8.2人月。如果一個員工的價格是每月10 000人民幣，則該項目的人員成本估算值是8.2萬。
如果采用FP估算，為了進行估算，假定複雜度加權因子都取平均值，表311列出了功能點估算結果。表311基於功能點估算
信息域值樂觀值可能值悲觀值估算值加權因子FP值外部輸入數212530254101外部輸出數8131713564外部查詢數9152015459內部邏輯文件數681361085外部接口數1232714總計323表312計算功能點的校正值
序號問題Fi(0~5)1係統是否需要可靠的備份和恢複?52是否需要數據通信？53是否有分布式處理的功能?54性能是否是關鍵?45係統是否將運行在現有的高度實用化的操作環境中?26係統是否要求聯機數據項？37聯機數據項是否要求建立在多重窗口顯示或多操作之間切換以完成輸入?38是否聯機更新主文件?59輸入、輸出、文件、查詢是否複雜？410內部處理過程是否複雜?411程序代碼是否要設計成可複用的?512設計中是否包含變換和安裝嗎?313係統是否要設計成多種安裝形式安裝在不同的機構中?314應用係統是否要設計成便於修改和易於用戶使用?5合計58最後，得出FP的估算值：FP=總計×(0.65+0.01×∑Fi)=397。
開發這類係統的團隊平均生產率如果是40\/PM（人月）。則工作量的估算值是9.9人月。如果一個員工平均價格是每月8 000人民幣，則每個FP的成本約為200元，項目人員成本的估算值是79 400元。
3. 基於過程的估算
基於過程的估算是根據軟件過程進行估算，將過程分解為一些小的活動、動作和任務，並估算完成每一項所需的工作量。
因此，基於過程的估算步驟為：第一步從項目範圍中提取出軟件功能；第二步列出為實現每一個功能所必須執行的一係列活動；第三步用表格的形式給出功能和活動的對應關係,類似於表313；第四步對於每個功能，估算出完成各個軟件過程活動所需要的工作量；第五步，將平均勞動力價格與每個軟件過程活動的估算工作量結合，就可以估算出人員成本。表313工作量估算表
活動
功能客戶溝通計劃風險分析分析設計編碼測試合計賬戶信息查詢和維護0.20.40.20.51.3賬戶轉賬（彙款）0.10.20.20.30.8生活繳費0.20.30.10.30.9投資理財產品管理0.20.50.312基金產品管理0.20.50.21.12信用卡管理0.10.50.31.12合計0.50.250.2512.41.34.310工作量%5%2.5%2.5%10%24%13%43%表313列出了個人網上銀行係統的每個功能在不同軟件工程活動的工作量估算(人月)。其中，構建發布活動又被細分為分析、設計、編碼、測試。再加上客戶溝通、計劃和風險分析活動，從而算出總工作量的估算。
4. 基於用例點的估算
用例點估算是一種估算規模和工作量的方法，主要用於麵向對象軟件開發項目。用例點估算的步驟如下：
第一步：建立用例模型。
第二步：計算角色複雜度UAW。
可以通過加權求和的方式求到角色複雜度，如表314（a）所示。
表314（a）角色複雜度
角色複雜度說明權重簡單角色是通過API或接口與係統進行交互的其他係統1一般角色是通過協議（如TCP\/IP）與係統進行交互的其他係統2複雜角色是通過GUI或Web界麵與係統進行交互的人3第三步：計算用例複雜度UUCW，如表314（b）所示。表314（b）用例複雜度
用例複雜度說明權重簡單僅涉及1個數據庫；操作步超過3步；實現用5個類以下5一般涉及2個或2個以上數據庫實體，操作在4—7步；實現用到5—10類10複雜複雜的用戶界麵或涉及3個或以上數據庫實體；操作超過7步；實現用到超過10個類15同樣可以通過加權求和的方式求到用例複雜度。
第四步：計算未平衡用例點 UUCP=UAW+UUCW。
第五步：用技術複雜度因子TCF和環境複雜度因子ECF進行調整，得到用例點。
UCP=TCF×ECF×UUCP
第六步：估算項目開發工作量。隻要給出基於每個UCP完成的時間，就可以計算出項目開發工作量。
工作量=UCP×生產率
建議每個UCP為16～30人時，可以取均值為20個人時。表315技術複雜度因子TFi取值0..5
技術因素說明權重技術因素說明權重TF1分布式係統2TF8可移植性2TF2係統性能要求1TF9可修改性1TF3終端用戶使用效率要求1TF10並發性1TF4內部處理複雜度1TF11特殊的安全性1TF5可重用性1TF12提供給第三方接口1TF6易安裝性0.5TF13需要特別的用戶培訓1TF7易用性0.5TCF=0.6+0.01×∑TFi表316環境複雜度因子EFi取值0..5
環境因素說明權重環境因素說明權重EF1UML精通程度1.5EF5團隊士氣1EF2開發應用係統經驗0.5EF6需求穩定性2EF3麵向對象經驗1EF7兼職人員比例1EF4係統分析員能力0.5EF8編程語言難易程度2ECF=1.4+(-0.03×∑EFi)5. 基於模型的估算
(1) COCOMO模型
① 基本COCOMO模型
Boehm提出的結構性成本COCOMO（Constructive Cost Model）模型是一種利用經驗模型進行工作量和成本估算的方法，這種模型分為基本、中間、詳細三個層次，分別用於軟件開發的不同階段，即係統開發初期、子係統的設計、子係統內部設計。PM=a×（S）b
D=c×(PM)d其中a為工作量調整因子；b為規模調整因子；S表示規模，單位千行代碼或功能點數；PM表示工作量，單位人月；c為開發時間常數；D為開發時間,單位人月；d為常數。
按照軟件的應用領域和複雜程度，該模型把軟件開發項目的總體類型分為3種（見表317）：組織型(Organic)、嵌入型(Embadded)和介於上述兩種軟件之間的半獨立型(Semidetaed)。每種類型取不同的a和b值。a,b,c,d四個常數的值如表318所示。表317項目類型表
項目類型說明組織型相對較小、較簡單的軟件項目，對需求不苛刻，開發人員對開發目標理解充分，相關工作經驗豐富，對使用環境熟悉，受硬件約束較少，程序規模不大（<5萬行）。嵌入型軟件在緊密聯係的硬件、其他軟件和操作的限製條件下運行，通常與硬件設備緊密結合在一起，對接口、數據結構、算法要求較高、軟件規模任意。半獨立型介於組織型和嵌入型之間，軟件規模和複雜性屬中等以上，最大可達30萬行。表318基本COCOMO模型參數
軟件項目類型abcd組織型2.41.052.50.38半獨立型3.01.122.50.35嵌入型3.61.22.50.32② 中間COCOMO模型
考慮了15種影響軟件工作量的因素，通過工作量調節因子修正工作量的估算，從而使估算更合理，公式如下：PM=a（S）bEAF其中，PM是工作量，單位人月；S是軟件產品的代碼行數；EAF表示調節因子；a,b是常數，取值如表319所示。表319中間COCOMO模型參數
項目類型ab組織型3.21.05半獨立型3.01.12嵌入型2.81.20表320給出了影響工作量的因素及其取值，每個調節因子Fi的取值分為很低、低、正常、高、很高、極高6級，正常情況下Fi=1；當15個Fi選定後，可得：EAF=∏15i=1Fi表320調節因子取值表
工作量因素Fi很低低正常高很高極高產品因素軟件可靠性0.750.881.01.151.40數據庫規模0.941.01.081.16產品複雜性0.70.851.01.151.301.65計算機因素執行時間限製1.01.111.301.66存儲限製1.01.061.211.56虛擬機易變性0.871.01.151.30環境周轉時間0.871.01.071.15人的因素分析員能力1.461.00.86應用領域實際經驗1.291.131.00.910.71程序員能力1.421.171.00.860.82虛擬機使用經驗1.211.101.00.900.70程序語言使用經驗1.411.071.00.95項目因素現代程序設計技術1.241.101.00.910.82軟件工具的使用1.241.101.00.910.83開發進度限製1.231.081.01.041.10為了便於說明，以個人網上銀行係統為例，假設該係統的程序規模為5000行代碼。試計算所需工作量和開發時間。
若使用基本COCOMO模型，采用表裏的組織型參數。
工作量 PM=2.4×（5）1.05=13人月
開發時間 D=2.5×130.38=6.6月
若使用中間COCOMO模型，取得的調節因子值如表321所示。表321調節因子
軟件可靠性1虛擬機易變性1.0虛擬機使用經驗1.0數據庫規模0.94環境周轉時間1.0程序語言使用經驗1.0產品複雜性0.7分析員能力1.0現代程序設計技術0.82執行時間限製1.0應用領域實際經驗1.0軟件工具的使用0.83存儲限製1.0程序員能力1.0開發進度限製1.0則EAF=1×0.94×0.7×1×0.82×0.83=0.448PM=3.2×51.05×0.448=7.77人月
以上介紹的是它的中間模型和基本模型，基本模型不使用EFA，僅用於粗略估算。中間模型是從整個生存周期來衡量EFA的影響，而詳細模型需要考慮各個調節因子對不同開發階段的影響。需要深入了解的讀者，可以參閱Boehm的原著。
③ COCOMOⅡ模型
COCOMOⅡ模型是一種層次結構的估算模型。COCOMOⅡ模型被分為三個階段性模型：應用構成階段、早期設計階段和體係結構後階段，在不同階段采用不同的模型計算工作量，從而使工作量的估算越來越接近實際情況。
應用構成階段：該模型用於在軟件開發早期，支持原型開發和基於已有構件開發的軟件項目的工作量估算。此階段的估算方法采用對象點計算的方法，而不用代碼行進行估算。
早期設計階段：該模型在需求已經穩定並且基本的軟件體係結構已經建立時使用。此階段采用功能點和成本驅動因素計算的方法，功能點可以轉換為代碼行。
體係結構後階段：在軟件的構造過程中使用。這個時候軟件結構經曆了最後的構造和修改，並且準備進入開發階段。該模型用於產品實際開發和維護。此階段采用代碼行或功能點計算工作量。
COCOMOⅡ使用對象點進行估算的步驟為：
第一步,分別統計初始的對象實例數，主要包括：
●用戶界麵的屏幕數；
●報表數；
●構件應用可能需要的構件數。
第二步，根據Boehm給出的標準，將每個對象實例歸類到三個複雜度級別之一，如表322所示，根據該表，對屏幕、報表和構件加權求和，得到對象點。對象點＝屏幕數×權重＋報表數×權重＋構件數×權重表322複雜度
對象類型複雜度簡單的中等的困難的屏幕123報表2583GL構件10第三步，當采用基於構件的開發或一般的軟件複用時，還要估算複用的百分比，然後用下麵公式調整對象點數，得到新對象點數NOP。NOP=對象點×(1-複用的百分比)第四步，確定生產率的值PROD。例如表323給出了在不同開發環境成熟度和不同水平的開發者經驗的情況下生產率。PROD＝NOP／人月表323對象點的生產率
開發者的經驗\/能力非常低低正常高非常高環境成熟度\/能力非常低低正常高非常高PROD47132550第五步，得到項目工作量的估算值。估算工作量=NOP\/PROD在更複雜的COCOMOⅡ模型中，還需要一係列的比例因子、成本驅動和調整過程。這些估算模型是根據以前的有限的樣本數據得出的，不可能適用於當前的所有軟件開發項目和開發環境，所以計算結果隻能是一個大概的參考。
為了反映當前項目的情況，應該對估算模型進行調整。應該使用已完成項目的數據對該模型進行檢驗，做法是將數據代入到模型中。並將已經完成項目的實際結果與用模型計算出來的結果進行比較。如果兩者一致性不高，則在使用該模型前，必須對其進行調整和再次檢驗。
(2) Putnam模型
Putnam提出了一種動態多變量模型。這種模型依據收集到的一些大型項目(總工作量達到或超過30人年)的工作量分布情況而推導出來的，Putnam模型把已交付的源代碼(源語句)行數與工作量和開發時間聯係起來，可以用下麵的方程式來表示：S=Ck(PM)1\/3td4\/3S其中S表示源程序代碼行；td表示開發持續時間(年)；PM表示開發和維護在整個生命周期所花費的工作量(人年)；Ck是技術狀態常數，它反映出“妨礙程序員進展的限製”，並因開發環境而異。典型值的選取如表324所示。表324Ck技術狀態常數表
Ck的典型值開發環境開發環境舉例6 500差沒有係統的開發方法，缺乏文檔和複審，批處理方式10 000好有合適的係統開發方法，有充分的文檔和複審，交互執行方式12 500優有自動開發工具和技術(3) 機器學習方法
機器學習方法是采用一種機器學習算法導出一種預測模型。
① 神經網絡方法
神經網絡是一種學習方法，這種方法使用曆史項目數據訓練網絡，通過不斷學習找出數據中的規律，再用其估算新項目的工作量。圖31２說明了如何使用神經網絡對工作量進行估算。它把影響項目工作量的四個因素——問題複雜性、應用新穎度、使用設計工具、團隊規模作為輸入，通過三層網絡計算出工作量。它使用曆史項目的數據作為訓練集，再用訓練好的網絡去估算新的項目。
圖31２神經網絡示意圖
② 基於案例的推理機器學習方法
可以用基於類推的估算，識別出與新項目類似的案例，再調整這些案例，使其適合新項目的參數。首先把一個新的問題標識為一個案例，係統從曆史的信息庫中檢索出相似的案例加以複用，再調整這個案例使其適合新的項目參數，同時把新的輸出案例加入到案例庫中，不斷豐富已有的案例。
這裏有個問題是如何標識出不同項目之間的相同和不同之處?有些軟件工具可以使用。ANGEL就是一種已經開發的用來自動化這種過程的應用程序，它通過標識案例之間的歐幾裏得距離來標識最接近新案例的已有案例。歐幾裏得距離的計算方法是:
歐幾裏得距離=[(新參數1-舊參數1)2+(新參數2-舊參數2)2+…+ (新參數n-舊參數n)2]1\/2
3.2.5項目進度管理
進度是指包括項目中所有活動的日期列表，這些活動按照時間先後順序排列，活動間存在依賴關係，且活動需要任務和資源。進度是跟蹤和溝通項目進展狀態的依據，也是跟蹤變更對項目影響的依據。
進度管理是指采用科學的方法確定進度目標，編製進度計劃和資源供應計劃，進行進度控製，在與質量、費用目標協調的基礎上，實現工期目標。
進度管理的意義在於：
●確保在需要時正好能得到合適的資源。
●避免不同的活動在相同的時間競爭相同的資源。
●為每個人員分配任務，協調人員。進度計劃把項目各個活動和具體人員對應起來，形成責任矩陣，從而有效地進行人員工作的分配。
●實際的進度可以有標準進行衡量，並根據實際情況調整項目。
●產生成本消耗計劃。人力成本占軟件項目的成本很大的一部分，進度計劃中明確給出了人員分配，則可以形成成本計劃的基礎。
●在項目生命周期內重新計劃項目來糾正偏離目標的情況。
軟件項目進度計劃是軟件項目計劃中的一個重要組成部分，影響到軟件項目能否順利進行，資源能否被合理使用，直接關係到項目的成敗。軟件項目進度計劃包括項目活動排序、項目曆時估算、製定進度計劃。
軟件項目進度安排是一種活動，它通過將工作量分配給特定的軟件工程任務，從而將估算的工作量分配到計劃的項目工期內。軟件工程項目的進度安排有兩種情況，第一種情況，有明確的而且不能改變的交付日期，軟件開發組織必須將工作量分布在預先確定的時間框架內。第二種情況是知道大致的時間界限，但是最終發布日期由軟件工程開發組織自行確定。
1. 軟件項目進度安排
首先，識別軟件項目所包含的任務集，任務集是由軟件需求而來的。這裏不僅包含軟件開發任務，也要包含軟件管理的任務。無論選擇哪一種過程模型，一個軟件團隊要完成的工作都是由任務集組成的。當前沒有能普遍適用於所有軟件項目的任務集。
第二，建立任務之間的依賴關係。根據任務本身的先後順序進行排序。有些任務必須是串行的，有些任務可以並行的。
第三，對各個任務的工作量進行合理分配或估算。
第四，定義裏程碑。裏程碑是指一組活動的終點，是完成一個階段工作後可以看到部分結果的檢查點。每個任務或任務組都應該與一個項目裏程碑相關聯。一個或多個工作產品經過質量評審並且得到認可時，就標誌著—個裏程碑的完成。
第五，分配人力和其他資源，判斷完成所有任務的時間，從而製定進度表。
最後，檢查進度安排，確保任務之間沒有衝突，並且包含完成項目必需的所有任務。
傳統的開發過程和敏捷過程都需要初始項目進度安排，隻是敏捷項目計劃不太詳細。采用傳統的開發過程，在開始階段就要創建完整的進度安排，並且隨著項目進行而修改。采用敏捷開發過程，必須有一個總的進度安排，確定何時完成項目的主要階段，然後再使用迭代的方法規劃各個階段。
2. 項目進度估算
進度估算就是要估算任務的持續時間，它是項目計劃的基礎，直接關係到整個項目的時間。工作量估算時沒有考慮資源，但是進度估算時需要考慮資源。例如，同樣工作量的軟件設計工作，估算它的曆時，需要考慮是一個人來完成，還是兩個人來完成，不同的人數需要的時間是不同的。
在進度估算之前，往往已經完成了規模和工作量的估算，所以工作量就可以作為進度估算的依據。考慮團隊規模是否確定，基於工作量的經驗估算有兩種。
當團隊規模確定時，D=E\/S×P，其中D表示任務持續時間，可以用小時、日、周表示；E表示工作量，可以用人月、人天表示；S表示團隊的規模，可以用人數來表示；P表示開發效率，主要代表團隊規模和個人開發相比的效率，體現了團隊效率和個人效率的關係。這種方法適合比較小的項目。
團隊規模未確定時，D=c×E0.3，其中D表示月進度，E表示工作量，以人月為單位，其中c取2到4之間的參數。c依賴項目屬性和團隊項目曆史情況。
IBM模型（WalstonFelix）是1977年IBM公司的Walston和Felix提出的。基本公式為：
E=5.2×（kLOC）0.91
D=4.1×（kLOC）0.36
S=0.54×E0.6
DOC=49×（kLOC）1.01
上述公式中，E是工作量，人月為單位；kLOC是千行代碼數；D是項目持續時間，以月為單位；S是人員需要數；DOC是文檔數量，以頁為單位。
以上介紹的方法是估算整個項目的曆時，而沒有估算各個階段的曆時，無法製定出進度計劃來。此時需要采用一些方法把整個項目的曆時劃分到每個階段上，從而得出每個階段的曆時。有了階段曆時後，再根據識別的任務，進行階段任務分解和排序，把這些時間分配到各個任務上去，對各個任務再進行工作量和開發時間的分配，這種方法可以看成是自上而下的經驗比例進度估算法。
階段曆時的經驗比例有多種，各個軟件開發組織也有自己的不同值，下麵給出幾種經驗比例供參考。
（1） 40—20—40規則
R.S.Pressman提出的40—20—40規則隻用來作為一個指南。在整個軟件開發過程中，編碼前的工作量占40%，編碼工作量占20%，編碼後的工作量占40%。實際的工作量分配比例必須按照每個項目的特點來決定。花費在分析或原型化上麵的工作量應當隨項目規模和複雜性成比例地增加。軟件的重要性決定了所需測試工作的份量，如果軟件係統是人命關天的(即軟件錯誤可能使人喪命)，就應該考慮分配更高的測試工作量比例。
（2） 設計和開發詳細比例
McConnell在《軟件項目生存指南》也提出了一個比例。該比例如表325所示。表325McConnell工作量的比例
生命周期階段小項目\/%大項目\/%架構設計1030詳細設計2020代碼開發2510單元測試205集成測試1520係統測試1015表中沒有給出需求分析階段的比例，因為他認為需求分析要另外花費項目的10%到30%的時間，而且配置管理和質量管理分別占項目總成本的3%到5%。
（3） Walker Royce比例表
Walker Royce在其軟件項目管理中給出工作量比例如表326所示。表326Walker Royce工作量的比例
管理工作5%需求分析5%設計10%編碼和單元測試30%集成和係統測試40%項目實施5%環境配置5%以上比例僅作為參考，項目經理在實際工作中，需要根據項目特點、團隊成員情況和團隊曆來水平確定合理的比例。
（4） Jones的一階估算準則
假設在規模估算中得出了項目中功能點總數，就可以根據該功能點數使用表327中的數據作為指數直接估算進度。表327中的冪次是Jones根據數千個項目的基本數據分析而得到的。例如，如果開發的軟件是平均水平的商業軟件，功能點是FP=170，則粗略的進度=1700.43=9個月。表327Jones冪次值
軟件類型最優級平均最差級係統軟件0.430.450.48商業軟件0.410.430.46封裝商品軟件0.390.420.45多年以來的經驗數據和理論分析都表明項目進度是具有彈性的。即在一定程度上可以提前交付(通過增加額外資源)，也可以拖延項目交付日期(通過減少資源數量)。
PNR(PutnamNordenRayleigh)曲線，表明了一個軟件項目中所投入的工作量與交付時間的關係。項目工作量和交付時間的函數關係曲線如圖313所示。圖中的to表示項目最低交付成本所需的最少時間(即花費工作量最少的項目交付時間),而to左邊(即當我們想提前交付時)的曲線是非線性上升的。
圖313工作量和交付時間的關係
假設一個軟件項目組織根據進度安排和現有可用的人員，估算所需要的工作量為Ed，正常交付時間應為td,雖然可以提前交付，但是曲線在td左側急劇上升，即工作量急劇增加。PNR曲線不僅說明了項目的交付時間不能少於0.75td,而且如果想要再提前一些時間提交，工作量進入了不可能區域，項目麵臨失敗風險，但是如果延長交付時間，可以降低工作量和成本。
PNR曲線表明了完成一個項目的時間與投入該項目的工作量之間是高度非線性的關係。因此，工作量與開發時間、交付的代碼（源代碼行數）可以用下麵的公式表示。E=L3P3t4其中，E是在軟件開發和維護的整個生命周期內所需要的工作量（按人年計算）；L是交付的源代碼行數。t是以年為單位的開發時間。P是一個生產率參數，它反映了軟件工程工作的各種因素的綜合效果(P通常在2 000到12 000之間取值)。
3. 軟件項目進度安排表示
軟件項目的進度安排一般以圖形的方式展現。圖中要明確標明各個任務的計劃開始時間、完成時間、各個任務完成的標誌、各個任務參與的人數及各個任務所需要的資源等。為了體現這些要求，一般進度管理使用裏程碑圖、網絡圖、甘特圖和資源圖等表示。
（1） 裏程碑圖
裏程碑圖顯示項目進展中的重大工作完成。裏程碑不同於活動，活動是需要消耗資源的，並且需要時間來完成。裏程碑僅僅表示事件的標記，不消耗資源和時間。裏程碑圖對項目幹係人是非常重要的，它表示了項目進展過程中的幾個重要的時間節點。
（2） 網絡圖
主要展示項目中的各個活動以及活動之間的邏輯關係，網絡圖是活動排序的一個輸出，可以表達活動的曆時。常用網絡圖有PDM（Precedence Diagram）節點法網絡圖、ADM（Arrow Diagram）箭線法網絡圖、CDM（Condition Diagram）條件箭線法網絡圖。
PDM（節點法）網絡圖在網絡圖中一個活動用一個方框、節點或者其他方式表示。每一個活動被各種關係線相連接著，表示各個活動的邏輯關係。網絡圖開始於一個任務、工作、活動、裏程碑，結束於一個任務、工作、活動、裏程碑，有些活動有前置任務或者後置任務。如圖314所示。
圖314PDM網絡示意圖
ADM也稱為AOA （ActivityonArrow）或者雙代號項目網絡圖。在ADM網絡圖中,箭線表示活動(工序或工作)，虛線箭頭表示虛擬活動，指實際不存在的活動。引入虛擬活動的目的是為了顯示地表示活動之間的依賴關係。節點Node表示前一道工序的結束,同時也表示後一道工序的開始，隻適合表示結束—開始的邏輯關係，如圖315所示。
圖315ADM示意圖
CDM網絡圖也稱為條件箭頭圖法網絡圖。CDM允許活動序列相互循環與反饋，從而在繪製網絡圖的過程中形成許多條件分支。但在PDM、ADM中是不允許的。
（3） 甘特圖
甘特圖可以顯示基本的任務信息，可以查看任務的工期、開始時間和結束時間以及資源的信息，有兩種表示方法(棒狀、三角形)。如圖316所示，空心棒狀圖表示計劃起止時間，實心棒狀圖表示實際起止時間；用棒狀圖表示任務進度時，一個任務需要兩行的空間表示。
圖316一種甘特圖
另外一種表示甘特圖的方式，如圖317所示。它是用三角形表示特定日期，方向向上三角形表示開始時間，向下三角形表示結束時間，計劃時間和實際時間分別用空心三角形和實心三角形表示。一個任務隻需要占用一行。
圖317另一種甘特圖
圖318是采用軟件工具Microsoft Visio繪製的一個項目的甘特圖。
圖318某個項目的甘特圖
4. 軟件項目進度計劃編製原理
關鍵路徑法(Critical Path Method,CPM)和計劃評審技術(Program Evaluation and Review Technique,PERT)是項目計劃管理的重要方法。這兩種方法都采用網絡圖來描述一個項目的任務網絡。即從一個項目的開始到結束，把應當完成的任務用圖的形式表示出來。但PERT方法要求對每個任務的完成時間做三次估計，而不是一次估計。
最可能的時間：期望任務在正常情況下所花的時間，用字母m來表示。
樂觀的時間：期望完成任務的最短時間(除非出現明顯的奇跡)，用字母a來表示。
悲觀的時間：考慮所有合理的可能情況下的最壞可能時間，用字母b來表示。
因此，PERT使用下麵公式來計算各個任務的持續期望時間為：t=(a+4m+b)\/6
方差 σ2=b-a62PERT認為整個項目的完成時間是關鍵路徑上各個任務的期望完成時間之和，且服從正態分布。假設關鍵路徑上有s個活動，這s個任務的方差分別為σ12,σ22,…，σs2,則關鍵路徑的方差就是這s個活動的方差之和，即σ12+σ22+ …+σs2。
求出項目的工期的期望值和方差之後，一般假設服從正態分布，可以通過查標準正態分布表，得出項目在某一時間內完成的概率。例如假設按照PERT方法求出項目工期的期望值T=60天，標準差σ=3.696，如果客戶要求在70天內完成項目，那麼可能完成的概率是：P(t≤70)=Φ((70-60)\/σ))≈0.996 6CMP方法首先要繪製網絡圖，在繪製網絡圖時需要遵循以下約定：
① 網絡圖是有向圖，本章節采用ADM（Arrow diagram）圖，任務(活動)用箭頭表示，箭頭上可以標上完成該任務的所需要的時間。事件用結點表示，事件表示流入該結點的任務已經完成，流出該結點的任務可以開始。事件的符號如圖319所示。事件本身不消耗資源和時間，僅代表某個時間點。圖319事件的符號
② 按照項目執行任務的順序把任務從左向右排列。
③ 兩個事件之間僅可存在一條箭頭。
④ 網絡圖中不能有回路。
⑤ 為了表示任務之間先後順序關係可以引入空任務（用虛線箭頭表示），空任務完成時間為零。
⑥ 為了表示項目的開始和結束，在網絡圖中隻能有一個終點和一個始點。
⑦ 網絡圖中不能夠包含懸點，既不是終點而且沒有流出任務的結點。
⑧ 每個事件用一個事件編號進行標記，一般按照各個結點的事件順序編號。
事件的最早時刻和最遲時刻的定義如下:
最早時刻表示所有到達該事件的任務最早在此時刻完成，或者從該事件流出的任務最早在此時刻才可開始。
最遲時刻表示所有到達該事件的任務最遲必須在此時刻完成，或從該事件流出的任務必須在此時刻開始，否則整個項目就無法按時完成。
下麵給出找關鍵路徑的步驟：
（1） 計算事件最早時刻EFT
設(i，j)為連接事件i和事件j的任務，t(i,j)為任務(i,j) 的持續時間，I為所有任務的集合，設起始事件為0號事件，n號事件為結束事件。設tE(j)為事件j的最早時刻，規定tE(0)=0,從左到右按事件發生的順序計算每個事件的最早時刻，那麼就有事件j的最早時刻為：tE(j)=max{tE(i)+tE(i,j)}，(i，j)∈I最早時刻計算如圖320所示。
圖320最早時刻計算
圖320中的tE(d)=max{tE(a)+ta，tE(b)+tb,tE(c)+tc}。
設有圖321所示的為待求解的網絡圖，用上述公式計算得到的各事件最早時刻如圖322所示。
圖321待求解的網絡圖
圖322求出最早時刻的網絡圖
（2） 計算事件最遲時刻LET
為了盡量縮短項目的完工時間，把終結點的最早時間，即項目的最早結束時間作為終結點的最遲時間。tL(i)表示事件i的最遲時刻，設事件編號n為最後一個事件，則有：tL(n)=tE(n)可從右向左按事件發生的逆序計算每個事件的最遲時刻，事件i的最遲時刻為：
tL(i)=min{tL(j)-t(i,j)}，（i，j）∈I以圖322為例，利用上麵公式可以計算出每個事件的最遲時刻如圖323所示。
圖323求出最晚時刻和最早時刻的網絡圖
（3） 計算機動時間
事件i和事件j之間的任務為(i，j)，其機動時間為:tL(j)-tE(i)-t(i,j)對上麵的網絡圖，各個任務的機動時間如圖324所示，標在箭頭線括號中。
圖324求出機動時間的網絡圖
（4） 關鍵路徑
機動時間為零的任務（活動）組成了整個工程的關鍵路徑。組成關鍵路徑的任務所需要的實際完成時間不能超過整個項目的預定時間。如圖324所示粗線箭頭表示的路徑就是該網絡圖的關鍵路徑。了解項目關鍵路徑的意義在於：必須保證關鍵路徑上任務所需要的資源，保證關鍵路徑上的任務順利執行。因此，要縮短項目工期必須縮短關鍵路徑上任務的完成時間。對不處於關鏈路徑上的活動，可以根據需要調整其起止時間或者延長任務時間。
（5） 跟蹤進度
在項目開發過程中，必須根據項目進度表，跟蹤和控製各項任務的實際執行情況，一旦發現某個任務（特別是關鍵路徑上的任務）未在計劃進度規定的時間內完成，那麼就要采取措施進行調整，此時可能要增加額外的資源，增加或調整新的員工或者調整項目進度表。
3.3風險管理
軟件開發幾乎總是要冒一定的風險，例如，產品交付給用戶之後用戶可能不滿意，到了預定的交付日期軟件可能還未開發出來，實際的開發成本可能超過預算，產品完成前一些關鍵的開發人員可能跳槽，產品投入市場之前競爭對手發布了一個功能相似、價格更低的軟件等。軟件風險是任何軟件開發項目中普遍存在的實際問題。軟件風險經常導致軟件項目延遲、超預算、質量下降、甚至失敗。因此，在軟件開發過程中必須及時識別風險、分析風險、規避風險、監控風險，並且采取適當的措施消除或減少風險的危害。風險管理是軟件項目管理的重要組成部分，是項目相關人員都需要認真思考的問題。一個成功的項目經理，必須也是一個成功的風險管理者。
3.3.1軟件風險管理過程
可能性和損失是風險的兩個基本屬性。可能性表示風險有多大的概率發生，或者稱為不確定性；損失表示風險事件造成的結果多大。風險是對項目成功造成威脅的潛在問題，這些潛在問題雖然還沒有發生，但是它們會影響成本、進度、質量等成功要素。風險不僅是項目計劃中的一個部分，還要求在開發過程中對它進行跟蹤、報告及更新。
風險管理過程如圖325所示，該過程包含以下幾個階段：
圖325風險管理過程
第一階段：風險識別，識別各類風險。
第二階段：風險分析階段，評估這些風險出現的可能性及其後果。
第三階段：風險規劃，製定計劃說明如何規避風險或最小化風險對項目的影響。
第四階段：風險監控，定期對風險和緩解風險的計劃進行評估，並隨著有關分析信息的增多及時修正緩解風險的計劃。
風險管理過程的結果應該記錄在風險管理計劃中。風險管理過程也是一個迭代進行的過程，風險管理並不是一次性活動。從最初的計劃製定開始，項目就處於被監控狀態以及檢測可能出現的風險，並持續於整個項目生命周期。隨著有關風險信息的增多，需要重新進行分析，重新確定風險的優先級，對風險規避和應急計劃要進行修正。
3.3.2風險識別
風險識別是風險管理的第一步，這一步主要是發現可能對軟件工程過程、正在開發的軟件或開發機構產生重大威脅的風險，通過項目組成員的集體討論或者憑借項目管理者的經驗識別出這些風險。
有些風險是共性風險，即它們與所有軟件項目相關，可以使用標準檢查單並通過對過去項目的分析來標識它們。這些風險包括對需求誤解或關鍵員工生病。還有一些與個別項目相關的特定風險，如果沒有項目組成員的參與以及沒有鼓勵風險評估的工作環境，則可能很難標識這些風險。
要充分識別出項目中存在的風險，需要借助於一些工具和方法，下麵介紹幾種常用的方法。
1. 風險檢查表
風險檢查表是風險識別的重要工具之一，它能為識別風險提供係統的方法。檢查表主要是根據風險分類和每類包含的要素進行編寫的，各個公司可以根據項目實際情況來編寫風險檢查表，或者參考一下其他公司風險檢查表來進行裁剪以適用項目的需要。常見的軟件風險如表328所示。表328風險類型表
風險類型可能的風險技術係統使用的數據庫處理速度不夠快。要複用的軟件組件有缺陷，限製了項目的功能。人員招聘不到符合項目技術要求的職員，在項目的生命期內，關鍵性員工生病，不能發揮作用。機構機構調整，由不同的管理層負責該項目，開發機構財務出現問題，必須追加項目預算。工具CASE工具不能被集成或產生的編碼效率低。需求需求發生變化，主體設計要返工，客戶不了解需求變更對項目造成的影響。估算低估了軟件開發工期，低估了軟件規模。２. 調查問卷法
調查問卷法是提出一係列問題讓參與者考慮，通過參與者的回答來判斷項目中是否存在相關的風險。
３. WBS法
WBS法是風險識別的一個工具，項目風險與項目任務不可分割，因此這種方法主要是根據項目已經分解的WBS，針對每個任務識別出相關的風險。
４. 頭腦風暴法
由項目小組成員在一起，不受項目權威的影響，每個人充分發揮自己的能力思考項目中可能的風險，自由討論和發言，充分預測項目中出現的各種情況，最終彙總成為項目的風險表。
不管采用什麼樣的方法和工具，風險識別最終都有一個輸出結果：風險管理表。
3.3.3風險分析
標識了影響項目的風險後，需要一些方法來評估風險的重要性。有些風險相對來講並不重要（例如某些文檔延期一天交付的風險)，而有些風險則是非常重要的(例如，軟件延期交付的風險)。有些風險很可能發生(例如，在一個周期較長的項目中，很可能出現團隊中的軟件開發人員請幾天病假的情況)，而其他風險相對而言很可能不會發生(例如，硬件故障導致丟失已經完成的代碼)。顯然，風險很多，無法計劃每個可能的危險，因此需要根據重要性的度量來對風險的優先級排序。度量可以從三個方麵開展，風險發生的概率、影響和二者的綜合結果。
1. 定性分析
定性分析是對風險發生的概率和影響都采用定性的方法進行描述。例如表329所示。表329風險概率影響矩陣
概率
影響非常高高中等低非常低災難性的高高中等中等低嚴重的高高中等低低輕微的中等中等低無無可忽略的中等低低無無風險發生的概率介於0到1之間，定性分析方法把風險概率分為“非常低、低、中等、高、和非常高”5類，或者簡單低分“高、中、低”3類。
對於風險對項目造成的後果，按照嚴重性也可以分為“非常低、低、中等、高、和非常高”5類，或者簡單低分“高、中、低”3類，或者“可忽略、輕微的、嚴重的、災難性的”4類。
確定了概率和影響之後，確定風險的綜合影響結果，根據概率和影響的評估得出概率影響矩陣。
根據風險綜合結果矩陣可以進行風險優先級排序。
2. 定量分析
定量分析常用的方法是計算風險暴露量。風險暴露量=風險的概率×風險的損失。該指標是進行風險排序的重要依據。風險影響根據項目的目標采用不同的單位，比如把風險影響折算成對項目時間的影響。對於項目風險概率，定量分析的結果就是給出0到1之間的數值，如表330所示。表330計算風險暴露量
風險發生的概率損失的大小\/周風險暴露量關鍵員工離職0.351.5設計欠佳返工0.2204低估了軟件規模0.51053. 風險概率和影響的確定
不論是定性分析或定量分析，項目風險的概率和影響確定有三種常用方法：一是由最熟悉相關風險的專家進行評估；二是德爾菲（Delphi）法，這個方法是通過反複使用調查問卷，從一組專家中取得一致的意見；三是少數服從多數法，由項目組成員來進行估算，然後根據大家的估算結果采用少數服從多數的原則來統一結果。
4. 風險優先級排序
根據風險暴露量、概率影響矩陣可以確定風險的優先級，以便明確風險管理的重點。根據2\/8定律，要重點關注排在前20%的風險，因為這些風險對項目的損失占80%。
3.3.4風險管理計劃
風險分析完成之後就進入風險控製階段，風險控製階段的第一步是風險管理計劃的製定。風險管理計劃的主要內容包含:
（1） 說明風險為什麼很重要，因為執行計劃的人可能並沒有參與計劃的編製。
（2） 為了追蹤風險的狀態什麼信息是必需的。風險表現形式是什麼，也就是風險征兆是什麼，誰來提供這些信息等。
（3） 誰來負責此風險管理活動。
（4） 為了執行風險管理計劃需要什麼資源。
（5） 風險可能什麼時間發生，在哪裏發生，怎樣發生，怎麼樣應對風險，如何實施計劃，應對風險的成本是多少等。
為了消除或減弱風險，往往製定兩類計劃，一個是行動計劃，一個是應急計劃。行動計劃是通過迅速防禦來降低或者消除風險的影響或者發生的概率，以此來化解風險。應急計劃是指如果采取正常的風險應對行動計劃，風險仍然沒有化解掉，那麼在風險監控中就要引入一個事先準備好的應急計劃。
3.3.5風險應對
風險管理計劃製定後，就要執行計劃，進入風險應對階段。應對的策略主要包括：
（1） 規避風險。不做冒險的活動，通過計劃的變更來消除風險或者消除風險發生的條件，保護目標免受風險的影響。例如表331中處理有缺陷的組件風險策略。
（2） 最小化策略。采用這些策略就會減少風險的影響。例如表331中的解決職員生病的策略。
（3） 應急策略。采用這些策略就算最壞的事情發生，有適當的對策處理。例如表331中的應對機構的財務問題的策略就屬於這一類策略。
（4） 風險轉移策略。
（5） 消除風險產生的根源。表331風險應對策略
風險策略機構的財務問題擬一份簡短的報告，提交高級管理層，說明這個項目將對業務目標有重大貢獻。職員生病問題重新對團隊進行組織，使更多工作有重疊，員工可以了解他人的工作。有缺陷的組件用買進的可靠性穩定的組件更換有潛在缺陷的組件。需求變更導出可追溯信息來評估需求變更帶來的影響，把隱藏在設計中的信息擴大化。數據庫的性能研究一些購買高性能數據庫的可能性。低估了開發時間對要買進的組件、程序生成器的效用進行檢查。3.3.6風險監控
風險管理的最後一步是風險監控。在項目的進行過程中，很多意想不到的事情會導致風險不按照原計劃中預先設定的消滅或減輕風險的路線前進。風險在項目的推進過程中，可能會增大或減弱，所以需要進行風險監控來檢查每個風險的化解程度，如果化解是無效的，要及時調整應對策略，並識別可能出現的新風險。風險監控主要完成以下工作：① 不斷地跟蹤風險發生的變化；② 不斷地識別新的風險；③ 不斷分析風險的產生概率；④ 不斷地整理風險表；⑤ 不斷地規避優先級高的風險。
3.4質量管理
隨著軟件日益融入人們生活的方方麵麵，人們對軟件質量越來越關心，對軟件質量的要求越來越高。現如今，軟件質量仍然是個需要研究和解決的問題。
3.4.1軟件質量的定義
什麼是質量？哈佛商學院的David Garvin 給出了建議：“質量是一個複雜多麵的概念”，不同的人從各自的視角會有不同的理解和要求。對於用戶來說，他們更關心的是係統的功能質量，比如說，是否滿足了自己的需求，是否存在影響使用的缺陷，軟件性能如何，以及是否容易使用等。對於開發人員，他們更多關心的是係統的結構質量，主要包括代碼的可讀性、可測試性、可維護性以及效率和安全等方麵的因素。對於投資者，他們更為關心軟件開發的過程質量，例如，項目是否可以在規定的時間和預算內交付，最終產品的交付質量是否可以保證等。從產品的觀點來說，質量是產品的固有屬性，比如功能特性。
一般意義上，軟件質量定義為：在一定程度上應用有效的軟件過程，創造出有用的產品，為使用者提供明顯的價值。即：軟件質量應該涵蓋軟件過程、軟件產品和產品效用三個方麵。軟件過程用過程質量來衡量，軟件產品包括內在質量和外在質量兩部分，產品效用，用使用質量來衡量。三者相輔相成，過程質量會影響到軟件產品內在的代碼質量，而代碼質量的好壞決定了產品的外在質量，外在質量最終影響到用戶的使用質量，因此必須用有效的方法來檢驗整個開發過程、程序代碼和最終產品，並對用戶的使用質量進行監測。
質量大師傑溫伯格在《質量·軟件·管理係統思維》說到：“質量就是軟件產品對於某個（或某些）人的價值”（某個或某些人，統稱之為用戶），這裏麵包含兩個層次的質量含義，即“正確的軟件”和“軟件運行正確”。
“正確的軟件”是說，一個軟件要能夠滿足用戶的需求，為用戶創造價值。此處的價值可以體現在兩個方麵，一是為用戶創造利潤，二是減少成本。如果一個軟件能夠滿足的用戶群體越大、創造的利潤越大或減少的成本越大，則該軟件產品的質量越高。反之，一個產品盡管運行良好，沒有Bug，擴展性很強，性能很好，但如果沒有用戶，沒有為用戶創造價值，則這樣的軟件盡管運行良好，也無任何質量可言。舉個例子，曾經引發全球熱潮的穀歌眼鏡，從2015年1月19日開始不再接受訂單，與此同時穀歌還關閉了“探索者”(Explorer)這個軟件開發項目,除了銷售策略欠佳方麵的原因，由於需求調研不足，穀歌自己也不清楚穀歌眼鏡存在的目的,產品過於超前，再加上價格昂貴等因素，使得這款看起來酷的產品很快失去了用戶。
“軟件運行正確”是指軟件沒有或有很少Bug、擴展性很強、性能良好、易用性高等，這樣的軟件是一個運行良好的軟件，但還不能稱之為高質量的軟件。隻有在軟件符合用戶的需求的基礎上，運行良好的軟件，才是一個高質量的軟件。當然，如果軟件完全符合用戶需求，但不易使用，經常出錯，性能很差，這樣的軟件也不是一個高質量的軟件。舉個例子，微軟的Vista係統，這是一個典型的“運行不正確”的軟件，Vista係統應該說是用戶非常期待的，也是滿足用戶需求的，但是由於莫名其妙的死機，以及很差的運行效率等一係列缺陷，最終導致許多用戶棄用，微軟不得不在兩年之後用Window 7取代了Vista。
“正確的軟件”及“軟件運行正確”二者相輔相成，前者關係到軟件的成敗，後者關係到軟件的好壞。現實的很多開發團隊，特別是偏重技術的開發團隊中，往往過分注重後者（軟件的Bug率、性能、可擴展性、架構等），經常陷入在軟件開發過程的細節之中，而忽略了前者（軟件需要符合用戶的需求），開發出的軟件經常能用但無用，不是最終用戶期望的軟件，這樣的軟件雖然能用但無用，是零質量軟件。
3.4.2評價質量
在理解了質量的基本含義之後，下一步要考慮應該如何評價質量？目前有很多質量模型，它們分別定義了不同的用來評價軟件質量的質量屬性。
1. Garvin模型
David Garvin提出了一種多維度的質量評價模型，從8個維度即8個質量屬性，反映了產品質量的不同方麵，這8個屬性分別是：性能、特色、可靠性、符合性、耐久性、可服務性、外觀性、感知性，可以通過改善產品的各個質量屬性來提高整個產品的質量。盡管Garvin沒有專門為軟件製定質量模型，但是評價軟件質量時依然可以使用。
Garvin所提出的8個軟件質量屬性中，多數隻能主觀地評價。因此需要一些能夠直接或間接測量的因素，把測量數據和一些基準數據進行比較，從而較為客觀地確定軟件質量。
2. McCall模型
McCall的軟件質量模型，使用3種視角如表332所列來定義和識別軟件產品的質量，分別是：產品修正(承受可改變的能力)，產品運行(基本操作特性)，產品轉移（對新環境的適應能力）。表332McCall質量模型屬性
視角質量屬性含義產品修正可維護性為滿足用戶新的要求或當環境發生了變化或運行中發現新的錯誤時，對一個已經投入運行的軟件相應診斷和修改所需要的工作量的大小。可測試性測試軟件以確保其能夠執行規定功能所需工作量的大小。靈活性修改一個運行的程序所需的工作量。產品轉移可移植性將程序從一個硬件和軟件係統環境移植到另一個環境所需要的工作量。可複用性一個軟件或軟件的部件能再次用於其他應用的程度。互連性將一個係統連接到另一個係統所需要的工作量。產品運行正確性在預定環境下，軟件滿足設計規格說明書和完成用戶任務目標的程度。可靠性軟件在規定時間和條件下不出故障，持續運行的程度。效率為了完成預定功能，軟件係統所需要的計算機資源的多少。可使用性對於一個軟件係統，用戶學習、使用軟件及為程序準備輸入和解釋輸出所需工作量的大小。完整性為某一目的而保護數據，避免它受到偶然的或有意地破壞、改動或遺失的能力。3. ISO9126模型
ISO9126模型是一種評價軟件質量的通用模型，它定義了軟件的6個質量屬性，分別是：功能性、可靠性、易用性、效率或性能、可維護性和可移植性。每一個屬性又細分成一係列子屬性。如表333所示。
功能性是指軟件滿足已確定要求的程度，包括適合性、準確性、互操作性和安全性4個子屬性。比如說，購物網站上購買商品，像關鍵字搜索、商品瀏覽、選購商品、生成產品訂單等都是用戶需要的主要功能。訂單費用的結算也必須是運行準確的，同時這個係統還會和銀行卡支付係統進行交互，係統也要保證用戶賬號的安全。
可靠性指的是係統是否能夠在一個穩定的狀態下滿足用戶的使用，那麼這就意味著軟件要有代碼出錯的處理能力。當外部出現異常錯誤時，軟件能夠對異常進行處理保持正常的運行狀態。或者在軟件失效時，係統能夠重新恢複到正常的運行，同時恢複受直接影響的數據。
易用性：是指在規定的條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力。軟件的易用性是用戶在使用過程中所實際感受到的係統質量，它會直接影響到用戶對產品的滿意度。
性能也是影響產品質量的一個重要因素，通常從時間特性和資源使用兩個方麵來衡量。比如說，我們打開一個商品網頁瀏覽商品，希望係統對用戶請求具有快速的響應和處理，同時消耗的係統資源和網絡帶寬比較低。
可維護性是用於衡量軟件產品被修改時，需要花費多大的努力。
可移植性是指軟件從一種環境遷移到另一種環境的難易程度。可維護性和可移植性這兩個屬性，對於開發人員來說很重要的。表333ISO9126模型屬性
功能性適合性軟件提供了用戶所需要的功能，同時軟件提供的功能也是用戶所需要的。準確性是指軟件提供給用戶功能的精確度是否符合目標。互操作性軟件和其他係統進行交互的能力。安全性軟件保護信息和數據的安全能力。可靠性成熟性軟件產品避免因軟件中錯誤發生而導致失效的能力。容錯性軟件防止外部接口錯誤擴散而導致係統失效的能力。可恢複性係統失效後，重新恢複原有的功能和性能的能力。易用性易理解性軟件顯示的信息要清晰、準確且易懂，使用戶能夠快速理解軟件。易學習性軟件使用戶能學習其應用的能力。易操作性軟件產品使用戶能易於操作和控製它的能力。吸引性軟件具有的某些獨特的、能使用戶眼前一亮的屬性。效率時間特性在規定的條件下，軟件產品執行其功能時能夠提供適當的響應時間、處理時間以及吞吐率的能力。資源利用軟件係統在完成用戶指定的業務請求所消耗的係統資源，如CPU占有率、內存占有率、網絡帶寬占有率等。可維護性易分析性軟件提供輔助手段幫助開發人員定位缺陷原因並判斷出修改之處。易改變性軟件產品使得指定的修改容易實現的能力。穩定性軟件產品避免由於軟件修改而造成意外結果的能力。易測試性軟件提供輔助性手段幫助測試人員實現其測試意圖。可移植性適用性軟件產品無需做任何相應變動就能適用不同運行環境的能力。易安裝性在平台變化後，成功安裝軟件的難易程度。共存性軟件產品在公共環境與其共享資源的其他係統共存的能力。替換性軟件係統的升級能力，包括在線升級、打補丁升級等。4. Boehm軟件質量模型
Boehm認為應從軟件的易使用性、可維護性和可移植性來評價軟件產品的質量。
Boehm質量模型把軟件質量的概念分解為若幹層次。具體地，易使用性反映用戶的滿意程度；可維護性從可測試性、可理解性、可修改性三個側麵進行度量，反映開發人員的滿意程度；而可移植性被單獨劃分為一個屬性。
5. ISO／IEC 250102014軟件質量模型
綜合以上的各種軟件質量模型，軟件質量評價屬性很多，但是這些屬性要求都定義在不同的標準中，使得用戶在綜合使用這些標準時存在很大的困難。同時，標準之間也存在不一致或者不協調的方麵。意識到這些問題後，國際標準化組織ISO和IEC的聯合技術委員會軟件工程分技術委員會，ISO／IECJTC1／SC7整合相關的標準，提出了係統與軟件質量要求和評價SQuaRE(Systems and Software Quality Requirements and Evaluation)係列標準，並以25000作為這些標準的統一編號。SQuaRE係列標準包括質量管理分部、質量模型分部、質量要求分部、質量評價分部和擴展分部。其中，質量模型分部給出了軟件產品質量模型、使用質量模型和數據質量模型。
ISO／IEC 25010質量特性規定了產品質量模型，由8個質量屬性組成。這8個屬性是功能適合性、性能效率、兼容性、易用性、可靠性、信息安全性、維護性、可移植性。
ISO／IEC 25010質量特性規定了使用質量模型，由5個質量屬性組成。5個屬性是有效性、效率、滿意度、抗風險性、周境覆蓋度。
3.4.3軟件質量困境
軟件質量的重要性毋庸置疑，軟件工程團隊應該生產高質量的軟件，那麼是不是質量越高就越好？或者說軟件產品是不是應該追求“零缺陷”？
不同的使用環境對軟件質量的要求不一樣。對於實時嵌入式軟件、航天軟件或者與硬件集成的應用軟件來說，如果在軟件使用時出現問題就會造成巨大的損失，所以使用之前，隻要發現任何異常就會立即排查，直到異常被消除為止。在這種情況下，軟件的質量越高越好，軟件產品追求的是“零缺陷”。而許多互聯網和遊戲軟件，如微信、QQ、百度導航等，在產品還存在一定缺陷的情況下，就發布上線，之後再不斷地更新版本、修複已有的缺陷，似乎在這種情況下，用戶也是可以接受一個有缺陷的軟件產品的。那麼為什麼這種係統不像航天係統一樣需要在發布之前修複所有發現的任何缺陷呢？顯然不能拋開商業目標來談論產品質量。企業的根本目標是要獲得盡可能多的利潤，為了提高用戶對產品的滿意度，企業必須提高產品質量，但是也不可能為了追求完美的質量而不惜一切代價。質量是有成本的，當企業為提高質量所付出的代價超過了產品收益時，這個產品也就沒有商業價值了。因此企業必須權衡質量、效率和成本三個因素，產品質量太低或太高，都不利於企業的長遠發展。理想的質量目標不是“零缺陷”，而是恰好讓用戶滿意，並且將提高質量所付出的代價控製在預算之內，也就是提供 “足夠好”的軟件。
3.4.4軟件質量實現
軟件質量是如何實現的？或者說如何才能有效地提高軟件質量？良好的軟件質量不會自己出現，它是良好的項目管理和紮實的軟件工程實踐的結果，需要軟件工程方法、項目管理技術、質量控製活動以及軟件質量保證等支持。
軟件開發過程包括了分析、設計、實現、測試等一係列活動。測試是檢驗軟件產品的一個重要的手段，實際上，到測試階段軟件質量的問題發生已經很難進行糾正。所以說，質量並不是測出來的，而是在開發過程中逐漸地生長起來的。軟件開發過程中的每一個階段對於保證軟件質量都至關重要，完整準確的需求分析、高質量的設計、高質量代碼的構建等是每一個軟件工程師義不容辭的責任。當然測試也是開發過程中不可缺少的一個重要環節。一般對於軟件開發來說，高質量的設計、規範的編碼以及有效的測試是保證軟件產品質量的三個重要方麵，也是提高軟件質量的必要手段。
此外，良好的項目管理技術對於提高軟件質量也是不可缺少的。項目經理使用估算確認交付日期，避免了因為趕進度而放棄高質量；進度依賴關係清楚了，團隊能夠有條不紊地開發，避免了走捷徑的企圖；進行了風險規劃，這樣出現問題就不會引起混亂，手忙腳亂，軟件質量才不會受到不利因素的影響。
3.4.5質量管理計劃
質量計劃是進行質量管理的綱領性文件，軟件項目質量計劃就是要將與項目有關的質量標準標識出來，提出如何達到這些質量標準和要求的設想。它是項目計劃的組成部分之一，並與其他的項目計劃編製過程同時進行。
1. 軟件質量標準
標準主要包括技術標準和業務標準兩大類。技術標準包含兩個方麵：一是作為軟件開發企業的軟件行業技術標準，包括知識體係指南、過程標準等；二是軟件開發服務對象所在的行業技術標準，例如，安全保密標準、技術性能標準。業務標準指的是軟件開發服務對象所在的組織或行業製定的業務流程標準和業務數據標準等。運用統一的技術與業務標準，有助於減少無效的討論，有助於不同產品之間的兼容和銜接。
編製軟件質量計劃的一個重要工作就是確定開發軟件產品和過程的標準。產品標準定義了所有產品組件應該達到的特性，而過程標準則定義了軟件過程應該怎麼執行。
IEEE、ISO及其他標準化組織製定了一係列廣泛的軟件工程標準和相關文件。標準可能是軟件工程組織自願采用的，或者是客戶或其他利益相關者要求采用的。
2. 質量計劃的要求
質量計劃應說明項目管理小組如何具體執行它的質量策略。質量計劃的目的是規劃出哪些是需要被跟蹤的質量工作，並建立文檔，此文檔可以作為軟件質量工作的指南，幫助項目經理確保所有工作按計劃完成。作為質量計劃，應該滿足下列要求：確定應達到的質量目標和所有特性的要求；確定質量活動和質量控製程序；確定項目不同階段中的職責、權限、交流方式及資源分配；確定采用控製的手段、合適的驗證手段和方法；確定和準備質量記錄。
3. 質量計劃的編製
軟件項目的質量計劃會根據項目的具體情況來決定采取的計劃形式，沒有統一的規定。有的質量計劃隻是針對質量保證的計劃，有的質量計劃既包括質量保證計劃，也包括質量控製計劃。質量保證計劃包括質量保證(審計、評審軟件過程、活動和軟件產品等)的方法、職責和時間安排等；質量控製計劃主要包括代碼走查、單元測試、集成測試、係統測試等安排。
編製質量計劃的主要依據是公司的軟件質量方針、軟件範圍描述、軟件產品描述、領域的標準和準則。
3.4.6軟件質量保證
軟件質量保證是適用於整個軟件過程的一種保護性活動，而不是在編碼完成之後才開始考慮的事情。軟件質量保證是以獨立審核方式，從第三方的角度監控軟件開發任務的執行，檢查軟件項目是否遵循已經製定的計劃、標準和規程，給開發人員和管理層提供數據和信息。這些信息和數據主要反映產品和過程的質量，同時輔助軟件開發團隊取得高質量的軟件產品。
軟件質量保證的工作主要由軟件質量保證小組負責完成。質量保證小組不屬於開發團隊成員，但是要全程參與軟件開發活動。質量保證小組成員要有很高的素質，具體來說要有很強的溝通能力，熟悉軟件開發過程，能應對繁雜的工作，工作要有計劃性，有責任心，要客觀。
軟件質量保證的工作內容有：① 編製質量保證工作計劃，組織評審該計劃，把通過評審的計劃發送給項目經理、項目開發人員和所有相關人員；② 參與項目的階段性評審和審計；③ 檢查項目的日常活動是否符合規程；④ 檢查和審計配置管理工作；⑤ 記錄各種不符合項並報告給高層管理人員，對評審中發現的問題和項目日常工作中發現的問題進行跟蹤，直至解決；⑥ 收集新方法，提供過程改進的依據；⑦ 收集和分析軟件度量。
3.4.7軟件質量控製
軟件質量保證是從項目外部確保軟件開發團隊按照製定的計劃和標準來執行項目，而軟件質量控製則是從團隊內部來保證軟件產品和過程的質量，是發現和消除軟件缺陷的一種活動。質量控製應該貫穿於項目的全過程，不僅對最終的軟件產品進行控製，也需要對生產軟件的過程進行控製。軟件缺陷有放大效應，所以軟件質量控製應該盡早開始。
軟件質量控製的主要活動包括技術評審、代碼走查、代碼評審、單元測試、集成測試、係統測試和缺陷追蹤等。
1. 技術評審
技術評審的目的是盡早地發現工作成果中的缺陷，並幫助開發人員及時消除缺陷，從而有效地提高產品的質量。
技術評審可以在任何開發階段執行，它能比測試更早地發現並消除工作成果中的缺陷。越早消除缺陷就越能降低開發成本。此外，通過技術評審，開發人員能夠及時地得到專家的幫助和指導，加深對開發工作和成果的理解，更好地預防缺陷，在一定程度上能夠提高開發效率。如果缺乏技術評審，到了測試階段往往會導致缺陷大量出現，使得開發人員不得不加班消除錯誤，開發效率受到影響。
2. 代碼走查
代碼走查是一種非正式的代碼評審技術，正規的做法是把代碼打印出來，邀請別的同行開會檢查代碼的缺陷。這種方法太消耗時間，所以實際中常常是在編碼完成之後將自己寫的代碼的邏輯和寫法向同事講解，然後同事給出意見，分析找出程序的問題。
3. 代碼評審
代碼評審是代碼編寫者講解自己的代碼，由專家或項目組其他成員及項目經理來做評審，期間有不了解之處隨時提問並提出意見。如果把代碼走查看成是開發人員的質量控製，那麼代碼審查是更高一層的質量控製。要讓代碼審查起到應有的效果，一是要做好計劃；二是評審要分重點和層次，先是自查，後是組內的評審，最後是外部評審；三是做好問題的確認和跟蹤。
4. 軟件測試
軟件測試是軟件項目中最基本的質量控製手段。軟件測試的目的是盡可能地發現軟件的缺陷，而不是證明軟件是正確的。一般測試過程包括測試計劃、測試的組織、測試用例設計、測試的執行和測試報告。軟件測試的方法主要有白盒測試和黑盒測試，前者主要關注程序內部的邏輯結構，後者主要關注程序的運行結果。軟件測試的類型主要有：單元測試，集成測試、功能測試、係統測試、驗收測試、安裝測試、性能測試、安全性測試、配置測試、兼容性測試、國際化測試、本地化測試、α\/β測試、易用性測試等。
5. 軟件缺陷跟蹤
從發現缺陷開始，一直到缺陷改正為止的全過程稱為缺陷跟蹤。缺陷跟蹤的意義在於確保每個被發現的缺陷都被解決。軟件缺陷管理過程中所收集到的缺陷數據對評估軟件係統的質量、測試人員的業績、開發人員的業績等提供了量化的參考指標，也為軟件企業進行軟件過程改進提供了必要的案例積累。
為了及時清除缺陷且不遺漏缺陷，需要對缺陷進行描述，既要描述缺陷的基本信息，如缺陷的內容，也要描述缺陷的追蹤信息，如缺陷的狀態。描述缺陷的信息通常有：缺陷ID、缺陷狀態、缺陷嚴重程度、缺陷緊急程度、缺陷提交日期、缺陷解決人、缺陷解決時間、缺陷處理結果、缺陷確認人、缺陷確認時間等。對於大型軟件項目而言，測試過程缺陷的總數可能成千上萬，所以往往采用缺陷跟蹤管理信息係統來支持缺陷管理。
6. 統計質量保證
質量的量化在產業界有不斷增長的趨勢，對於軟件而言，統計質量保證包含以下步驟：
（1） 收集軟件的錯誤和缺陷信息，並進行分類。
（2） 追溯每個錯誤和缺陷形成的根本原因(例如，不符合規格說明、設計錯誤、違背標準、缺乏與客戶的交流)。
（3） 使用Pareto原則(80％的缺陷可以追溯到所有可能原因中的20％)，將這20％(重要的少數)原因分離出來。
（4） 一旦找出這些重要的少數原因，就可以開始糾正引起錯誤和缺陷的問題。
已經證明統計軟件質量保證技術確實使軟件質量得到了提高。在某些情況下，應用這些技術後，軟件組織已經取得每年減少50％缺陷的成果。
3.5軟件配置管理
在軟件項目開發過程中，會產生大量的“中間產品”，例如代碼、文檔、數據、腳本、執行文件、安裝文件、配置文件等。這些中間產品的數量會隨著軟件項目規模的擴大而急劇增加。而且它們與有形的產品不同，有形產品一旦生產出來後，再加工就比較困難，而中間產品是以電子介質的方式存在計算機中，比較容易修改，因而容易發生變化，這些變化給軟件產品的管理帶來了複雜性。
此外，軟件項目開發過程是在變化中進行的，任何一個微小的變化都會反映到軟件項目產品中來，一個軟件項目產品的變化就可能引起其他產品的變化，因為這些變化的產生導致在軟件開發過程中會遇到下麵的問題：
（1） 有時候，代碼被改亂了，想找到某個文件的之前的版本，卻沒有保存。
（2） 開發人員使用錯誤的版本修改程序。
（3） 開發人員未經授權修改代碼或文檔。
（4） 由於代碼管理混亂，人員流動，交接工作不徹底。
（5） 在維護過程中，需要重新編譯某個版本，但是缺少原有的開發工具或者運行環境，造成無法重新編譯某個曆史版本。
（6） 在協同工作過程中，代碼修改混亂，自己修改好的代碼，被人修改成舊的版本，因為協同開發或異地開發，版本變更混亂。
（7） 已經修複的Bug在新版本中又出現。
以上由於變化引起的項目問題最終都會影響項目的成功，所以軟件開發中必須有效地控製和管理變化，使得變化具有可追溯性，即記錄任意一個變化引起的軟件項目中間產品的變化過程。
3.5.1軟件配置管理定義
為了保持項目的穩定性，減少因項目混亂而造成的負麵影響，就需要進行有效的軟件項目配置管理。IEEE對軟件配置管理的定義是：軟件配置管理是一門應用技術、管理和監督相結合的學科，通過標識和文檔來記錄配置項的功能和物理特性，控製這些特征的變更，記錄和報告變更的過程和狀態，並驗證它們與需求是否一致。
軟件配置管理是一種標識、組織和控製修改的技術，它在整個軟件生命周期都有用，是對工作成果的一種有效保護。配置管理的過程是對處於不斷演化、完善過程中的軟件產品的管理過程。其目的是使錯誤量達到最小，並有效地提高生產率。軟件配置管理的作用是記錄軟件產品的演化過程，控製變更，確保開發人員在軟件生命周期的每一個階段都可以獲得精確的產品配置，保證軟件產品的完整性、一致性和可追溯性。
3.5.2軟件配置管理的相關概念
1. 配置和配置項
配置意為多個部件集合在一起形成一個整體，相對於硬件配置，軟件產品的配置包括更多的內容並具有易變性。
軟件配置項是軟件配置管理的對象，是為了配置管理而作為單獨實體處理的一個產品或軟件文檔、數據、源代碼和目標代碼。軟件配置項是在軟件工程過程中創建的信息。除了這些來自軟件工程工作產品的配置項之外，很多軟件工程組織也將軟件工具列入配置管理的範疇，如：特定版本的編輯器、編譯器、瀏覽器以及其他自動化工具等。因為當要對軟件配置項進行變更時，需要使用這些工具來生成文檔、源代碼和數據。在軟件項目進行過程中，要不斷地識別配置項，並為它們統一編號，以一定的目錄結構保存在配置庫中。對配置項的任何修改都應在軟件配置管理係統的控製之下。
2. 基線
基線是一個軟件配置管理概念，它能夠幫助開發團隊在不嚴重阻礙合理變更的條件下控製變更。IEEE對基線的定義是：已經通過正式評審和批準的規格說明或產品，它可以作為進一步開發的基礎，並且隻有通過正式的變更控製規程才能修改它。
基線由一組配置項組成，這些配置項構成了一個相對穩定的版本。基線中的配置項在項目生命周期的不同時間點上通過正式評審而進入正式受控狀態，它們被“凍結”了，不能再被隨意修改。
在軟件配置項成為基線之前，可以較快地且非正規地進行變更。然而，一旦成為基線，雖然可以進行變更，但是必須應用特定的、正式的規程來評估和驗證每次變更。
基線一般表示一個開發階段的結束。例如：需求文檔經過正式評審後，就成為一個基線(需求基線)，形成基線的文檔需要變更申請批準後才能修改。在一次迭代結束後，就形成一個軟件開發的裏程碑。
軟件工程任務產生一個或多個配置項，在配置項被複審並認可後，它們被放置到項目數據庫中。當項目團隊中的某個成員想修改某個基線配置項時，該配置項被從數據庫複製到這個成員的私有工作區中，但是，這個提取出來的配置項隻有在遵循配置管理控製的情況下可以被修改。
3.5.3軟件配置管理的參與人員
軟件配置管理過程的主要參與人員有：
（1） 配置控製委員會。負責指導和控製配置管理各項具體活動的進行，為項目經理的決策提供建議。
（2） 項目經理。是整個軟件項目開發的負責人，他根據配置控製委員會的提議，批準配置管理的各項活動並控製它們的進程。
（3） 配置管理員。根據配置管理計劃執行各項管理任務，定期向配置控製委員會提交報告，並列席配置控製委員會的例會。
（4） 開發人員。根據項目組織確定的配置管理計劃和相關規定，按照配置管理工具的使用模型來完成開發任務。
（5） 係統集成員。負責生成和管理項目的內部和外部發布版本。
（6） QA人員。跟蹤當前項目的狀態，測試報告錯誤，並驗證其修複結果。
上述6個角色中，配置管理員是從事配置管理的具體任務的人員，在實際軟件企業中，根據軟件企業規模的大小，配置管理員可能是項目團隊的全職人員，也可能是項目團隊的兼職人員。
3.5.4軟件配置管理活動
軟件配置管理的主要活動包括識別配置項、標識配置項、配置環境建立、版本控製、變更配置、配置審核、配置狀態報告等。
1. 識別配置項
一個軟件項目的工作產品有很多，哪些工作產品要列入配置項？識別的基本思想是“變化的東西才是配置管理的重點，不變的數據管理即可”。一般來說，可能成為配置項組成部分的主要工作產品如下：① 文檔；② 代碼；③ 數據文件；④ 軟件開發工具。
2. 標識配置項
識別了項目中的配置項後，為了管理和控製的方便，需要為這些配置項命名。命名的原則是唯一性、可追溯性和可擴充性。唯一性即是不允許出現同名現象，可追溯性要求命名能夠反映命名對象間的關係以便查詢和跟蹤，擴充性是指命名應該能容納所有的配置管理項，不能因為增加新的配置項而需要刪除或合並其他的配置項。
3. 建立配置管理環境
識別了配置項後就是搭建配置管理庫，配置管理庫是用來存儲所有配置項和相關文件的係統，是軟件產品的整個生存周期中建立和維護軟件產品完整性的主要手段。
一般來說，軟件項目中存儲過程文件的庫有三種。
（1） 開發庫，也稱動態庫。是指在軟件生存周期的某一個階段期間，存放與該階段軟件開發工作有關的計算機可讀信息和人工可讀信息的庫。由開發人員管理。
（2） 受控庫，也稱配置庫。是指在軟件生存周期某一個階段結束時，存放作為階段產品與軟件開發工作有關的計算機可讀信息和人工可讀信息的庫。軟件配置管理就是對軟件受控庫中的各軟件項進行管理，因此軟件受控庫也叫軟件配置管理庫，由配置管理員管理。
（3） 產品庫。是指在軟件生存周期的係統測試階段結束後，存放最終產品，而後交付給用戶運行或者現場安裝的軟件的庫。進入產品庫以後的更改必須執行嚴格的更改手續，並需要進行回歸測試、係統測試等驗證性試驗，通過後方能辦理入庫手續。
4. 版本控製
在對象成為基線以前可能要做多次變更，可能發生多人同時要修改一個文檔的現象，這種情況下就需要版本控製。版本控製的目的是按照一定的規則保存配置項的所有版本，避免發生版本丟失或混亂等現象。
版本是在明確定義的時間點上某個配置項的狀態，版本管理是對係統不同的版本進行標識和跟蹤的過程，從而保證軟件技術狀態的一致性。可以為配置項創建一個演化圖，演化圖描述了對象的變更曆史。例如圖326所示的就是一個版本控製過程，配置對象1.0經過修改成為對象1.1，對象1.1經過修改變成1.1.1。對象1.1經過更新變成了1.2。這個圖直觀地顯示了軟件的修改情況。
圖326軟件版本演化
在軟件開發過程中，程序員修改代碼可能出現兩種情況，第一種情況，每個程序員各自負責不同的專門模塊，沒有出現兩個程序員修改同一個代碼文件的問題。這時每個程序員都可以從代碼庫讀取文件，修改之後再存入代碼庫中。第二種情況，假設兩個程序員同時修改同一個代碼文件，就會出現代碼覆蓋問題，通常有兩種模式進行版本控製。
（1） 獨占工作模式。程序員從配置庫中檢出特定版本的文件到他的工作目錄，同時配置管理員同步鎖定了配置庫中的該對象，直到這個程序員完成變更後，把對象檢入回受控庫，再解鎖，這樣就創建了文件的一個新版本。這種模式的好處是在於一個程序員將配置項檢入回去之前，文件是被鎖定的，其他程序員無法修改文件。但是這種模式不利於並行工作。
（2） 並行工作模式。這種模式下，多個程序員可以並行修改同一個文件。假設張三和李四兩個程序員同時檢出了受控庫中的文件A進行修改，如果李四修改得到A1並檢入受控庫，當張三完成修改得到A2並準備檢入時，配置管理員通過審核提示張三原始版本已經發生變化，則張三再檢出目前受控庫中的A1到本地目錄，與自己完成的A2進行合並得當A3，使得變化都體現在A3中，然後再把合並後的文件A3檢入受控庫中。
代碼分支是支持並行開發的常用機製，分支包含了一個項目的文件樹及其發展的曆史，記錄了一個配置項的發展過程，一個配置項可能選擇多個分支，歸並是將對分支的修改合並到另一個分支。
代碼庫應該有一個主分支，所有提供給用戶使用的版本都在主分支上發布，主分支主要用來發布重大的版本，日常的開發在分支上完成。如果開發分支上的文件需要正式對外發布，就在主分支上對開發的分支進行合並。除了主幹和日常開發分支之外，還有一些臨時性的分支用於一些特殊目的版本開發，比如說功能分支、缺陷修複分支等。需要注意的是每條分支的目的和用途要明確，並確定相關角色和權限。運用分支可以實現多人並行開發一個新的係統，同步更改多個並行版本的錯誤，以及同時集成和發布多個版本。
5. 變更控製
變更控製是配置管理的重要內容，是一個重點也是一個難點，變更控製把人的規程和自動工具結合起來，以提供一個控製變化的機製。變更控製的目的是為了在動態中保證配置項的完整性、一致性和可回溯性，保證配置項的變更過程規範、受控、有完整記錄，受影響的各方均能及時了解情況，並協調一致。變更控製是通過創建產品基線，在產品的整個生存周期中控製它的發布和變更。主要工作是：① 變更的提出；② 變更的評價；③ 變更的處置；④ 實施經批準的變更；⑤ 對變更進行驗證和結束變更。
變更控製的流程圖如圖327所示。
圖327變更控製過程
典型的變更控製過程如下：收集變更理由，提交變更申請後，首先檢查變更請求的有效性，如果變更請求是一個已經記錄過的變更請求或者變更請求已經被實施了的，那麼這個請求是無效的。如果是新的變更請求，就評估這個變更，了解其對項目的影響情況，從質量、規範、成本、接口、可靠性、進度、預算等方麵分析變更對項目的影響，如果同時接受多個變更請求，需要確定變更的優先級。
下一步是變更審核，由變更控製委員會（或者產品開發小組）確定是否進行變更。一般四種結果：① 批準變更；② 拒絕變更；③ 部分變更，需要指出應該變更的部分；④ 延遲變更或待定，等待條件成熟時再決策。
如果變更被批準，變更實現人員從受控庫中取出基線的拷貝，實現被批準的變更，並對實現的變更進行驗證。一旦變更控製委員會（或者產品開發小組）認為正確實現並驗證了一個變更，就可以將更新的基線檢入配置庫中，更新該基線的版本標識。
6. 配置審計
標識、版本控製和變更控製幫助軟件開發者維持秩序，否則情況可能將是混亂和不固定的。為了確保適當地實現了變更，軟件配置管理使用兩種方法，即技術複審和軟件配置審計。
技術複審關注的是配置對象在修改後的技術正確性。評審者要評估配置項，以確定它與其他配置項是否一致、是否有遺漏或是否具有潛在的副作用。除了那些非常微不足道的變更之外，應該對所有變更進行技術複審。
軟件配置審計一般作為技術複審的補充，解決以下問題：
（1） 批準後的變更已經完成了嗎?引起任何額外的修改了嗎?
（2） 是否已經進行了技術複審來評估技術正確性?
（3） 是否遵循了軟件過程？是否正確地應用了軟件工程標準?
（4） 在軟件配置項中顯著強調所做的變更了嗎?是否說明了變更日期和變更者?配置對象的屬性反映出該變更了嗎?
（5） 是否遵循了軟件配置管理規程中標注變更、記錄變更和報告變更的規程?
（6） 是否已經正確地更新了所有相關的軟件配置項?
7. 狀態報告
配置狀態報告是軟件配置管理的一項任務，它回答下列問題：① 發生了什麼事？② 誰做的這件事？③ 這件事是什麼時候發生的？④ 它將影響哪些其他事情？
當大量人員在一起工作時，人與人之間不一定相互了解在做什麼；兩名開發人員可能試圖按照互相衝突的想法去修改同一軟件配置項；軟件工程團隊可能花費幾個人月的工作量，對著一個過時的需求規格說明在開發軟件。配置狀態報告通過改善所有相關人員之間的通信，幫助消除這些問題。配置狀態報告在大型軟件開發項目中發揮重要作用，配置狀態報告應定期進行，並盡量通過工具自動生成。
3.5.5軟件配置管理工具
Git是一個開源的分布式版本控製係統，它最初由Linus Torvalds編寫，用做Linux 內核代碼的管理，後來在許多其他項目中取得很大的成功。它除了常見的版本控製管理功能之外，還具有處理速度快、分支與合並表現出色的特點。
Github是一個基於Git的開源項目托管庫，目前成為全球最大的開源社交編程及代碼托管網站，它可以托管各種Git庫並提供一個Web界麵。
Subversion(SVN)是一個開源的版本控製係統，支持可在本地訪問或通過網絡訪問的數據庫和文件係統存儲庫，具有較強而且易用的分支以及合並功能。
Microsoft Visual Source Safe是微軟公司推出的一款支持團隊協同開發的配置管理工具，提供基本的文件版本跟蹤功能，與微軟的開發工具實現無縫集成。
Rational Clear Case 是IBM公司的一款重量級軟件配置管理工具，包括版本控製、工作空間配置、構建管理、過程控製，支持並行開發與分布式操作。
3.6本章小結
1. 軟件工程包括技術和管理兩方麵的內容，是技術與管理緊密結合的產物。軟件項目管理是軟件工程的一個重要組成部分，是軟件開發過程中一項重要活動，貫穿整個軟件生存周期，是軟件項目成功的保障。
2. 本章3.1介紹人員管理。軟件項目取得成功的關鍵是在項目啟動時挑選到高素質的、和諧的、目標一致的開發人員並建立結構合理的項目團隊，在開發過程中要及時有效地溝通，具有團隊協作精神。
3. 本章3.2介紹了項目規劃的意義、作用和方法。合理的規劃是建立在對要完成的項目做出一個比較符合實際的估算，而估算的基礎是軟件度量。介紹了麵向功能的度量和麵向規模的度量，接著介紹軟件項目估算的方法和如何進行進度安排、進度估算方法及進度安排表示方法。
4. 本章3.3節介紹了風險管理。風險管理實際上就是一係列管理項目風險的步驟，包括標識軟件項目中的風險，分析預測風險發生的概率以及風險造成的影響，並對所有可能的出現的風險進行評估。找出那些導致項目失敗的風險，然後采取措施來緩解、避開或消除風險。風險管理的活動主要概括為：風險識別、風險預測、風險評估和風險監控，這些活動貫穿於整個軟件工程過程中。
5. 本章3.4介紹了質量的定義，如何評價軟件質量，並介紹了幾種質量模型。提出了軟件質量困惑，軟件質量如何實現？從管理方麵要做好質量計劃編製，從項目外部要做好質量保證活動，從項目內部要做好質量監控活動。
6. 本章3.5介紹了軟件配置管理的定義，軟件配置管理的基本概念，配置管理參與的人員及配置管理活動和常用的配置管理工具。
習題
1. 何謂項目？何謂軟件項目管理？下列哪些活動是項目？
（1） 開展某個課題研究。
（2） 設計開發一個管理信息係統。
（3） 安排一場演出活動。
（4） 研製一種新藥。
（5） 高等學校招生新生。
2. 在選擇項目團隊成員時要考慮哪些因素？
3. 假如你被指派為一個小型軟件公司的項目經理，你的工作是管理該公司開發的已經被廣泛使用的字處理軟件的新版本的開發。你會選擇哪種團隊結構？為什麼？
4. 軟件項目開發中常用的溝通方式有哪些？
5. 項目規劃主要回答哪些問題？
6. 產品交付之前，團隊A在軟件工程過程中發現了352個錯誤，團隊B發現了185個錯誤。對於項目A和B，還需要做什麼額外的測量，才能確定哪個團隊能夠更有效地發現排除錯誤？
7. 假如某項目的任務分解如下表所示：任務代號任務名稱緊前任務期望完成時間A分析3個月B設計A2個月C測試計劃2個月D測試數據A、C4個月E測試軟件C6個月F編碼B4個月G產品測試D、E、F2個月H文檔B4個月（1） 請繪出ADM（Arrow Diagram）圖。
（2） 確定關鍵路徑,指出完成軟件開發需要多長時間。
（3） 若將“測試數據”任務的時間減少為3個月，對整個工期有影響嗎？若將“測試數據”任務的時間增加為6個月，對整個工期有影響嗎？將“編碼”任務減少為3個月，對整個工期有影響嗎？
8. 風險識別的方法有哪些？
9. 質量控製活動有哪些？
10. 軟件質量如何實現？
11. 軟件配置管理有哪些活動？
12. 軟件配置管理有哪些參與人員？
13. 基線是什麼？
14. 常用的軟件配置管理工具有哪些？
【微信掃碼】
本章參考答案&相關資源
第4章軟件需求工程第4章軟件需求工程
需求是係統應該提供的服務或對係統的約束一個高層抽象的描述，軟件需求是軟件開發的基礎，反映了客戶對係統解決某個問題的要求。用戶需求分析的準確與否直接影響到軟件開發的準確與否。因此，軟件需求工程已成為一項不可或缺的軟件工程活動，其基本任務是準確地回答“軟件係統必須做什麼？”這個問題。
隨著軟件開發模型的不斷變換和發展，軟件需求工程也是一個不斷認識和逐步細化的過程，該過程包括從定義係統的遠景和範圍，到逐步細化功能的可詳細定義的程度，並分析出各種不同的軟件成分，然後為這些成分找到可行的解決方法。特別是隨著軟件係統的規模越來越大，且軟件需求必須適應環境的改變，軟件需求分析和定義活動不再僅限於軟件開發的最初階段，而是貫穿於整個軟件生命周期。因此，軟件需求工程的過程在整個軟件生命周期中占有至關重要的地位。
4.1軟件需求的概念
4.1.1軟件需求的定義
需求工程作者Dorfman和Rhayer（1990）對軟件需求進行了如下定義：
●用戶為了達到某個目標而解決某個問題時所必需的一種軟件能力。
●係統或係統組件為滿足某個合約、標準、規格說明或其他正式文檔所必須達到或擁有的軟件能力。
1997年IEEE在《軟件工程標準詞彙表》對需求做出如下定義：
●用戶為解決某一問題或為達到某個目標所需要的條件或能力。
●係統或係統部件為滿足合同、標準、規格說明或其他正式的強製性文檔所必須具有的條件和能力。
●對在上述兩點所描述的條件或能力的文檔化說明。
IEEE的定義包括從用戶角度（係統的外部行為）以及從開發者角度（一些內部特性）來闡述需求，其關鍵的問題是一定要編寫需求文檔。
對於用戶來說，軟件係統相當於一個黑盒，軟件係統與係統間的交互過程如圖41所示。
圖41軟件係統元素
因此，Davis（1999）認為可以從5個方麵來完全描述係統：
●係統輸入。包括輸入的設備、形式、外觀以及感覺等必要的細節。
●係統輸出。必須支持對輸出設備的描述，如語音輸出或可視化顯示等，以及係統所產生信息的協議和格式。
●係統的功能。把輸入映射到輸出，以及他們的不同組合。
●係統的屬性。非行為需求，如可靠性、可維護性、可得到性以及吞吐量等開發人員必須考慮的因素。
●係統環境的屬性。附加的非行為需求，如係統在不同操作約束、負載和操作係統兼容性中運行的係統能力。
4.1.2軟件需求的層次
軟件需求主要包括3個不同的層次：業務需求、用戶需求、功能需求和非功能需求，不同層次從不同角度和不同層次反映其細節問題，他們之間的關係如圖42所示。
圖42軟件需求的關係
1. 業務需求
業務需求是組織或客戶對於係統的高層次目標要求，定義了項目的遠景和範圍，即確定軟件產品的發展方向、功能範圍、目標客戶和價值來源。這種需求通常來源於項目投資人、購買產品的客戶、市場營銷部門或產品策劃部門，一般使用遠景和範圍文檔進行記錄。業務需求通常應該涵蓋業務、客戶、特性、價值、優先級這幾個方麵的內容。
以個人網上銀行係統為例，其業務需求：
●該係統支持手機端和PC端的個人網上銀行服務，為用戶提供高效、便捷的銀行自助服務；
●該係統可使得係統用戶查詢個人賬戶餘額、轉賬、生活繳費、理財產品管理、基金產品管理、以及信用卡管理；
●由於某些功能存在風險問題，理財產品和基金產品的管理需要用戶在銀行網點進行簽約確認後才可使用。
在需求的層次結構中，業務需求處於整個結構的最頂層，它定義了整個係統的遠景與範圍，其他需求都必須符合業務需求設定的目標。項目的遠景和範圍應該以文檔形式描述出來，這種文檔一般比較簡短，可能隻有1～5頁，主要包括業務機會、項目目標、產品適用範圍、客戶特點、項目優先級等方麵的內容。
2. 用戶需求
用戶需求是從用戶角度描述係統必須完成的任務，包括係統功能需求和非功能需求，通常隻涉及係統的外部行為，而不涉及係統的內部特性。用戶需求的描述應該易於用戶的理解，一般不采用技術性很強的語言，而是采用自然語言和直觀圖形相結合的方式進行描述。利用用例（Use Case）模型或場景（Scenario）等方式說明。
以個人網上銀行係統為例，其用戶需求包括：
係統用戶可隨時通過Internet查詢個人的賬戶餘額和收支明細，並可以快捷地進行水、電、氣的繳費，可以方便地進行手機話費充值。
使用自然語言進行需求描述容易產生含糊不清和不準確的問題，因此，清晰的文檔結構和適當的語言表達對於用戶的需求描述是十分必要的。
3. 功能需求和非功能需求
功能需求描述係統應該提供的功能或服務，通常涉及用戶或外部係統與該係統之間的交互，一般不考慮係統的實現細節。在某些情況，功能需求還需明確聲明係統不應該做什麼。功能需求取決於開發的軟件類型，軟件未來的用戶及開發的係統類型。
比如，個人網上銀行係統為係統用戶提供了以下服務：① 係統用戶能查詢該行所有自身賬戶的賬戶餘額、賬戶明細情況，也應支持賬戶掛失；② 係統用戶輸入水、電、煤氣、電話費單的用戶號，選擇資金劃出賬號即可進行繳納；③ 用戶可以選擇相應的理財產品或基金產品進行購買，用戶還可以查詢自己的理財產品信息和基金產品信息。
以上的功能需求可以以不同的詳細程度反複編寫和細化。
非功能需求是從各個角度對係統的約束和限製，反映了應用對軟件係統質量和特性的額外要求。非功能需求包括過程需求、產品需求和外部需求等類型，其中過程需求包含交付、實現方法和標準等方麵的需求，產品需求包含性能、可用性、實用性、可靠性、可移植性、安全性、容錯性等方麵的需求，外部需求有法規、成本、互操作性等需求。具體的各項非功能需求的內容見圖43所示。
圖43非功能需求
4.1.3需求工程過程
需求工程是應用已證實有效的原理和方法，並通過合適的工具和符號，係統地描述出待開發係統及其行為特征和相關約束。需求工程包括需求獲取、需求分析、需求規格說明、需求驗證和需求管理等過程。
在這個過程中，開發人員聆聽客戶的需求，觀察用戶的行為（需求獲取），將這些信息進行分析和整理（需求分析），編寫規格說明文檔（需求規格說明），采用評審和商議等有效手段對其進行驗證（需求驗證），最終形成一個需求基線，並在整個軟件開發生命周期中有效地管理和控製需求的變更（需求管理）。結合2001年Abran和Moore給出的需求工程過程模型和當前軟件開發過程，圖44展示了整個需求工程的過程。
圖44需求工程過程
根據圖44所示，需求工程過程包括需求獲取、需求分析、需求描述和需求驗證4個步驟，涵蓋了與軟件需求相關的所有活動，包括：
●確定目標係統的所有利益相關者（Stakeholders）。
●從每一類利益相關者角度出發，收集他們的需求。
●了解這些利益相關者對係統期望的目標。
●分析這些目標，將目標細化為係統的功能需求、非功能需求、業務約束等，剔除與係統實現無關的信息。
●協商和確定各需求的優先級。
●對係統的需求進行建模，並用書麵文字來描述軟件需求規格說明。
●形成需求文檔，與用戶進行交涉，確保需求描述與用戶需求保持一致。
●整個需求分析的過程是一個不斷迭代的過程，通過多次的溝通和交流，不斷明晰用戶的需求。
4.2需求獲取
需求獲取涉及與項目相關的各種人員，包括組織管理層、最終使用係統的用戶、市場營銷人員、係統維護人員等，這些人員通常具有不同的目的，並從不同的角度提出自己的要求。因此，軟件設計師隻有在了解他們對係統的要求後才能開始設計係統。否則，一旦某項需求不滿足用戶的要求，都會導致設計方麵的大量返工。把需求獲取集中在各類用戶的任務上，有助於避免更多的失誤。
4.2.1需求獲取的任務
需求獲取的目標是確定用戶到底“需要”什麼樣的軟件產品，然而，如何明確用戶的需求卻是整個軟件開發過程中最關鍵、最困難、最需要溝通和交流的環節。主要原因在於：需求的不穩定性，軟件需求會隨著時間的推移發生變化；需求的不準確性，用戶對目標係統的要求往往不清晰，導致提取的需求不準確。因此，需求獲取應該集中在用戶任務上，其主要任務內容包括：
（1） 聆聽用戶需求，了解目標係統的應用環境，明確該業務係統的應用領域。如網上銀行、移動公司、證券、電子商務等，如果分析員對該領域有一定的了解，就可以先利用易於理解的語言和直觀的圖標建立該領域的業務模型來表示用戶的基本需求，並與用戶不斷的進行迭代溝通，不斷獲取目標係統中各用戶的準確需求。
（2） 分析和整理所獲取的信息。在不斷與用戶交流和溝通的過程中，要對獲取的需求信息結合行業領域準則進行分析和整理，並將分析和整理後的需求與用戶進行討論。每一次分析和整理用戶需求的過程，就是對業務需求不斷細化和明晰的過程，經過分析和整理的需求有助於進一步啟發用戶的需求。針對改進型業務係統，分析和整理需求信息除了來源於與用戶進行交談和討論的結果外，還包括目標係統中存在和描述現有產品或競爭產品的文檔、遺留係統的需求規格說明、當前係統的問題報告和改進要求、市場調查和用戶問卷調查、觀察用戶工作流程、用戶工作場景分析等。
（3） 形成文檔化的描述。當分析員完整的獲取了用戶的各項需求後，利用需求建模工具建立目標係統的需求模型，如Use Case模型、活動圖模型、BPMN業務模型、數據字典等。然後結合軟件工程需求規格文檔的標準規範，形成文檔化描述。
然而，在實際的軟件開發中，需求獲取是一個十分困難的過程，其主要原因在於：
（1） 用戶通常並不真正知道自己希望計算機係統做什麼。
（2） 用戶通常使用業務語言表達需求，開發人員缺乏相關的領域知識和經驗，難以準確地理解這些需求。
（3） 不同的用戶提出不同的需求，可能存在矛盾和衝突。
（4） 管理者可能出於增加影響力的原因而提出特別的需求。
（5） 由於經濟和業務環境的動態性，需求經常發生變更。
因此，需求獲取應該識別項目相關人員的各種要求，解決這些人員之間的需求衝突。
4.2.2需求獲取的技術
需求獲取的關鍵在於與用戶的溝通和交流，收集和理解用戶的各項需求。在需求獲取過程中，我們可以采用多種不同的技術進行業務理解和信息收集，常見的需求獲取技術包括麵談和問卷調查、需求專題討論會、觀察用戶工作流程、基於用例的方法、原型化方法等，而選擇這些技術需要根據應用類型、開發團隊技能、用戶性質等因素來決定。
1. 麵談
麵談是一種十分直接而常用的需求獲取方法，它也經常與其他需求獲取技術一起使用，以便更好地澄清和理解一些細節問題。麵談的主要流程包括：麵談之前的準備、進行麵談和麵談之後。其整個麵談的內容如圖45所示。需要說明的是，麵談過程應該進行認真的計劃和準備。
圖45麵談的內容
以個人網上銀行係統的一次麵談，舉例說明其主要步驟。
（1） 麵談之前
① 確認麵談目的
在項目調研的初期，我們需要了解網上銀行的業務過程，因此本次麵談的主要目的是了解當前網上銀行的業務流程、所存在的主要問題以及相關人員的期望要素。
② 確認參加麵談的相關人員
客戶方麵：銀行經理、銀行櫃員、用戶代表。
開發方麵：項目負責人、分析人員、開發人員。
③ 建立要討論的問題和要點列表
銀行賬戶管理由誰負責？這些人員的計算機專業背景如何？
該銀行具有哪些類型的銀行賬戶？
網上銀行係統期望的基本功能有哪些？
進行網上轉賬的賬戶製定了哪些規則？
網上轉賬實現的期望流程是什麼？
目前網上銀行係統存在的主要問題是什麼？其產生的原因是什麼？
銀行管理人員希望如何解決這些問題？
當前競爭對手的網上銀行係統有哪些亮點？
目前該銀行的賬戶規模有多少？
賬戶的編碼和管理？
銀行櫃員對於網上銀行的期望是什麼？
用戶對於網上銀行的期望是什麼？
……
（2） 進行麵談
麵談獲得所需信息的首要前提是應該與麵談者建立良好的談話氛圍，以下行為有助於建立氛圍。
誠懇態度：直截了當地談話，對麵談者在軟件中的利害關係表現出真正興趣。
保持傾聽：完全關注對方，認真聽取對方的談話。
虛心求教：不要顯得“無所不知”。
深入細節：對模糊應答需要刨根問底。
避免跑題：可適當引導當前網上銀行係統的基本業務功能，緊密圍繞該主題。
詳細記錄：對麵談人員的每一個問題答案、客戶方的每一個疑問等內容進行詳細記錄。
麵談結束時需要再次啟發對方，詢問是否還有需要提出的問題和可以帶走的資料，確定有問題時雙方的聯係方式，並向對方人員表示感謝。
（3） 麵談之後
複查記錄的準確性、完整性和可理解性，把收集的信息轉化為適當的模型和文檔，再次確定有問題時雙方的聯係方式，並向對方人員表示感謝。
2. 需求專題討論會
專題討論會是指開發方和用戶方召開多次需求討論會，達到徹底弄清項目需求的一種需求獲取方法。需求專題討論會適合用戶方對業務係統的工作流程、項目達到的最終目的等方麵非常了解，同時，開發方也對該業務係統領域有過類似的開發經驗。因此，召開需求專題討論會可以更加準確的描述和掌握需求。需求分析員需要經常組織和協調需求專題討論會，人們通過協調討論和群體決策等方法，為具體問題找到解決方案，並在應用需求上達成共識，對操作過程盡快取得統一意見。
在這種會議中，參加人員一般包括三種角色：
主持人或協調人：該角色在會議中起著十分關鍵的作用，他應該鼓勵參會人員積極參與和暢所欲言，保證會議過程順利進行。
記錄人：該角色需要協助主持人將會議期間所討論的要點內容記錄下來。
參與人：該角色的首要任務是提出設想和意見，並激勵其他人員產生新的想法。
專題討論會具有以下優點：① 協助建立一支高效的團隊，圍繞一個目的；② 所有風險承擔人都暢所欲言；③ 促進風險承擔人和開發團隊達成共識；④ 能夠揭露和解決那些妨礙項目成功的行政問題；⑤ 能夠很快產生初步的係統定義。
3. 觀察用戶工作流程
客戶可能無法有效的表達或隻能片麵的表達自己的需求，開發人員很難通過麵談和會議了解完整的需求，因此，觀察用戶工作流程是一種比較好的解決方法。
觀察用戶工作流程有兩種形式：主動觀察和被動觀察，主動觀察是指分析人員以用戶的角色參與到業務係統的工作流程中去，從而獲取第一手業務係統的完整需求；而被動觀察是指分析人員觀察用戶的業務操作，記錄用戶的操作流程，從而獲得業務係統的需求信息。
缺點主要有兩點：① 觀察用戶的工作流程時間較長，而且需要涉及不同的業務階段；② 用戶在觀察到過程中會有意識地隱藏現實的工作情況。
4. 原型化方法
原型通常是指模擬某個產品的原始模型，旨在演示目標係統主要功能的可運行程序。在軟件開發中，原型是軟件的一個早期可運行的版本，它反映最終係統的部分重要特性。如果通過獲取目標係統的基本需求後，通過快速分析並構造出一個小型的軟件係統，滿足用戶的基本要求。用戶可在試用原型係統的過程中得到親身感受並受到啟發，做出相應的反應和評價，然後開發方根據用戶的意見對原型加以改進。經過不斷試驗、糾錯、試用、評價和修改，獲得新的原型版本，從而進一步確定各種需求的細節。因此，它是最準確、最有效、最強大的需求分析技術。