壹.風險評估
軟件項目風險是指整個項目周期中涉及的費用預算、開發進度、技術難度、經濟可行性、安全管理等問題，以及這些問題對項目造成的影響。項目的風險與可行性成反比，可行性越高，風險越低。軟件項目的可行性可以分為四個方面:經濟可行性、業務可行性、技術可行性和法律可行性。軟件項目風險分為六個方面:產品規模風險、需求風險、相關性風險、管理風險和安全風險；
1.？產品規模風險
項目的風險與產品的規模成正比。壹般產品規模越大，問題越突出。特別是估算產品規模的方法、可復用軟件的數量、需求變化的數量等因素都與產品風險密切相關:
(1) ?估計產品規模的方法
(2) ?產品規模估計的可信度
(3) ?產品規模與之前平均產品規模的偏差
(4) ?產品的用戶數量
(5) ?復用軟件有多少？
(6) ?產品需求發生了多大的變化？
2.？需求風險
許多項目在確定需求時面臨壹些不確定性。當這些不確定性在項目前期被容忍，在項目進展過程中得不到解決時，這些問題將對項目的成功構成極大的威脅。如果不控制與需求相關的風險因素，很可能會生產出錯誤的產品，或者把預期的產品造壞。每種情況對產品都可能是致命的，這些風險因素是:
(1) ?對產品缺乏清晰的了解
(2) ?缺乏對產品需求的認識
(3) ?需求分析過程中客戶參與不足
(4) ?沒有優先需求
(5) ?由於不確定的需求，新的市場產生了。
(6) ?需求變化
(7) ?缺乏有效的需求變更管理流程
(8) ?缺乏對需求變化的相關分析等。
3.？相關風險
很多風險是由項目的外部環境或者因素的相關性造成的。為了控制外部相關性風險，緩解策略應包括可能性計劃，以便從第二資源或協作工作資源中獲取必要的組件，並檢測潛在的問題。與外部環境相關的因素有:
(1) ?客戶供應項目或信息
(2) ?交互成員或交互組的依賴性
(3) ?內部或外部分包商之間的關系
(4) ?有經驗人員的可用性
(5) ?項目可重用性
4.？技術風險
軟件技術的快速發展和缺乏有經驗的工作人員意味著項目團隊可能會因為技能而影響項目的成功。在早期，識別風險並采取適當的預防措施是解決風險領域問題的關鍵，如培訓、聘請顧問和為項目團隊招募合適的人才。關於技術，主要有以下風險因素:
(1) ?缺乏訓練
(2) ?對方法、工具和技術理解不足。
(3) ?缺乏應用領域的經驗
(4) ?不熟悉新技術和開發方法的應用。
5.？管理風險
雖然管理問題限制了許多項目的成功，但不要對所有管理活動都沒有包括在風險管理計劃中感到驚訝。在大多數項目中，項目經理通常是編寫項目風險管理計劃的人。他們有壹個先天不足——他們不能檢查自己的錯誤。因此，項目的成功變得更加困難。如果我們不正視這些棘手的問題，它們很可能在項目的某個階段影響到項目本身。當我們定義項目跟蹤過程並闡明項目角色和責任時，我們可以處理這些風險因素:
(1) ?計劃和任務定義不充分。
(2) ?不知道實際的項目狀態
(3) ?項目所有者和決策者很困惑。
(4) ?不切實際的承諾
(5) ?無法與員工充分溝通。
6.？危險人物
軟件產品本身就是壹個創意產品，保守產品核心技術的秘密非常重要。但長期以來，我們在軟件這方面的安全意識比較薄弱，軟件產品的開發主要集中在技術本身，忽視了專利的保護。軟件行業的技術人員流動是非常普遍的現象。隨著技術人員的流失和變動，很可能導致產品和新技術的泄露，導致我們的軟件產品被其他公司盜用，項目失敗。而且軟件知識產權的認定也沒有明確的行業標準，這也是我們軟件項目的潛在風險。
7.？規避風險的方法
(1) ?由開發人員指導可以保證需求的完整性，並使需求與客戶的真實期望高度壹致。然後，便於形成書面的重要文檔“用戶需求”，避免遺漏造成的損失在軟件系統的後續階段被逐漸放大。
(2) ?要建立監理制度，項目開發的任何重大決策都必須有客戶的參與。在本項目中，項目監督由項目開發中的質量監督小組實施。
(3) ?需求變更需由統壹負責人提出，經用戶需求審核組長批準。需求變更應該定期而不是隨時提出，開發人員要做好詳細的記錄，讓客戶了解需求變更的實際情況。
(4) ?控制系統的復雜和系統結構的簡單，會明顯打折用戶的比例，甚至造成軟件壽命過短。另壹方面，如果軟件結構過於靈活和通用，必然會增加軟件實現的難度和系統的復雜性，從而在實現和測試階段帶來風險。適當控制系統的復雜性有利於降低開發風險。
(5) ?從軟件工程的角度來看，軟件維護成本約占總成本的55%~70%，系統越大，成本越高。忽視系統的可維護性是大型軟件系統最大的風險。在軟件漫長的運營期內，業務規則壹定會不斷發展。解決這個問題的科學方法是在保證可維護性的前提下，不斷升級軟件系統，逐步擴展系統。
(6) ?制定應急預案，每個開發計劃至少要制定壹個應對突發情況和未知風險的應急預案。
二、成本預算
1.？成本預算模式
(1) ?自上而下的預算方法
自上而下的預方法主要是根據中上層項目經理的管理經驗來估算構成項目整體成本的子項目成本，並將這些判斷和估算的結果傳遞給下層經理。在此基礎上，這壹級的管理人員對構成項目的子任務和子項目進行估算，然後繼續將其成本估算傳遞給下壹級，直到達到最低級別。
使用這種預算方法，當上層管理者基於經驗的成本估算分解到下層時，可能會出現下層人員認為上層估算不足以完成相應任務的情況。這個時候，下層人員可能不會表達自己的真實看法，也可能不會理性地和上層管理層討論，從而得出更合理的預算分配方案。在實踐中，他們只能默默等待高層管理者發現問題並改正，這往往會給項目帶來很多問題。
自上而下更適合項目啟動初期，與真實成本的差異在30%-70%之間。
Scrum采用自上而下的成本預算方法，不會立即準確地確定成本，但會最大程度地容納客戶對未來產品要求的變化。
(2) ?自下而上的預算方法
自下而上的方法要求使用WBS(工作分解結構)仔細檢查項目所有工作任務的時間和預算。最初預算是針對資源的(團隊成員的工作時間，硬件配置)，項目經理加上適當的間接費用(如培訓費用，管理費用，不可預見費用等。)和項目要達到的利潤目標，形成項目總預算。自下而上的預算方法要求綜合考慮所有涉及的任務，比較適合項目的初期和中期。它可以估算項目在準備階段的成本，它與真實成本的差異在5%到10%之間。
註:WBS
WBS是對提交項目的分解。從提交列表中，我們可以確定每個提交需要執行的活動。Scrum會進壹步細化WBS，將壹個叠代分解成壹個或多個工作包，然後將工作包分解成小的開發任務(壹般開發任務的開發周期在15工作小時以內)。
2.？確定項目支出
總成本預算是結合以下成本預算方法綜合計算的開發成本:
(1) ?零基數預算
在成本預算之初，應采用零基的計算原則，不能像上年總成本加20%那樣粗略計算項目成本。
(2) ?軟件和硬件成本、項目成本
項目成本是指類似於:服務器(RAM硬盤CPU NIC卡RAID集群)成本、維護成本、機房租金、光纖通信成本、軟件成本等成本。
在計算成本的時候，我們需要考慮很多因素，比如組裝硬盤需要的時間長短，技術人員的素質，產品供應商能否保證質量，管理上是否需要額外的管理人員。
(3) ?軟件許可成本
(4) ?外包成本
使用視頻、短信、移動電信服務、門戶等子項目時。，可以考慮外包，降低開發成本。
(5) ?人力資源成本
在計算人力資源成本時，應通過估算工作效率最高和最低的平均效率來計算人力資源的平均成本。
(6) ?維修費用
第三，客戶溝通的過程
從客戶溝通的角度來看，軟件項目可以分為需求識別、方案定制、項目實施、項目結束四個不同的階段，每個階段有不同的溝通重點。
1.？需求識別階段
(1) ?文字通信
在需求識別前期，要通過問卷調查、原型展示、界面展示、邏輯處理展示、標準化文檔模板等方式進行全方位、多角度的分析。，並隨時將歧義反饋給客戶，以期待客戶解答。並以文字記錄的方式建立需求分析書，請客戶審閱需求分析書，以達到需求分析與客戶真實期望高度壹致的結果。
(2) ?業務邏輯溝通
在業務溝通中，要理解客戶的行業語言，從而推動業務分析的進程，跨越應用需求與開發之間的鴻溝。溝通過程提倡速寫或可視化信息化，為不同層次的企業用戶提供最適合的操作界面。多角度思考，抓住重點需求，尤其是客戶領導關註的創新性、實用性需求。
(3) ?需求變化的標準化管理
需求變更在軟件開發項目中是可以理解的，但是必須以標準化的方式進行管理，以避免無休止的需求變更的風險。需求變更必須由統壹負責人提出，並經用戶需求審核組長批準。需求變更應該定期提出，而不是隨時提出。開發人員要做詳細的文字記錄，讓客戶了解需求變更的實際情況，以及開發人員所付出的成本。
2.？方案定制階段
該階段項目的主要任務是根據前期明確的需求、雙方的資源、項目初期、實施時間約定、項目成本限制等，與客戶* * *制定出可操作的項目計劃。從這壹階段開始，客戶將全面參與項目管理，從雙方利益出發考慮項目實施的具體方案和風險規避。
3.？項目實施階段
在這個階段，軟件項目團隊應該和客戶壹起領導項目的實現。同時，項目組要實時評估客戶滿意度，通過持續改進提高客戶滿意度。還應要求客戶參加必要的培訓，並在必要時檢查項目產品。在客戶的需求發生變化之前，要積極與客戶溝通，讓客戶充分了解項目的每壹個環節以及變化帶來的影響，減少需求變化。如果客戶需求發生變化，我們應該與客戶壹起解決由變化引起的成本、進度和質量的變化。
4.？結束階段
這個階段主要是項目成果移交，系統交付給維護人員，幫助客戶實現業務目標，結算各種款項。在完成這些任務後，應對項目進行評估，對項目結果進行審查，並總結項目經驗。
5.？售前人員的註意事項
當以產品為導向的項目被視為開發成果時，相關銷售人員要註意:對產品的推廣不能過度承諾。如果承諾過多，會給後續項目實施帶來困難；壹旦承諾沒有兌現，也會降低客戶滿意度，影響以後的合作。如果有任何額外的承諾，必須以文本形式記錄下來，以便實施項目經理能夠知道並傳達給項目團隊成員。
註意:在軟件項目中，需要定義以下四個客戶角色。
A.？要明確最終用戶部門和用戶，了解他們現有的工作方法，讓他們知道項目的目標框架，知道項目要解決哪些困難，但肯定不是全部，這樣才能更好的控制項目的範圍。
B.？為了明確需求的發起者，他或他們應該能夠代表最終的客戶群。這類提出產品需求的客戶應具備壹定的技術、業務能力和權限，能真實代表最終客戶團隊的意願和想法，最好有IT基礎，能用IT語言描述問題和需求，便於雙方溝通合作，避免歧義。
C.？做需求確認的中層領導，壹定要把握方向。軟件開發項目是為了解決實際生產或管理問題，也是為了引領系統建設的具體實現。作為需要確認的客戶領導，不僅要了解高層領導的系統建設重點和方向，還要熟悉具體的業務和生產管理實踐。如果是這樣的話，對於企業軟件開發項目的順利進行將起到非同壹般的作用。
D.？要明確誰來對成品做評論，誰來接受。項目驗收環節是項目的收尾環節。如果接受項目的人不了解項目最初的需求目標，會從態度上和產品的實際使用效果上對接受產生負面影響，對提供產品的企業關閉項目非常不利。根據實踐總結，需求方和確認方做好項目的驗收工作，可以促進項目的順利完成，避免延誤。
第四，需求分析
1.需求分析的過程
需求流程包括兩個部分:需求開發和需求管理:
(1) ?需求開發是開發前期的管理和與客房的溝通過程，分為需求獲取、需求分析、需求撰寫、需求驗證四個階段。
(2) ?需求管理:是軟件項目開發過程中控制和維護需求協議的活動。包括變更控制、版本控制、需求跟蹤和需求狀態跟蹤。
2.？需求水平
需求層次包括四個方面:業務需求、用戶需求、功能需求和非功能需求。
3.需求開發階段的關鍵點
(1) ?提取業務對象
業務對象指的是系統使用的真實對象。例如，供應鏈管理(SCM)的業務對象主要包括:生產商、批發商、零售商、供應商和客戶。
(2) ?提取業務流程
在理解業務邏輯的過程中，要列出開發的軟件模塊各自的功能，細化每個工作流程，深入分析業務邏輯。
(3) ?性能要求
在分析前期，客戶要關註所開發軟件的技術性能指標，如存儲容量限制、運行時間限制、安全保密等。
(4) ?環境需求
環境要求是指軟件平臺運行的環境的要求，如硬件:型號、外部設備、數據通信接口；軟件:系統軟件，包括操作系統、網絡軟件和數據庫管理系統；用途:從運營商的系統和技術水平來說，使用部門應該具備什麽條件。
(5) ?可靠性要求
應根據實際運行環境要求所開發的軟件投入運行後出現故障的概率。對於重要的軟件，或者運行失敗會造成嚴重後果的軟件，應該提出更高的可靠性要求。
(6) ?安全和保密要求
在進行需求分析時，要在這方面做出適當的規定，對開發的軟件進行特殊的設計，以保證其在運行中的安全性和保密性。
(7) ?用戶界面要求
詳細指定用戶界面的到達要求。
(8) ?資源使用需求
所開發的軟件在運行時和開發時需要的各種資源。
(9) ?軟件成本消耗和開發進度要求
軟件項目立項後，根據合同提出軟件開發的進度要求和每壹步的費用，作為開發管理的依據。
(10)發展目標要求
提前預估系統可能達到的目標，這樣更容易對系統進行必要的補充和修改。
4.？需求分析的任務
需求分析的主要任務是借助於當前系統的邏輯模型導出目標系統的邏輯模型，其過程如下:
(1) ?確定系統的綜合要求(功能、性能、操作和擴展要求)
(2) ?制作產品需求文檔(PRD)
(3) ?分析系統的數據需求(概念模型、數據字典、標準化)
(4) ?導出目標系統的詳細邏輯模型(數據流圖、數據字典、主要功能描述)
(5) ?開發原型系統
(6) ?從PRD中提取和編譯軟件需求規格說明。
註意:SRS格式
1.簡介？2系統概述(項目背景、系統目標、核心業務流程)3。術語描述？4.系統結構(架構圖、功能圖)
5.主要功能和業務邏輯(要點)6。接口要求(內部和外部接口)7。整體網絡設計(拓撲網絡、主機、網絡)
8.操作環境(Linux，Windows，IIS，WebLogic，Tomcat，OLAP，OLTP，JDK 8.0，。NET Framework 4.0等。)
五、面向對象程序設計(略)
1.？設計原理
(1) ?SRP單壹責任鏈
每個班級應該只負責做壹件事。
(2) ?OCP啟封和關閉原理
軟件實體(類、模塊、函數等。)應該是可擴展的，但不可修改的。
(3) ?LSP替換原則
子類必須能夠替換它們的基本類型。
(4) ?傾角相關反演原理
高層模塊不應該依賴於低層模塊，但兩者都應該依賴於接口和抽象類。抽象不應該依賴於細節，細節應該依賴於對象。
(5) ?ISP接口隔離原則
我們應該分離胖接口，而不是強迫客戶依賴未使用的接口。
2.？實現UML建模
(1) ?業務對象的提取
(2) ?基於SRS、CRC等的用例建模。
(3) ?實現業務序列圖
(4) ?建立類圖，根據用例圖建立對象之間的關聯。
(5) ?繪制活動圖，實現協作圖和狀態圖。
不及物動詞發展管理
1.？建立項目計劃
(1) ?設計整體架構
根據系統的實施需要，采用合適的、成熟的框架結構。
(2) ?控制可擴展性
過度擴展會增加系統的復雜性，延長開發時間；過低的擴展性會直接影響系統的二次開發和維護。控制系統的可擴展性可以提高開發效率，降低系統維護的難度。
(3) ?建立基礎設施
合理分配部署軟硬件等基礎設施所需的時間和成本(例如，訂購和安裝服務器、光纖接入、訂購軟件平臺)。
(4) ?劃分開發任務
使用WBS(工作分解結構)對可交付成果進行分類和劃分。每個項目可以分成幾個不同的階段，每個階段又可以分成幾個工作包，這些工作包是WBS中最小的可交付成果。最後，從工作包中分離出幾個開發任務列表。
(5) ?部署和開發進度
壹個項目要根據進度分成幾個開發階段，每個階段的開發周期壹般在30~60個工作日內。在這個階段，我們應該與客戶召開咨詢會議，制定產品路線圖，並在開發過程中邀請客戶積極參與並給予反饋。然後根據開發難度、依賴度、重要性等條件，將該時期的開發任務劃分為多個叠代周期。
在Scrum敏捷軟件開發的原則中，每個叠代任務要進壹步細分為多個開發任務列表，再開發任務要分配給團隊成員，開發時間要控制在15工作小時以內。如果開發時間超過15工作小時，就要考慮重新細化開發任務。開發任務建議應該由團隊成員自己選擇，而不是強制分配。
(5) ?測試項目結果
每個工作包應該同步部署測試工作，以提高項目的質量。有bug的工作包要由測試人員用文字記錄下來，把錯誤展示給開發人員，以便開發人員及時修改。
2.？管理開發團隊
(1) ?建立壹個團隊
根據工作任務和項目時間的前提條件建立團隊，並根據團隊職責分配人員。壹般團隊成員人數要控制在8到12之間。當團隊人數超過15時，要考慮將團隊拆分成兩個獨立的團隊，分別負責不同的開發任務。
(2) ?分配開發任務
在每個叠代周期內(壹般為15~30個工作日)，每個工作包要進壹步細分為多個開發任務，將再開發任務分配給團隊成員，開發時間控制在15個工作小時內。如果開發任務的開發時間超過15工作小時，就要考慮重新細化任務。開發任務應該以自由選擇的方式分配給每個團隊成員。
(3) ?監督開發進度
在叠代前期召開會議，讓團隊成員了解開發進度和過程，以自選的方式分配開發任務。在此期間，可以使用Microsoft Project等工具來記錄開發過程的進度。每個工作包開發完成後，都要進行功能測試，測試結果要用文字記錄下來。
每天開壹個15分鐘的常務會，讓團隊成員交代昨天完成的開發任務，當天要做的任務，開發過程中遇到的問題。並且每周末開壹次例會，說明整體流程。
叠代結束時，召開沖刺會議，總結項目進展，完成任務，回顧叠代期間遇到的問題，為下壹次叠代做準備。
(4) ?系統測試
及時測試每個完成的工作包，確保系統的質量和性能。用文字記錄測試結果，並將測試結果與績效工資收入掛鉤，用真實數據計算團隊成員的績效收入。
(5) ?解決發展中遇到的問題
對開發人員進行前期培訓，根據工作能力分配任務，指導團隊成員的發展。遇到問題要立即在當天的常務會上提出，遇到的問題要在15工作時間內解決，防止問題進壹步擴大。
3.？監督產品質量
(1) ?質量需要規劃、設計，而不是評審。在產品建立的初始階段，需要與“質量保證”(QA)部門協商，以正式文件的形式確定適當的質量策略和標準。
(2) ?在開發過程中，采用TDD(測試驅動開發)模式來提高開發質量。測試人員應該以文本形式記錄bug，並與開發人員壹起向開發人員演示突出的缺陷，以提高修改的效率。
(3) ?每次叠代結束，做壹次產品效果演示，收集客戶、用戶、高層領導的反饋信息。在團隊內部召開評審會議，分析測試結果，了解產品性能，為下壹次叠代需要的改進制定計劃。
4.？修改項目計劃
(1) ?在產品標識階段，產品功能和開發過程應以文件形式記錄。當開發計劃需要修改時，應與客戶討論，讓客戶知道計劃修改對項目進度的影響。
(2) ?項目計劃的修改應由統壹負責人提出，並經用戶需求審核組長批準。需求變更應該定期提出，而不是隨時提出。
(3) ?對於計劃變更要做詳細的文字記錄，讓客戶了解需求變更的實際情況，以及開發商所付出的成本。
七。產品交付
1.？項目的事後審計
項目開發最終完成後，對開發者來說可以算是放下工作的負擔，但對項目經理來說往往是關鍵時刻。前期的風險評估，成本預算，需求分析，軟件設計，都是為了把項目引導到這壹刻，這時候所有的目光都會放在項目管理人員身上。妳可能會發現很多瑣碎的工作會在幾個小時內完成。此時此刻，項目經理需要保持清醒和冷靜，把最後的工作當成壹個微項目。後期認真審核項目，對項目成果、項目團隊的效率、可交付產品的價值進行分析，使審核結果作為項目管理經驗總結的壹部分。
2.？質量評估
在項目交付前，應將項目提交給相關的“質量保證”(QA)部門進行質量審查，並邀請典型用戶感受產品的質量。
3.？項目的最終交付
壹般情況下，項目交付協議會在項目前期訂立，項目交付方式分為非正式驗收和正式驗收。壹般項目完成後，會先進行非正式驗收，讓客戶體驗項目的質量，並給予反饋。最後，正式的產品驗收將在客戶確認產品質量後，以書面協議的形式進行。
4.？項目的最終報告
在項目結束時，應作出項目的最終報告，該報告可視為項目的記錄，但報告不必包括項目的所有方面。壹般最終報告應包括以下幾個方面:
(1) ?首次引入項目時的初始項目視圖。
(2) ?項目的價值評估和支持信息
(3) ?項目範圍
(4) ?項目開發過程和WBS
(5) ?項目會議紀要
(6) ?項目變更報告及變更原因。
(7) ?與項目相關的溝通過程文件
(8) ?項目審計報告和客戶驗收報告
(9) ?項目成員的績效報告
(10)項目的最終結果