做一個正規的軟體産品從來都不是一件簡單的事情，除了産品本身涉及的技術因素之外，還有更多的非技術因素。本文僅描述一個小公司的團隊在一個軟體産品從想法到實作過程中涉及的工具和這些工具提供的功能與作用。由于我們經驗有限，描述内容會有纰漏，請多多指正。不過，我們倒是體會到開發一個可用的産品有多困難了。反正呢，說或者說别人都要比自己親自實踐和實作來得容易的多得多了。是以，我也越來越覺得應該學會如何去尊重别人看似傻瓜的東西。就像有人在批評這個産品、那個産品，如果這個産品是你自己做的，你就不一定會那麼說了。當然，也希望能夠分享你們的任何想法和建議了。
首先，我們來看一下，使用者在使用我們産品涉及的大概的互動内容（A～D的圖檔可以快速浏覽過去）。
A 安裝包界面
安裝包功能選擇：支援VS2005/2008/2010 & 安裝成功
B 安裝後界面
安裝後檔案夾
C 使用
開發時可以使用模闆快速建立一個宿主或者插件 & Manifest編輯器
遠端控制工具，開發、調試和部署用
D 幫助和使用者向導
API說明書 & 使用向導
在對上面一個産品有了一個大概的印象之後，我們便來看一下這個産品在設計和實作過程中涉及的一些東西。
1 想法
一個有意義的産品絕對是為了解決某些問題而誕生的，否則就沒有任何價值。而價值的衡量是相對于其要解決的問題來評判的。如果一個軟體産品并不是用來解決問題，基本就沒有存在的意義。是以，有價值的想法，一般出自于你碰到的各種問題，如果你的一個想法能夠解決很多人的問題，那麼這個産品具有很高的價值了。
當然，要提出一個好的想法并不那麼容易。并不是有了高價值的想法就可以去實踐。事實上，有價值的想法僅僅是初步而已，因為這個想法還必須具有可行性。每一個有價值的想法也或多或少有其它的問題伴随而來。當綜合考慮各個問題之後，我們或許才能夠下一個比較理智的決定。不過，這個決定并不是那麼容易的，我至今一直都在摸索中。
2 概念設計
當有了一個軟體産品的想法後，我們便開始琢磨該如何來實作這個産品。一開始，我們對産品并沒有太清晰的認識，比如産品要提供什麼功能來解決使用者的問題、這個功能如何來使用等等。這個時候意識比較模糊。
在概念設計階段，我一般使用“白闆 + 白闆筆 + 帶有相機功能的Touch HD”工具組合進行。使用白闆筆在白闆上做一些頭腦風暴的快速設計，然後通過Touch HD照相，并且儲存下來。儲存下來以後可以列印然後貼在白闆上做一些細化，直到頭腦已經有了軟體産品模拟運作的初步印象為止。
概念設計圖例
3 功能規範
概念設計僅是一些初步的圖檔，思維跨度會大一些。是以，需要有一個比較規範且易于了解的功能描述，即功能規範文檔。這個文檔是對概念設計的進一步細化。我們可以根據實際情況來設計。一般而言，功能文檔會描述出系統的重要用例。不得不提到一點，設計一個複雜系統的時候，最好的方法是從High Level的方式來俯視整個應用系統，然後根據設計的機器、元件、人物、運作環境等比較大的因素來劃分成不同的小系統，進而擷取更多的細節。
功能規範圖例
4 使用者使用場景說明書
此外，如果是SDK之類的産品，最好還需要設計一下每一個公開的API涉及的使用者使用場景。使用者使用場景是對産品釋出後使用者使用的模拟，進而可以優化API的設計。API設計的目标是確定50%～70%的功能能夠讓使用者非常簡單的應用，讓剩下的功能可以是進階功能。
使用者使用場景說明圖例
5 進度安排
該概要設計和功能規範設計的同時，我也會着手開始安排整個項目的進度。目前是直接采用Project。進度安排也是由上到下的方式開始，從大的開始，再細分任務，并根據每一個的能力初步估計一下大概時間。然後由不同的人進行審計，由他們再次更新進度。需要知道的是，進度不可能是準确的，一般而言，我們需要在整體估計的時間上上浮二十個點，甚至更高。
進度安排圖例
6 設計規範
設計是産品實作過程的一個重要環節，從Agile角度考慮，為了節省人力和時間，我們隻是對一些重要的算法、重要的功能、重要的類進行比較詳細的設計。當然了，我也相信簡單的功能我們團隊的這些人一定能夠勝任。留下設計規範文檔的好處是維護、測試，以及教育訓練會來的容易的多。在我們産品開發中，我一般會把系統設計的接口類定義好、把重要的算法描述好，然後交由其它人開發實作。是以，我強烈推薦VS自帶的類圖工具。
設計規範圖例
7 實作
到這一步，我想實作應該比較簡單了。隻是要讓團隊形成一個統一的開發規範。我們使用了Framework Design Guideline中的設計與開發原則進行規範化的開發。
FDS PPT，強烈推薦
8 品質保證體系
在産品建構之初，我們考慮了品質保證。在上班的時候，那會公司使用的是ClearCase、CruiseControl、Ant、Junit和一個Bug管理工具。我們肯定買不起也用不是ClearCase這樣重量級的配置管理工具了。是以，我當時的選擇是：Subversion（VisualSVN Server）/TotoiseSVN/AnkhSVN + CruiseControl.NET/NAnt/MSBuild + BugTracker.NET + xUnit + Wix。
選擇Subversion的原因，在于：（1）免費；（2）提供了Branch/Tag功能。第二個因素是最重要因素，一個産品肯定避免不了持續更新和不同版本的釋出。是以我們通過Branch/Tag來支援這種産品線工程。我們産品線管理的方式是，有一個trunk，它具備最全的功能，持續不斷的進行更新，除非是Merge階段。一旦trunk到達快穩定狀态且已經達到産品釋出的目标，我們會為其建立若幹個Branch和Tag，trunk還可以繼續BugFixing和New feature更新，但是Branch的代碼就必須非常小心對待了，我們不可以添加新功能、不可以不經過代碼審計、代碼更新需要發送通知，這都是確定釋出的産品達到最穩定的必要保證。當然，關于産品線的管理有很多方法，我這個方法不一定是合理的，隻是我現在還覺得這樣做可行。
CruiseControl.NET/NAnt/MSBuild一方面用于在代碼更新後自動Build，一方面也可以進行DailyBuild出一個安裝包。安裝包采用Wix來開發，通過與Nant內建，每一次安裝包建構都會自動從代碼庫擷取代碼、編譯、混淆，最後生成。CC.NET功能很強大，代碼更新後，如果Build失敗，會發送郵件通知，同樣的它還可以自動執行xUnit單元測試，如果測試失敗，也會郵件通知。這樣可以盡可能避免一些代碼錯誤和避免Regression。Regression——回退，這是一種非常嚴重的Bug，一般而言，我們會把它定義為最進階别。由于UIOSP是一個中間件産品，對其代碼修改可能會對其它産品、或者自身産生影響，是以，自動測試也是必須的。
QAS涉及的一些批處理檔案：啟動/停止/建構安裝包等 & VisualSVNServer代碼管理
內建了NAnt/MSBuild/xUnit的CC.NET & Subversion內建了的BugTracker.NET
BugTracker.NET的擴充：代碼審計
9 第三方元件
一般而言，在開發軟體産品，如果有一些功能别人已經實作了，我們都會選擇重用。這就涉及第三方庫。在使用第三方元件的時候，一般會被忽略的就是它的License聲明。目前有幾種常見License，比如Apach、GPL、MS-PL等。在中國，或許這些東西你可以忽略并随便使用，但是我建議開發軟體産品的人還是稍微留意一下，盡量避免一些問題。
10 幫助文檔
如果一個軟體産品能夠不依賴于幫助文檔而使使用者可以直接使用，那這個産品的使用者體驗一般都非常的友好，或者已經有很多使用者認可産品的互動模式。大多數情況，我們都需要提供幫助文檔，特别是SDK。開發人員一般都懶，能不看文檔最好，是以，文檔編寫需要别出心裁。當然，想要别緻是需要代價的，隻能看情況一步一步改善了。我們在産品的文檔上給使用者提供了一個使用者指南和API文檔。使用者指南編寫上，首先會用一個簡單示例，3分鐘的Quick Start，然後在逐漸細化和深入。API文檔會把重要的類的使用說明描述盡可能清楚，同時每一個重要的類或者API都會附上一個Example。我們在編寫API使用說明時使用了Sandcastle和SandcastleBuilder這兩個工具。
Help工程 & API注釋
11 結束語
一個産品所涉及的細節實在是太多太多了，足夠寫出一大堆的書籍了。這裡僅僅是描述了其中的冰山一角。産品展現價值的方式更重要的是如何獲得市場的認可。而這就涉及更多的非技術性的問題了。有高層戰略，也有底層政策。公認的，與人打交道是最困難的。一旦你需要負責市場擴充時，需要商業眼光、商業技巧、交際技巧、讀人技巧……，實在是太多了！沒有一個分工細緻的團隊很難能夠做到成功！本文所描述的也一定有不少錯誤，希望多多指教和得到意見，也請分享你們的想法，當然，拍磚的同志稍微輕點。
本文轉自道法自然部落格園部落格，原文連結：http://www.cnblogs.com/baihmpgy/archive/2010/08/18/1801963.html，如需轉載請自行聯系原作者