----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------算法
軟件不一樣於通常的傳統產品,它是對物理世界的一種抽象,是邏輯性的、知識性的產品,是一種智力產品。編程
(1)軟件項目是設計性的項目網絡
設計性項目與其餘類型的項目徹底不一樣。設計性項目所涉及的工做和任務不容易採用Tayloristic或者其餘類型的預測方法,並且設計性項目要求長時間的創造和發明,須要許多技術很是熟練的、有能力合格完成任務的技術人員。開發者必須在項目涉及的領域中具有深厚和廣博的知識,而且又能力在團隊溝通和協做中有良好的表現。設計性項目一樣也須要用不一樣的方法進行設計和管理。數據結構
(2)軟件過程模型架構
在軟件開發過程總,會選用特定的軟件過程模型,如瀑布模型、原型模型、迭代模型、快速開發模型和敏捷模型等。選擇不一樣的模型,軟件開發過程會存在不一樣的活動和操做方法,其結果會影響軟件項目的管理。例如,在採用瀑布模型的軟件開發過程當中,對軟件項目會採用嚴格的階段性管理方法;而在迭代模型中,軟件構建和驗證並行進行,開發人員和測試人員的協做就顯得很是重要,項目管理的重點是溝通管理、配置管理和變動控制。數據結構和算法
(3)需求變化頻繁編程語言
軟件需求的不肯定性或變化的頻繁性使軟件項目計劃的有效性下降,從而對軟件項目計劃的制定和實施都帶來了很大的挑戰。例如,人們採用極限編程的方法來應對需求的變化,以用戶需求爲中心,採用短週期產品發佈的方法來知足頻繁變化的用戶需求。分佈式
需求的不肯定性或變化的頻繁性還給項目的工做量估算形成很大的影響,進而帶來更大的風險。僅瞭解需求是不夠的,只有等到設計出來以後,才能完全瞭解軟件的構造。另外,軟件設計的高技術性,進一步增長了項目的風險,因此軟件項目的風險管理尤其重要。ide
(4)難以估算工做量單元測試
雖然前人已經對軟件工做量的度量作了大量研究,提出了許多方法,但始終缺少有效的軟件工做量度量方法和手段。不能有效地度量軟件的規模和複雜性,就很難準確估計軟件項目的工做量。對軟件項目工做量的估算主要依賴於對代碼行、對象點或功能點等的估算。雖然上述估算可使用相應的方法,但這些方法的應用仍是很困難的。例如,對於基於代碼行的估算方法,不只因不一樣的編程語言有很大的差別,並且也沒有標準來規範代碼,代碼的精煉和優化的程度等對工做量影響都很大。基於對象點或功能點的方法也不能適應快速發展的軟件開發技術,基於沒有統一的、標準的度量數據供參考。
(5)主要的成本是人力成本
項目成本能夠分爲人力成本、設備成本和管理成本,也能夠根據和項目的關係分爲直接成本和間接成本。軟件項目的直接成本是在項目中所使用的資源而引發的成本,因爲軟件開發活動主要是智力活動,軟件產品是智力的產品,因此在軟件項目中,軟件開發的最主要成本是人力成本,包括人員的薪酬、福利、培訓等費用。
(6)以人爲本的管理
軟件開發活動是智力的活動,要使項目得到最大收益,就要充分調動每一個人的積極性、發揮每一個人的潛力。要達到這樣的目的,不能靠嚴厲的監管,也不能靠純粹的量化管理,而是要靠良好的激勵機制、工做環境和氛圍,靠人性化的管理,即以人爲本的管理思想。
項目角色和職能:
角色 | 職能 |
項目經理 | 項目的總體計劃、組織和控制 |
需求人員 | 在整個項目中負責獲取、闡述、維護產品需求及書寫文檔 |
設計人員 | 在整個項目中負責評價、選擇、闡述、維護產品設計及書寫文檔 |
編碼人員 | 根據設計完成代碼編寫任務並修正代碼中的錯誤 |
測試人員 | 負責設計和編寫測試代碼,以及完成最後的測試執行 |
質量保證人員 | 負責對產品的驗收、檢查和測試的結果進行計劃、引導並作出報告 |
環境維護人員 | 負責開發和測試環境的開發和維護 |
其餘人員 | 另外的角色,如文檔規範人員、硬件工程師等 |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
軟件項目管理有其特定的對象、範圍和活動,着重關注成本、進度、風險和質量的管理,還須要協調開發團隊和客戶的關係,協調內部各個團隊之間的關係,監控項目進展狀況,隨時報告問題並督促問題的解決。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
軟件項目管理和生命活動週期的活動比較:
項目管理 |
項目啓動 |
計劃階段 |
監控階段 |
項目結束 |
客戶服務和系統維護 |
|||||||
軟件開發生命週期 |
概念或願景 |
需求分析和定義 |
設計 |
實施(編程和單元測試) |
系統集成和測試 |
系統安裝 |
維護和支持 |
|||||
說明 |
項目活動 l 收集數據 l 識別項目需求 l 肯定項目範圍 l 指定初步的WBS l 資源估計 系統開發活動 l 定義產品需求 l 可行性分析 l 定義產品範圍 l 規劃系統架構 |
項目活動 l 創建項目團隊 l 指定詳細WBS l 項目路勁網絡 l 預算和進度估計 l 寫項目計劃 l 簽定項目合同書 系統開發活動 l 產品需求肯定 l 完成系統架構設計
|
項目活動 l 創建項目組織 l 創建和執行工做任務 l 知道、監督和監控項目 系統開發活動 l 完成詳細設計 l 設計書籤發 l 構建系統 l 執行單元、系統和集成測試 |
項目活動 l 實施技術和財務審覈 l 獲取客戶承認 l 準備項目移交 l 評估和記錄結果 系統開發活動 l 安裝和測試系統 |
項目活動 l 項目移交 l 制定客戶調查計劃 l 跟蹤客戶 l 客戶服務 系統開發活動 l 操做系統 l 系統技術支持 l 維護和升級 |
---------------------------------------------------------------------------------------------妖嬈的分割線----------------------------------------------------------------------------------------------------------------------------
(1)按規模劃分:大型項目、中小型項目等。大型項目比較複雜,代碼量在百萬行數量級,開發團隊在百人以上。
(2)按軟件開發模式分:組織內部使用的軟件項目、直接爲用戶開發的外部項目和軟件外包項目。
(3)按產品不一樣的交付類型分:產品型項目和一次型項目。
(4)按軟件商業模式分:軟件產品銷售和在線服務(online service)或者隨需服務模式(on-demand)和內部部署模式(on-premise)。
(5)按軟件發佈方式分:新項目和重複項目(舊項目)或完整版本(full package release/major release)、次要版本或服務包(service pack)和修正補丁包(patch)等。
(6)按項目待開發的產品進行分類:如COCOMO模型中,可分爲組織型、嵌入型和半獨立型。
組織型(organic):相對較小、較簡單的軟件項目(<50 KLOC)。開發人員對項目目標理解比較充分,與軟件系統相關的工做經驗豐富,對軟件的使用環境很熟悉,收硬件的約束較小。
嵌入型(Embedded):要求在緊密聯繫的硬件、軟件和操做的限制條件下運行,一般與某種複雜的硬件設備集成。對接口、數據結構和算法要求高。軟件規模沒有限制。
半獨立型(semidetached):介於上述兩種項目之間。規模和複雜度都屬於中等或更高(<300 KLOC)。
(7)按系統架構分(Architecture):B/S結構和C/S結構或集中式系統和分佈式系統或面向對象(OOA)、面向服務(SOA)和麪向組件(COA)。
(8)按技術劃分:Web應用、客戶端應用、系統平臺軟件等。或者J2EE、.Net等