軟體開發流程思考及建議

標籤：

• 一般Team Dev需要以下幾個組成部分：
  • 開發負責人：要求懂技術和開發管理，較強的溝通能力，負責系統的架構、編碼品質和開發進度的控制、難題攻克等任務、團隊建設和管理；（建議1人）
  • 開發人員：可以由經驗豐富的進階開發和經驗一般的普通開發組成；（建議2-3人，大型項目根據情況適當增加）
  • 測試人員：一般大型系統需要一個測試組，需要有專業的、經驗豐富的測試組長負責（一般小型Team Dev由於各種原因不去配備專有的測試人員，但軟體的測試工作不能省去，所有，很多時候就由開發人員自行測試）；（建議1-2人，複雜項目可能需要5人以上）
  • 介面設計或美工：一般有條件的還是需要一個介面UI的設計的專業人員負責介面布局、功能設計之類的工作。（建議1-2人）

 

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

 

• 一般的開發分為以下幾個步驟：
  • 需求確認

一般該步驟需要Team Dev負責人（有時也會整個團隊參與）與需求提供方開會（或其他形式）溝通，來瞭解需求；然後，根據客戶需求進行需求分析，可以出一份分析報告，比如直接出需求分析報告或需求設計文檔；最後，根據分析結果或需求設計進行進一步的溝通來確定需求。

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

• • 系統設計

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

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

服務體現在在開發的時候可以直接參考詳細設計就很快明白如何?，而不再需要重新考慮應該怎麼實現，以此來提高開發效率。

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

• • 系統開發

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

• • 系統測試

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

• • 系統交付

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

最終完成後後續還需要不斷升級，進行修複和增加新的功能。

 

• 一般的開發流程

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

現在一般不會採用這種單純的開發方式。我認為可以考慮分步分階段的方式進行。因為在實際開發過程中經常會遇上需求變更的問題，甚至有時會推翻前面的重新再來；或者最初設計的問題導致開發難以進行下去；人員流動帶來的種種問題等等。所以，我覺得按照以下的方式進行開發會有很大好處：

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

（這個步驟肯能會貫穿到系統開發的中前期，一般很少有到後期還做大量的調整和修改的，如果有小的調整也需要在確定需求後再去做後面的步驟）

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

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

第三步，在開發進行一定的時間後，經常會出現新的需求或者需求的變更，所以，我們需要再次的瞭解需求和確認，以便能夠及時更正系統設計時的不足或者開發產生的偏差，如果最後或者後期才去做這些，到時候系統的架構就已經無法修正，即便只是一個小模組很可能都很難修改了。所以，這個過程很重要，而且，需要在整個開發階段中不斷的重複執行，不斷的修正系統的設計和開發。——需要注意的是，這裡所說的修正系統設計並不是說系統的整體架構或者核心的結構可以隨便修改，這些一般在定下來之後除非非常嚴重的問題，導致無法進行後續開發是不能調整和修改的，尤其是在中後階段更不能調整核心設計。沒有任何設計開始就說完全合理的，所有，允許一定的調整，但一般會在後面需要調整的會越來越少，最後能夠達到局部的、小範圍的修改代碼就比較理想了。

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

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

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

最後，在開發過程中多次重複第三、四步的工作後基本就能保證系統的順利完成了，在系統的開發後期和完成階段一定要進行整體的測試，這個也很重要，他會影響到最終的上線。在團隊自我裝載完成後，沒有其他變化後，可以考慮上線測試，也就是發布一個測試版，公開到使用者那裡小範圍的使用和測試，此時，主要需要做的是採集使用者意見、收集實際運行中的問題、系統BUG（BUG基本不能消除，但是，一些無關緊要的小問題可以不必太計較），然後在根據收集的資訊進行分析，根據輕重緩急在此安排版本修訂，在基本滿足需求和基本沒問題的情況下就可以發版了。後續需要注意的就是升級，任何產品、系統都需要不斷的升級來不斷的完善和最佳化。

 

如果可能得話，在系統設計中最好能夠融合進好的日誌系統，在日誌系統中要有分析模組，這個主意是用來收集系統在運行中的問題和日常使用中的一些正常或異常資訊，主意是異常資訊，通過分析模組來判斷問題的嚴重性、出現頻率等，來協助對系統的使用情況分析和日後的修複、升級、最佳化等的工作安排。

軟體開發流程思考及建議