软件项目开发流程以及人员职责,软件工程中五种常用的软件开发模型整理
文章目錄
- 一、軟件項目開發流程邏輯圖
- 開發流程
- 需求分析
- 概要設計
- 詳細設計
- 編碼
- 測試
- 軟件交付
- 驗收
- 維護
- 軟件維護
- 軟件升級
- 軟件項目開發流程以及人員職責
- 軟件工程中五種常用的軟件開發模型整理
- 軟件系統開發流程七大詳細步驟完整介紹
一、軟件項目開發流程邏輯圖
這張圖應該清楚的說明了一個軟件項目開發的各個流程。
項目啟動會
項目啟動會的目標是明確該產品開發項目的目標。目標不是孤立存在的，目標與計劃相輔相成，目標指導計劃，計劃的有效性影響著目標的達成。所以在執行目標的時候，考慮清楚自己的行動計劃，怎么做才能更有效地完成目標，是每個人都要詳情清楚的問題，否則，目標越是不清晰或是過高，都會影響項目的實際結果。
項目啟動會需要說明項目目標、階段劃分、組織結構、管理流程等關鍵事項，并將這些內容寫入 PPT（最好是有固定格式和范文，讓團隊內部或者公司內部共同遵守規范），需要大家達成一致。對于關鍵角色任命，事前也需要聽取相關領導和項目主要干系人的意見。
用戶需求
軟件開始開發前需要確定代價和所獲得價值的對比，也就是 ROI（Return On investment），一旦確定需要創建，就需要安排一系列的資源來支撐這個軟件的生存。這是需求的最原始描述。
為什么既要有用戶需求，也要有產品需求？因為兩者是有差異的，用戶需求由用戶提出，對技術一般不描述，只描述產品目標。產品需求是根據用戶需求轉化而來的技術實現需求，需要針對用戶提出的產品目標進行細分，總結出具體的每一個功能點，再針對每一個功能點細分為各種不同的操作流程，對每一個操作流程進行技術化定義。
用戶需求和產品需求容易發生不一樣，這是因為雖然大家都在談需求，但是出發點可能不同，造成了雙方關注點和思維方式不同。用戶需求關注的是系統如何支持業務流程，背后的需求是“實現業務目標”。技術人員關注的是合理技術方案，背后的需求是“工作量”、“實現難度”和“系統性能”。
產品需求
我們需要弄清楚產品經理或項目需求提出者為什么要做這個項目？這是最本質的業務需求。需求分析確定的業務需求，都是從業務需求推導出來的，都必須為業務需求服務。
產品需求一般包括產品需求規格說明書和產品需求矩陣。產品需求矩陣一般按照子系統、功能集、執行單元的結構列出所有的功能需求，每列則對應每項功能的工作步驟以及每個步驟的工作量。
產品需求寫完后，需要進行評審。在需求評審會上，產品、技術詳細評審需求是否完整，產品功能的正常場景是什么？是否形成閉環？異常場景是什么？是否考慮周全？
需求評審后，開發和測試負責人，分別編寫技術方案和測試用例。技術方案評審，開發負責人拉上涉及到其他系統的負責人一起討論，技術方案中必須要有業務流程圖和時序圖，業務流程圖是為了梳理開發對業務的理解，是否和需求一致。時序圖是了梳理本次需求涉及的系統交互。技術方案評審通過后，確認工作量和交付時間，反饋給產品。
總體設計
設計階段的目標主要是對待開發系統的構架進行分析和設計，并建立系統構架的基線，以便為之后的實施工作提供一個穩定的基礎。
設計階段包括了系統架構的輸出，一個好的系統架構設計可以幫助人類梳理業務邏輯且抓住核心需求，設計穩定可擴展的業務系統，評估業務開發周期和開發成本，有效的規避風險。例如蓋房子的時候得有建筑圖紙，有了圖紙，才能核算施工周期。
總體設計是整個系統的框架型設計，意義及其重大，一般情況下不能省略（只有維護項目可以省略總體設計，因為基準項目已經設計完畢），所有的產品開發項目均需要首先進行總體設計，它是設計首要步驟，決不允許本末倒置，不能出現先編碼后設計的情況，這是軟件開發的第二大痛點（第一大是需求不明確、任意變更需求）。
總體設計分為三個階段：
第一階段：初始設計。在對給定的數據流圖進行復審和精化的基礎上，將其轉化為初始的模塊結構圖。
第二階段：精化設計。依據模塊“高內聚低耦合”的原則，精化初始的模塊結構圖，并設計其中的全局數據結構和每一模塊的接口。
**第三階段：設計復審階段。**對前兩個階段得到的高層軟件結構進行復審，必要時還可能需要對軟件結構做一些精化工作。
概要設計
概要設計的目的是描述系統的每個模塊的內部設計，對總體設計和詳細設計承擔承上啟下的作用。
概要設計按照結構化設計方法進行設計。結構化設計方法的基本思路是：按照問題域，將軟件逐級細化，分解為不必再分解的的模塊，每個模塊完成一定的功能，為一個或多個父模塊服務（即接受調用），也接受一個或多個子模塊的服務（即調用子模塊）。模塊的概念，和編程語言中的子程序或函數是對應的。
概要設計階段把軟件按照一定的原則分解為模塊層次，賦予每個模塊一定的任務，并確定模塊間調用關系和接口。
在這個階段，設計者會大致考慮并照顧模塊的內部實現，但不過多糾纏于此。主要集中于劃分模塊、分配任務、定義調用關系。模塊間的接口與傳參在這個階段要制定得十分細致明確，需要編寫嚴謹的數據字典，避免后續設計產生不解或誤解。概要設計一般不是一次就能做到位，而是反復地進行結構調整。典型的調整是合并功能重復的模塊，或者進一步分解出可以復用的模塊。在概要設計階段，應最大限度地提取可以重用的模塊，建立合理的結構體系，節省后續環節的工作量。
概要設計文檔最重要的部分是分層數據流圖、結構圖、數據字典以及相應的文字說明等。以概要設計文檔為依據，各個模塊的詳細設計就可以并行展開了。
詳細設計
詳細設計階段就是依據概要設計階段的分解，設計每個模塊內的算法、流程，為每個模塊完成的功能進行具體的描述，要把功能描述轉變為精確的、結構化的過程描述。
詳細設計這個階段，各個模塊可以分給不同的人去并行設計。設計者的工作對象是一個模塊，根據概要設計賦予的局部任務和對外接口，設計并表達出模塊的算法、流程、狀態轉換等內容。這里要注意，如果發現有結構調整（如分解出子模塊等）的必要，必須返回到概要設計階段，將調整反應到概要設計文檔中，而不 能就地解決，不打招呼。詳細設計文檔最重要的部分是模塊的流程圖、狀態圖、局部變量及相應的文字說明等。一個模塊對應一篇詳細設計文檔。
概要設計階段通常得到軟件結構圖，詳細設計階段常用的描述方式有：流程圖、N-S 圖、PAD 圖、偽代碼等。而詳細設計的目的是描述某一個模塊內部的處理流程、開發方法和編碼技巧。一般來說，詳細設計由項目簡介、模塊說明（具體說明每一個模塊內部的流程、功能、邏輯、消耗以及未解決問題）、接口設計（包括內部接口和外部接口）、數據結構設計（包括物理結構和邏輯結構）、特殊處理等幾個部分構成。軟件的詳細設計，最終是將軟件系統的各個部分的具體設計方法、邏輯、功能采用文字方式進行表述。這樣在實現過程中，編碼人員原則上嚴格按此進行代碼實現即可。
編寫代碼
編寫代碼可以遵循以下幾點原則：
先做核心模塊的壓測：很多程序員，習慣把東西做完，然后等著快上線的時候才做性能測試，那么如果前面設計出了問題，這個就很頭大了。當然，后期快上線的時候也要做性能測試，但前期的我認為還是很重要的。當然，做好這一點，需要懂一些業務，你要知道業務壓力在哪里，業務請求的重心在哪里，很多時候，產品經理不講，你也要問清楚。
確保過程可控：代碼執行時一定要保持中間的輸出，比如說，每處理 10 萬條日志，寫一條狀態日志，記錄處理的日志條目數和當前的執行時間。
多打日志：很多時候，代碼寫的自己也不是很滿意，比如某個處理效率不夠優化，某個處理的方法不夠簡潔，或者擴展性比較差，代碼寫的很弱智，但可能短時間沒有辦法想清楚最合理的解決方案，考慮到上線初期這里并不是重心所在，所以也不會特意去優化它，但這種情況下我往往會留下注釋，并說明下一步優化的可能思路是什么，或者想到的可行方案是什么。
簡單易懂的邏輯：千萬不要把自己繞進去了，時間一長，誰都看不明白你的邏輯。如果邏輯真的很難在一個函數內完成，嘗試切分。
不要沉迷于框架：框架最大的問題是什么？是過于繁冗的嵌套。為什么我一直很煩框架？因為經常遇到需要一秒鐘幾千次請求的處理場景，那么調優的時候，要從數不清的框架中尋找數據處理的邏輯，尋找性能卡點，可能改動代碼只有兩行，但是找問題需要兩天。程序員記住，你的技術能力絕對不能被框架約束住。
使用熟悉、成熟的技術：很多人根本沒搞明白自己的障礙和問題在哪里，根本不知道相關技術產品的優勢和劣勢在哪里，看一堆第三方的數據測評，腦子一熱，去學新技術，然后，掉進坑里出不來，如果是創業公司，可能項目就死在里面了。使用新技術前，建議全面了解該技術的特征，適用范圍，以及不適用的范圍。
代碼審核
眾所周知，在團隊中進行代碼審查（Code Review）可以提升代碼質量，分享項目知識、明確責任，最終達到構建更好的軟件、更好的團隊。
代碼審核及其重要，一般來說每周都要做一次代碼審核。首先，代碼審核有利于你跟蹤項目進展情況，我們能真實地看到手下的人進展如何，并且更早發現他們是否誤入歧途。有時候，手下人會說“完成得差不多了！”，你去看代碼時發現什么都沒有或者只是一堆垃圾，諸如此類，總之離完成還很遙遠。在管理中，這種情況是最讓人討厭的，所以我認為代碼審查是避免這種麻煩的最佳途徑。
單元測試
要認識單元測試，首先要明白什么是“單元（Unit）”。所謂“單元”指的是代碼調用的最小單位，實際上指的是一個功能塊（Function）或者方法（Method）。所以單元測試指的就是對這些代碼調用單元的測試。
單元測試是一種白盒測試，就是必須要對單元的代碼細節很清楚才能做的測試。所以，單元測試的編寫和執行都是由軟件工程師來做的。相對于單元測試，還有集成測試。集成測試基本都是黑盒測試，主要是由測試人員根據軟件的功能手冊來進行測試，需要有專門的測試環境配合。集成測試又分功能測試、回歸測試等。
需要單元測試的代碼實際上是開發人員自己寫的邏輯，測試邏輯所依賴的環境是否正常不是單元測試的目的。在環境訪問代碼中引入邏輯，只會讓邏輯更難測試，導致邏輯代碼無法進行單元測試。因此，可單元測試的代碼，才能夠采用單元測試。判斷可測試的代碼還有一個方法，就是看這個方法能否用一個 main 函數直接運行，如果可以的話就是可單元測試的代碼?？蓽y試的代碼還有另一個特征，就是該方法單元的參數，開發人員可以自由模擬，不需要依賴外部環境。
集成測試
集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。一些局部反映不出來的問題，在全局上很可能暴露出來。
集成測試是在軟件系統集成過程中所進行的測試，其主要目的是檢查軟件單位之間的借口是否正確。它根據集成測試計劃 ，一邊將模塊或其他模塊組合成越來越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各個組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。也可以理解為在軟件設計單元、功能模塊組裝、集成為系統時，對應用系統的各個部件（軟件單元、功能模塊接口、鏈接等）進行的聯合測試，以決定他們能否在一起共同工作，部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。
系統測試
系統測試階段包括系統測試方案及用例編寫、功能性測試、性能測試、穩定性測試。
為了驗證需求分析確定的功能是否齊全并被正確實現，同時還要對安裝、部署、適應性、安全性、界面等非功能性需求進行測試。系統測試也有測試人員負責，應該在需求分析完成后進行設計，在集成測試完成后進行實施。
功能性測試一般由獨立測試小組采用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。在經過以上各階段測試確認之后，把系統完整地模擬客戶環境來進行的測試。系統測試是將已經確認的軟件、計算機硬件、外設、網絡等其他元素結合在一起，進行信息系統的各種組裝測試和確認測試，其目的是通過與系統的需求相比較，發現所開發的系統與用戶需求不符或矛盾的地方，從而提出更加完善的方案。
性能測試驗證系統的穩定性和效率，檢查系統是否滿足規定的性能要求。性能測試通常選擇一些典型的功能，檢驗這些功能在大量用戶同時使用系統時系統是否穩定。性能測試由測試人員負責，可以在系統測試完成后進行，也可以對重要模塊先進行性能測試，可以貫穿整個測試周期，目的是盡早發現系統的性能瓶頸并提早解決。
穩定性測試和性能測試都必須等到系統基本沒問題、趨于穩定時再進行才有效果，否則很難順利測下去，出現異常也不能定位究竟是系統架構的問題，還是功能上的缺陷。
穩定性測試（亦可稱可靠性測試）通過給系統加載一定的業務壓力，讓系統持續運行一段時間（一般為 7x24 小時），檢測系統是否能夠穩定運行。
產品發布
產品發布是系統測試結束后的最后一步，通常在軟件產品開發過程中不需要產品試制環節，可以直接上線，只需要系統測試員輸出系統測試報告并批準產品發布（上線）就可以了。
產品發布前需要通過產品發布說明會形式，對整個產品開發過程從立項開始回溯過程，指出整個過程中的不足點，總結經驗，為下一個項目提供經驗案例。這一會議可以通過正式會議形式召開，需要召集產品經理、主要開發人員、測試人員、上級領導等參與，準備充分，盡最大可能說清楚這個產品發布之后的效果、效益，為上線后的價值評估做準備。這一環節不可缺少，即便在互聯網公司，迭代速度很快的情況下，這一環節也需要滿足。
開發過程復盤
其實開發過程體系里并沒有這一過程，但它卻非常重要。
所有的總結，只有帶著問題去思考才會有收獲，這就是復盤。不論說多少，如果沒有過類似的經驗，就很難有很強的共鳴。看清一個問題最好的方式，就是曾經處在一個問題的兩個不同的角色中。
總結項目經驗教訓的目的，在于總結問題、分析原因，避免以后犯同樣的錯誤，而不是追究誰的責任。
假設一個需求理解的缺陷，如果在需求階段發現，修改一下可能只要一個小時，但是如果到了設計完成時發現這個缺陷，因為涉及的人員、文檔增多，估計要一天時間，而如果等到代碼都編寫完成時才發現這個缺陷，可能需要十天八天了。如果缺陷沒被發現，而是直接到了生產系統中呢？這就不是工作量的問題了，估計損失就難以估計了。在質量管理的理論中，缺陷每延遲一個階段被發現，修復的代價就要乘上十倍。
再看一個百度百科的
開發流程
需求分析
1.相關系統分析員向用戶初步了解需求，然后用相關的工具軟件列出要開發的系統的大功能模塊，每個大功能模塊有哪些小功能模塊，對于有些需求比較明確相關的界面時，在這一步里面可以初步定義好少量的界面。
2.系統分析員深入了解和分析需求，根據自己的經驗和需求用WORD或相關的工具再做出一份文檔系統的功能需求文檔。這次的文檔會清楚列出系統大致的大功能模塊，大功能模塊有哪些小功能模塊，并且還列出相關的界面和界面功能。
3.系統分析員向用戶再次確認需求。
概要設計
首先，開發者需要對軟件系統進行概要設計，即系統設計。概要設計需要對軟件系統的設計進行考慮，包括系統的基本處理流程、系統的組織結構、模塊劃分、功能分配、接口設計、運行設計、數據結構設計和出錯處理設計等，為軟件的詳細設計提供基礎。 [2]
詳細設計
在概要設計的基礎上，開發者需要進行軟件系統的詳細設計。在詳細設計中，描述實現具體模塊所涉及到的主要算法、數據結構、類的層次結構及調用關系，需要說明軟件系統各個層次中的每一個程序(每個模塊或子程序)的設計考慮，以便進行編碼和測試。應當保證軟件的需求完全分配給整個軟件。詳細設計應當足夠詳細，能夠根據詳細設計報告進行編碼。
編碼
在軟件編碼階段，開發者根據《軟件系統詳細設計報告》中對數據結構、算法分析和模塊實現等方面的設計要求，開始具體的編寫程序工作，分別實現各模塊的功能，從而實現對目標系統的功能、性能、接口、界面等方面的要求。在規范化的研發流程中，編碼工作在整個項目流程里最多不會超過1/2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提高，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在很多研發過程中都出現過。編碼時的相互溝通和應急的解決手段都是相當重要的，對于程序員而言，bug永遠存在，你必須永遠面對這個問題！
測試
測試編寫好的系統。交給用戶使用，用戶使用后一個一個的確認每個功能。軟件測試有很多種：按照測試執行方，可以分為內部測試和外部測試；按照測試范圍，可以分為模塊測試和整體聯調；按照測試條件，可以分為正常操作情況測試和異常情況測試；按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試。以上都很好理解，不再解釋?？傊?#xff0c;測試同樣是項目研發中一個相當重要的步驟，對于一個大型軟件，3個月到1年的外部測試都是正常的，因為永遠都會有不可預料的問題存在。完成測試后，完成驗收并完成最后的一些幫助文檔，整體項目才算告一段落，當然日后少不了升級，修補等等工作，只要不是想通過一錘子買賣騙錢，就要不停的跟蹤軟件的運營狀況并持續修補升級，直到這個軟件被徹底淘汰為止。
軟件交付
在軟件測試證明軟件達到要求后，軟件開發者應向用戶提交開發的目標安裝程序、數據庫的數據字典、《用戶安裝手冊》、《用戶使用指南》、需求報告、設計報告、測試報告等雙方合同約定的產物。
《用戶安裝手冊》應詳細介紹安裝軟件對運行環境的要求、安裝軟件的定義和內容、在客戶端、服務器端及中間件的具體安裝步驟、安裝后的系統配置。
《用戶使用指南》應包括軟件各項功能的使用流程、操作步驟、相應業務介紹、特殊提示和注意事項等方面的內容，在需要時還應舉例說明。
驗收
用戶驗收。
維護
根據用戶需求的變化或環境的變化，對應用程序進行全部或部分的修改。 [2] [3]
軟件維護
維護是指在已完成對軟件的研制（分析、設計、編碼和測試）工作并交付使用以后，對軟件產品所進行的一些軟件工程的活動。即根據軟件運行的情況，對軟件進行適當修改，以適應新的要求，以及糾正運行中發現的錯誤。編寫軟件問題報告、軟件修改報告。
1、軟件數據庫管理
2、用戶跟蹤培訓
3、故障分析解決
軟件升級
需求調整分析
軟件功能拓展
優化系統
軟件項目開發流程以及人員職責
實行軟件工程項目管理：
▲ 項目經理（負責人）：項目經理（負責人）對整個項目負完全責任，是指導、控制、管理和規范某個軟件和軟/硬件系統建設的人，項目經理（負責人）是最終對客戶負責的人。
▲ 軟件項目經理（負責人）：軟件項目經理（負責人）對一個項目的所有軟件活動負完全責任，控制一個項目的所有軟件資源，按照軟件約定與項目經理（負責人）打交道。
▲ 軟件工程組： 軟件工程組是負責一個項目的軟件開發和維護活動（例如：需求分析、設計、編程和測試）的人員（包括管理人員和技術人員）。
▲ 系統工程組： 系統工程組是負責下列工作的人（既有經理也有技術人員）的集團：規定系統需求；將系統需求分配給硬件、軟件和其它成分；規定硬件、軟件和其它成分之間的界面；以及監控這些成分的設計和開發以保證它們符合其規格說明。
▲ 系統測試組：系統測試組是一些負責策劃和完成獨立的軟件系統測試的個人（既有經理又有技術人員）的集團，測試的目的是為了確定軟件產品是否滿足對它的要求。
▲ 軟件質量保證組： 軟件質量保證組是一些計劃和實施項目的質量保證活動的個人（既有經理又有技術人員）的集團，其工作的目的是保證軟件過程的步驟和標準得到遵守。
▲ 軟件配置管理組： 軟件配置管理組是一些負責策劃、協調和實施軟件項目的正式配置管理活動的個人（既有經理又有技術人員）的集團
總體流程如下：
計劃階段－》需求分析階段－》軟件開發階段－》測試階段－》完成
*一、項目計劃階段*
項目計劃草案和風險管理計劃作為第一步，當有一個商業機會后，根據公司高層負責制定的初步商業計劃書來完成項目的計劃草案，確定、分析項目風險并確定其優先級，還要制定風險解決方案。本階段的目的是確立產品開發的經濟理由。
當確定開發之后則制定軟件開發計劃、人員組織結構定義及配備、過程控制計劃。
（ 1 ）項目計劃草案
項目計劃草案應包括產品簡介、產品目標及功能說明、開發所需的資源、開發時間和里程碑。
（ 2 ）風險管理計劃
也就是把有可能出錯或現在還不能確定的東西列出來，并制定出相應的解決方案。風險發現得越早對項目越有利。
（ 3 ） 軟件開發計劃
軟件開發計劃的目的是收集控制項目時所需的所有信息，項目經理根據項目計劃來安排資源需求并根據時間表跟蹤項目進度。項目團隊成員根據項目計劃以了解他們的工作任務、工作時間以及他們所依賴的其他活動。
可將計劃分成總體計劃和詳細計劃，總體計劃中每個任務為一個里程碑，詳細計劃中必須將任務落實到個人。
軟件開發計劃還應包括產品的應收標準及應收任務（包括確定需要制訂的測試用例）。
（ 4 ）人員組織結構定義及配備
常見的人員組織結構有垂直方案、水平方案、混合方案。垂直方案中每個成員充當多重角色。水平方案中每個成員充當一到兩個角色?；旌戏桨竸t包括了經驗豐富的人員與新手相互融合。具體選擇根據人員實際技能情況進行選擇。
（ 5 ）過程控制計劃
過程控制計劃的目的是收集項目計劃正常執行所需的所有信息，用來指導項目進度的監控、計劃的調整，確保項目按時完成。
*二、需求分析階段*
需求分析階段的目的是在系統工作方面與用戶達成一致。
（ 1 ）軟件需求規約
詳細說明系統將要實現的所有功能。
（ 2 ） 用戶界面原型
可以有三種表示方法：圖紙（在紙上）、位圖（繪圖工具）、可執行文件（交互式）。
*三、* *軟件開發階段*
本階段從物理上實現目標系統。采用了面向對象方法。
（ 1 ）軟件架構
說明軟件的組織結構、部署結構及運行環境。
（ 2 ）類設計
定義類之間的關聯和類的屬性、方法。
（ 3 ）數據庫設計
定義數據庫表之間的關聯和各個表的字段。
（ 4 ）編碼和單元測試
按照設計文檔進行編碼，每完成一個模塊應進行單元測試。
（ 5 ）集成系統
按軟件組織結構的要求將各個子系統組合起來。
*四、測試階段*
測試的目的是在發布之前找出程序的錯誤。包括：核實每個模塊是否正常運行（參考設計文檔）、核實需求是否被正確實施（參考需求文檔）。
（ 1 ）測試計劃
收集和組織測試信息，為測試工作提供指導。
（ 2 ）測試數據
盡量使用真實數據。
（ 3 ） 測試報告
記錄測試結果，詳細描述問題，提出解決辦法。
（ 4 ）幫助文件和用戶操作手冊
*五、* *管理軟件開發過程*
有以下幾方面地工作：
（ 1 ）組織會議
討論會議、總結會議等。
（ 2 ）評審程序
對各個階段的工作結果進行審核。
（ 3 ）協調人員
（ 4 ） 配置管理
? 使用一些配置管理工具進行開發文檔管理，如： visual sourcesafe ， teamsouce 等
*六、* *各參與角色的具體職責描述及對人員的要求*
（ 1 ） 項目經理
職責：
1 、 制定產品的目標。
2 、 制定各個工作的詳細任務表，跟蹤這些任務的執行情況，進行控制。
3 、 組織會議對程序進行評審。
4 、 綜合具體情況，對各種不同方案進行取舍并做出決定。
5 、 協調各項目參與人員之間的關系。
人員要求：
對產品有激情，具有領導才能。
對問題能正確而迅速地做出確定。
能充分利用各種渠道和方法來解決問題。
能跟蹤任務，有很好地日程觀念。
能在壓力下工作。
（ 2 ）系統分析員
職責：
1 、 了解用戶需求，寫出《軟件需求規約》。
2 、 建立用戶界面原型。
人員要求：擔任系統分析員的人員應該善于協調，并且具有良好的溝通技巧。擔任此角色的人員中必須要有具備業務和技術領域知識的人才。
（ 3 ）設計員
職責：
1 、 定義類的方法和屬性以及各個類之間的關聯，畫出類圖。
2 、 進行數據庫設計。
人員要求： 掌握面向對象分析與設計技術，統一建模語言 (uml) 。
（ 4 ）程序員
職責：按項目的要求進行編碼和單元測試。
人員要求：良好的編程技能和測試技術。
（ 5 ）測試員
職責： 執行測試，描述測試結果，提出問題解決方案。
人員要求：了解被測試的系統，具備診斷和解決問題的技能，編程技能
小結一下：
可行性研究：一般只有大型的項目才有。
一、需求分析
1、采集、整理需求，寫出需求說明書（ 敘述該項軟件開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟件開發的背景材料。解釋被開發軟件與其他有關軟件之間的關系。詳細說明系統將要實現的所有功能。）
需求設計文檔（主要把握以用戶需求說明書為基線原則。主要內容與用戶需求說明書相似，用戶需求說明書是需求說明書站在用戶角度、使用通俗語言編寫的，軟件需求規格說明書則是開發者角度、使用開發者的語言編寫的，主要差異在于前者是對外的，后者是對內的，通過前者得出后者。）
二、架構設計
（一）概要設計
1、系統結構設計： 定義和設計軟件的模塊化，軟件系統各模塊之間的關系。
2、數據設計：定義數據庫功能模塊表結構。數據庫設計要考慮到以后的擴展性。
（二）詳細設計： 逐個地給出各個層次中的每個程序的設計考慮。
三、編碼
代碼規范
四、軟件測試
開發人員內部測試（內測）、交給客戶的公開測試（公測）
軟件工程中五種常用的軟件開發模型整理
軟件工程中五種常用的軟件開發模型整理
軟件系統開發流程七大詳細步驟完整介紹
系統軟件開發方面有很多信息要素各類問題,今天跟大家來談談流程問題,軟件開發公司的流程是怎樣的呢?流程很重要嗎?這也將幫助您在選擇軟件開發公司合作時,多一重保障。
*系統軟件開發流程七大步驟介紹：*
*步驟********一********:確定開發功能。*
1.產品經理向用戶初步了解需求，進行市場調查，用word列出開發系統的大功能模塊，每個大功能模塊有哪些小功能模塊，在需求明確相關接口時，可以在此步驟中初步定義設計。
2.產品經理和項目經理深入理解和分析需求，根據自己的經驗和市場情況，用辦公工具、原型設計工具等制作詳細的功能需求文件。本次文檔將明確列出系統的大致功能模塊，大功能模塊有哪些小功能模塊，并列出相關接口和接口功能。對整個項目需求進行審查，哪些功能優先于第一階段開發？什么樣的功能很難實現？
3.產品經理向用戶再次確認需求，簽訂合同，進入研究開發。
*步驟********二********:設計開發。*
1.概要設計:首先，開發人員需要概要設計軟件系統，即系統設計。概要設計需要考慮軟件系統的設計，包括系統的基本處理流程、系統的組織結構、模塊劃分、功能分配、接口設計、運行設計、數據結構設計和錯誤處理設計等，為軟件的詳細設計提供基礎。
2.詳細設計:在概要設計的基礎上，開發人員需要進行軟件系統的詳細設計。在詳細的設計中，需要說明與具體模塊相關的主要算法、數據結構、類別的層次結構和調用關系，說明軟件系統各層次的各個程序(各模塊或子程序)的設計考慮，進行代碼和測試。必須保證軟件的需求完全分配給整個軟件。詳細設計應充分詳細，并可根據詳細設計報告編碼。
*步驟********三********:代碼開發。*
在軟件編碼階段，開發者根據軟件系統的詳細設計方案，對數據結構、算法分析和模塊實現等方面的設計要求，開始具體的編寫程序，分別實現各模塊的功能，實現對目標系統的功能、性能、界面、界面等方面的要求。
*步驟********四********:產品測試。*
進行軟件測試，測試過程按四個步驟進行，即單元測試、集成測試、確認測試和系統測試和發布測試。測試制作的系統，如果沒有問題的話可以準備交貨。
*步驟********五********:軟件交付。*
軟件測試證明軟件達到要求后，軟件開發者應向用戶提交開發的目標安裝程序、數據庫數據字典、用戶安裝手冊、用戶使用指南、需求報告、設計報告、測試報告等雙方合同約定內的產物。
*步驟********六********:軟件檢查。*
軟件配送查詢所有功能都可以實現，開發商配送項目，客戶配送尾款。
*步驟********七********:售后服務。*
根據需求方的需求和雙方的合同規定，開發人員履行合同，對產品進行后期運營和維護。
以上就是關于****軟件系統開發****流程的相關介紹，軟件開發流程看似簡單,但卻真正影響軟件開發,關乎客戶自身利益。所以我們的客戶在選擇公司合作的時候,也要特別注意一下合作流程問題。選擇一個負責任的公司,那么合作就會非常愉快,常常是事半功倍的效果。****互聯網助手****在互聯網軟件開發這塊已經有10年的經驗,合作過各行各業的客戶,也有豐富的案例,我們對待每一位客戶都是從專業流程出發,充分考慮到客戶需求與利益,既有強大的實力,也有服務客戶的誠心,是值得信賴的專業的軟件定制開發服務公司。
總結
以上是生活随笔為你收集整理的软件项目开发流程以及人员职责,软件工程中五种常用的软件开发模型整理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 前端学习（3115）：react-hel
- 下一篇： 桌面软件开发框架大赏