首先 看一下基本軟體專案開發流程圖

其中

1.需求分析：
　　通過對客戶業務的瞭解和與客戶對流程的討論對需求進行基本建模，最終形成需求規格說明書。

2.總體設計：
　　通過分析需求資訊，對系統的外部條件及內部業務需求進行抽象建模，最終形成概要設計說明文件。

3.詳細設計：
　　此部分在對需求和概要設計的基礎上進行系統的詳細設計（也包含部分程式碼說明）。 

4.開發程式設計：
　　對系統進行程式碼編寫。

5.測試分析與系統整合：
　　對所有功能模組進行模擬資料測試及其它相關性測試並整合所有模組功能。

6.現場支援：
　　系統上線試執行進行現場問題記錄、解答。

7.系統執行支援：
　　系統正式推產後，對系統進行必要的維護和BUG修改

需求分析是怎樣做的？

需求分析是構建軟體系統的一個重要過程。 一般，把需求型別分成三個型別： 

1、業務需求（business requirement）
　　反映了組織機構或客戶對系統、產品高層次的目的要求，它們在專案檢視與範圍文件中予以說明。 
2、使用者需求(user requirement) 
　　文件描述了使用者使用產品必須要完成的任務，這在使用例項文件或方案指令碼說明中予以說明。 
3、功能需求(functional requirement)
　　定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。 

業務需求和使用者需求是軟體需求分析的基礎，也是軟體構建的前提。
 
系統分析員通過對業務需求和使用者需求的分解，將其轉換成可以形式化描述的軟體功能需求。
開發軟體系統最為困難的部分，就是準確說明開發什麼。這就需要在開發的過程中不斷的與使用者進行交流與探討,使系統更加詳盡,準確到位。這就需要確定使用者是否需要這樣的產品型別以及獲取每個使用者類的需求。 
　　客戶也經常是矛盾的。事實上，很少有客戶能夠明確的知道怎樣的一個系統對自己是最有益處的，他們往往在集中方案之間徘徊，於是經常產生需求的變動。生產廠商經常陷入客戶自己的矛盾之中。 

　　客戶的負面影響可能對於能夠在預算內按時完成專案產生很大的影響。儘管客戶需要對需求的質量負責任，但是，當一個軟體專案因為客戶事先沒有預料到的情況而導致失敗的時候，即使客戶不會追究開發方的責任，就軟體專案本身而言，也已經是失敗的。
 
總結： 
 

良好的需求分析是軟體成功的基礎。
在軟體專案整個過程中系統分析員主動進行溝通，提出指導性意見。當軟體融合了客戶和系統分析員雙方智慧，其質量將會進一步得以提高。

軟體開發管理規範流程圖

摘專案管理的根本目的是按時、保質、保量完成預期交付的成果。專案管理要讓整個組織能清楚理解專案實施的目的、影響、進度，應做到專案組所有員工都應理解專案實施的原因、意義及客戶的要求。在專案管理中還能看到公司高層領導通過實際行動表現出來的對於專案實施的支援與幫助，通過以制度化管理來組織合理安排員工的工作職責和角色轉換。為滿足上述要求，就必須讓員工、企業、客戶能接受並適應新的“軟體專案開發管理規範”。

1.啟動階段

　　這個階段的工作目的是決定一個專案是否需要啟動。為了達到這個目的，首先要明確專案的總體戰略目標，對專案的需要建立認同。即確定到底需要做什麼、開發什麼產品或提供什麼服務，以及需要解決什麼樣的問題和需要滿足客戶或市場的什麼要求等，同時還要總結專案工作的範圍、所需資源、大約開支、各種風險，以及該專案不執行的其他替代選擇等。這些代表了對整個專案目標從戰略角度和巨集觀層次所進行的分析，通過專案的意向書總結出來，由此確證客戶或專案發起人和贊助者的要求與期望，並幫助他們判定專案是否上馬。專案意向總結書的通過及專案被批准上馬形成了這個專案的起始點。

• 產品領域研究

　　研究產品所在領域的狀況，為專案論證提供依據。研究內容包括：

產品領域的現狀和前景
產品領域的商業模式和業務流程
產品的價值和盈利空間
產品的特性和複雜度

• 技術可行性研究

　　研究產品的實現技術，總結技術可行性。研究內容包括：

類似產品的當前實現技術和技術趨勢
實現技術的候選方案
各個方案的優點、成本和風險
開發團隊與實現技術的匹配情況

• 專案論證

　　基於商業和技術等方面對專案的可行性進行論證，確定專案是否開展。如果開展專案，則進一步論證專案的總體方案。

　　論證的內容包括：

商業可行性
技術可行性
當前產品與類似產品的比較
專案收益和前景
專案的成本和風險
專案的總體方案

• 確定專案目標和範圍

　　專案開始時，所有相關人員必須對專案的目標和範圍達成共識，形成共同的專案願景。並把願景敘述為《專案開發大綱》向相關人員傳達。

《專案開發大綱》的內容包括：

概 述	用三到五張圖表來描述產品目標、功能、平臺、客戶、進度表和開發職責
高階功能	用一個段落來綜述產品，再用一個段落來描述每個重要的功能
不實現的功能	用一個段落來描述每個對產品有用的但本專案不實現的功能
涉 眾	用一個段落來明確每個重要的涉眾群體和他們的風險股本
專案需求	用一個段落來講述每個重要的專案需求
專案風險	按風險暴露量對每個重要的專案風險都用一個段落來討論
專案回報	用一個段落綜述產品的回報，其後再對每個重要的專案回報都用一個段落來討論
結 論	用一到三個段落將上述所有部分聯絡起來，明確專案的需求和風險，再用論點和論據來總結為什麼這個專案會成功

2.計劃階段

　　這個階段的工作是為整個專案做計劃。專案開始後，首先要確定專案的具體範圍，明確定出專案到底要做什麼，總結、歸納並定出產品的功能。然後進一步制定專案的計劃，列出每項具體工作，並建立所有工作任務的重要性及順序；確定每項工作的執行人和所需資源；根據人員的配置和能力設定各項工作和整個專案的完成時間表。

• 規模、工作量評估

　　圍繞各項計劃的制定工作對專案的規模、工作量等進行評估，評估的內容包括：

模組數量與複雜度
輸入、輸出和對外介面等數量與複雜度
SLOC和功能點
非生產性的支援工作量
開發工作量（人月）
進度與里程碑
進度風險

• 定製專案開發計劃

　　專案開發計劃體現了專案組對整個開發週期的預期，指定了專案開發的總體方針。與其他計劃一樣，專案開發計劃不是固定不變的，在執行過程中要對計劃進行監控，可能會根據實際情況修改計劃並重新發布。

《專案開發計劃》的內容包括： 

概 述	用三到五張圖表來描述產品目標、功能、平臺、客戶、進度表和開發職責。 （《專案開發計劃》的概述部分應該是《專案開發大綱》中概述部分的拷貝。當專案計劃改變時，修訂《專案開發計劃》的概述部分而不是修訂《專案開發大綱》。這樣，以後在進行專案評價時，通過比較《專案開發大綱》和《專案開發計劃》的概述，就能看出專案是如何改變的）
高階功能	用一到五頁的篇幅來概述產品的功能，其中，要包括這些功能的附加資訊（開發者需要這樣的資訊來了解實現需求）。
專案成員	確定軟體工程職能角色，以及分配到這些角色的人員數量。
軟體過程	概述這個專案中所應用的軟體過程。 （具體內容可在《質量保證計劃》中定義）
軟體工程方法	概述這個專案中所應用的軟體工程方法和技術。 （具體內容可在《質量保證計劃》中定義）
進度和工作量	這一部分要表達出整個專案進度和工作量的估計。其中要包括： 對固定不變的里程碑和同步點的解釋 在評估中的設想情況、評估中的不準確性的可能來源 隨著專案的進展如何更新評估 （具體進度表內容可在《開發進度表》中定義）
風險管理計劃	概述這個專案中風險管理計劃。 （具體內容可在《風險管理計劃》中定義）
測 量	概述這個專案中要收集的測量。
軟體工具	列出要使用的每一項軟體工具，以及該工具所支援的任務。
專案支援	硬體支援 明確所需的硬體，包括那些需要移動、獲取或升級的硬體。 軟體支援 明確所需的軟體，包括需要獲取、安裝或升級的軟體件。 人力支援 由哪個人、部門或團隊為開發組的哪項任務提供支援。

• 定製風險管理計劃

　　風險管理任務包括：風險識別、風險分析、確定風險優先順序、定製風險化解方案、風險化解和風險監控

　《風險管理計劃》定義這些任務的執行流程和人員分配。

　　《風險管理計劃》的內容包括：

概 述	用文字和圖表概述風險管理任務的總體執行流程。
風險識別	詳細說明“風險識別”任務的實施細節和各項工作的負責人。
風險分析	詳細說明“風險分析”任務的實施細節和各項工作的負責人。
確定風險優先順序	詳細說明“確定風險優先順序”任務的實施細節和各項工作的負責人。
定製風險化解方案	詳細說明“定製風險處理方案”任務的實施細節和各項工作的負責人。
風險化解	當風險發生時，需要採取相應的措施化解風險。 這部分的內容是描述風險化解工作的操作規範和流程。
風險監控	詳細說明風險監控任務的實施細節和各項工作的負責人。

　　風險管理中通常會用到《Top N 風險列表》，風險列表按照風險暴露量排序列出當前專案中主要的N個風險，《Top N 風險列表》的內容包括：

本週排名	本週的排名（如果本週已被完全化解用“---”表示）
上週排名	上週排名（如果是新識別的風險用“---”表示）
上表週數	該風險已上表的週數
風 險	風險的名稱或簡述
類 型	風險型別（只針對進度相關的風險）： 計劃編制 組織和管理 設計和實現 客戶和需求 承包商 產品 人員 過程 技術 外部環境 開發環境
發生概率	風險發生的百分比概率
損失程度	風險發生時損失的進度（工作日或工作周）
暴露量	發生概率 X 損失程度
狀 態	風險的當前狀態：未發生、已發生、已化解
化解方案	簡述風險的化解方案，如果有具體的化解方案文件則連結到相應文件
化解進度	對已發生的風險，簡述化解進度（未發生的風險用“---”表示）

• 定製質量保證計劃 

　　保證工作質量的一個重要步驟是制定一套合理的質量保證計劃並貫徹執行。

　　《質量保證計劃》的內容包括：

概 述	說明編寫的目的、適用範圍以及對相關人員的要求等
軟體過程	詳細說明這個專案中所應用的軟體過程。
軟體工程方法	詳細說明這個專案中所應用的軟體工程方法和技術。
工作規範	對工程方法中的各種工作任務進行規範，明確執行的時機、流程和準則等。這些工作任務包括： 常規開發活動 （需求分析、架構設計、詳細設計、編碼和測試、釋出和實施等） 會議 （工作例會、進度會議、審查會議等） 評審 （方案評審、技術評審、質量評審等） 測量 （產品規模測量、進度測量、缺陷率測量、測試覆蓋率測量等） 其他活動 （技能培訓、資料收集、內部流、客戶溝通等）

• 定製開發進度計劃

　　基於當前對專案的規模和工作量評估，定製初步的開發進度表，作為專案開發計劃的組成部分。

　　《開發進度表》的內容包括：

專案的開始和結束時間
專案各個階段的開始和結束時間
每個階段的工作任務及其開始和結束時間
每個工作任務的子任務的及其開始和結束時間
里程碑和同步點
角色的定義和任務分配

 　　作為跟蹤專案進度的重要依據，進度表在專案推進過程中需要不斷細化。另外，當實際進度與計劃進度出現偏差時，需要修改進度表並重新發布。

相關推薦