軟件開發流程思考及建議

• 通常開發團隊須要如下幾個組成部分：
  • 開發負責人：要求懂技術和開發管理，較強的溝通能力，負責系統的架構、編碼質量和開發進度的控制、難題攻克等任務、團隊建設和管理；（建議1人）
  • 開發人員：能夠由經驗豐富的高級開發和經驗通常的普通開發組成；（建議2-3人，大型項目根據狀況適當增長）
  • 測試人員：通常大型系統須要一個測試組，須要有專業的、經驗豐富的測試組長負責（通常小型開發團隊因爲各類緣由不去配備專有的測試人員，但軟件的測試工做不能省去，全部，不少時候就由開發人員自行測試）；（建議1-2人，複雜項目可能須要5人以上）
  • 界面設計或美工：通常有條件的仍是須要一個界面UI的設計的專業人員負責界面佈局、功能設計之類的工做。（建議1-2人）

 

以上建議必須有的人員爲：開發負責人、開發人員，最好有測試人員，由於這直接關係到最終產品的實現和質量。

 

• 通常的開發分爲如下幾個步驟：
  • 需求確認

通常該步驟須要開發團隊負責人（有時也會整個團隊參與）與需求提供方開會（或其餘形式）溝通，來了解需求；而後，根據客戶需求進行需求分析，能夠出一份分析報告，好比直接出需求分析報告或需求設計文檔；最後，根據分析結果或需求設計進行進一步的溝通來肯定需求。

該步驟一搬能解決70-80%左右的需求，由於開發階段或者開發後期確定會出現新的需求或在對已有需求的進行修改，可是這已經能夠開始考慮系統的設計和開發了。

• • 系統設計

在大體的需求定下來以後接下來該着手設計系統了，這個環節能夠考慮和團隊中一些經驗較豐富，技術較好的同事一塊兒討論設計，但必定要注意效率，不要一味地討論，而不定不下來設計方案。

最後對系統的設計定好後就要好好設計每一部分的具體實現了，這時通常就是寫詳細設計文檔（也有邊開放邊設計、或者開發後補設計的，但我不建議這樣，至少也要儘可能作到設計一部分就開始進行這一部分的開發），詳細設計的目的是爲後面的開發進行服務和約束的。

服務體如今在開發的時候能夠直接參考詳細設計就很快明白如何實現，而再也不須要從新考慮應該怎麼實現，以此來提升開發效率。

約束體如今在開發時以避免忘去最初的想法，而採用其餘方式實現（頗有可能實現的原來或結果都出現很大差別），最終頗有可能偏離本來的初衷，從而影響系統的開發進度、質量等，致使很大不良後果。

• • 系統開發

根據設計階段的設計指導開發團隊進行系統的開發。

• • 系統測試

在系統的開發過程當中和系統部分功能開發完成後以及最後所有完成後都須要進行測試，也就是測試是分佈在開發過程當中的各個階段。

• • 系統交付

開發完成後，最終測試完畢就能夠交付系統了，此時的系統應該以及實現主要功能、不該該存在明顯BUG，基本可以保證平常使用。

最終完成後後續還須要不斷升級，進行修復和增長新的功能。

 

• 通常的開發流程

在之前的開發中大多數採用的是瀑布是的流水線式的開發，這種開發方式有不少問題，常常會影響實際的開發進度、開發質量、甚至致使最終的項目失敗。

如今通常不會採用這種單純的開發方式。我認爲能夠考慮分步分階段的方式進行。由於在實際開發過程當中常常會趕上需求變動的問題，甚至有時會推翻前面的從新再來；或者最初設計的問題致使開發難以進行下去；人員流動帶來的種種問題等等。因此，我以爲按照如下的方式進行開發會有很大好處：

首先，前期肯定大體需求後先定好系統架構，各功能模塊的設計，把核心的功能肯定後先設計出一套可行的方案，最好能出一個簡單的DEMO，能夠不實現具體功能，但要可以說明對需求的實現，可以讓用戶看懂你的實現方式，目的是讓用戶再次肯定需求。若是這一步沒有問題，那就能夠開發這部分功能了，其餘系統功能相似。

（這個步驟肯能會貫穿到系統開發的中前期，通常不多有到後期還作大量的調整和修改的，若是有小的調整也須要在肯定需求後再去作後面的步驟）

第二步，開發已肯定部分的功能，並最好可以在開發時每開發一個實現方法測試一個（最好能作到這一點，這會對後續的測試和BUG的修改都有幫助——不少問題都會在這時就被發現，能夠節省後期的工做量，通常這種測試被叫作單元測試）。在開發完一個功能或一個完整的模塊後也要進行整個功能模塊的測試，這能夠發現一些在單元測試階段不能發現的問題。另外，在每次提交一個測試好的功能後最好能進行代碼審查，最好由經驗豐富、技術較強的開發人員，或者技術負責人來審查，這個過程目的是及時的發現不規範的代碼——規範代碼和規範開發的目的是爲了之後的代碼維護和其餘開發人員修改提供方便——個性的代碼書寫少了，理解的過程就會大大縮短。

（建議單元測試、功能測試等各類測試和代碼審查要貫穿在整個的代碼編寫的開發階段）

第三步，在開發進行必定的時間後，常常會出現新的需求或者需求的變動，因此，咱們須要再次的瞭解需求和確認，以便可以及時更正系統設計時的不足或者開發產生的誤差，若是最後或者後期纔去作這些，到時候系統的架構就已經沒法修正，即使只是一個小模塊極可能都很難修改了。因此，這個過程很重要，並且，須要在整個開發階段中不斷的重複執行，不斷的修正系統的設計和開發。——須要注意的是，這裏所說的修正系統設計並非說系統的總體框架或者核心的結構能夠隨便修改，這些通常在定下來以後除非很是嚴重的問題，致使沒法進行後續開發是不能調整和修改的，尤爲是在中後階段更不能調整核心設計。沒有任何設計開始就說徹底合理的，全部，容許必定的調整，但通常會在後面須要調整的會愈來愈少，最後可以達到局部的、小範圍的修改代碼就比較理想了。

（階段性的需求確認、系統的重構等工做基本會不斷的重複，通常需求確認是貫穿編碼的大部分時間的，並且要視狀況而定，不能機械的固定執行；系統重構須要慎重考慮——最好可以在前期穩定下核心架構，不隨便修改。通常代碼級的重構較多，並且多數在中後期考慮）

第四步，在第三步後必定會有對系統架構或代碼方面的變化，此時必定要作第二步中說到的一些測試，並且，頗有可能在修改了某一功能後還要進行相關功能的聯合測試，以保證修改的功能測試經過的同時不會影響到其餘功能、不會影響到整個系統的完整性、穩定性、高效性。

（測試很重要。必定優先保證系統的穩定性，其次考慮效率問題）

最後，在開發過程當中屢次重複第3、四步的工做後基本就能保證系統的順利完成了，在系統的開發後期和完成階段必定要進行總體的測試，這個也很重要，他會影響到最終的上線。在團隊內部測試完成後，沒有其餘變化後，能夠考慮上線測試，也就是發佈一個測試版，公開到用戶那裏小範圍的使用和測試，此時，主要須要作的是採集用戶意見、收集實際運行中的問題、系統BUG（BUG基本不能消除，可是，一些可有可無的小問題能夠沒必要太計較），而後在根據收集的信息進行分析，根據輕重緩急在此安排版本修訂，在基本知足需求和基本沒問題的狀況下就能夠發版了。後續須要注意的就是升級，任何產品、系統都須要不斷的升級來不斷的完善和優化。

 

若是可能得話，在系統設計中最好可以融合進好的日誌系統，在日誌系統中要有分析模塊，這個主意是用來收集系統在運行中的問題和平常使用中的一些正常或異常信息，主意是異常信息，經過分析模塊來判斷問題的嚴重性、出現頻率等，來幫助對系統的使用狀況分析和往後的修復、升級、優化等的工做安排。