做一个正规的软件产品从来都不是一件简单的事情，除了产品本身涉及的技术因素之外，还有更多的非技术因素。本文仅描述一个小公司的团队在一个软件产品从想法到实现过程中涉及的工具和这些工具提供的功能与作用。由于我们经验有限，描述内容会有纰漏，请多多指正。不过，我们倒是体会到开发一个可用的产品有多困难了。反正呢，说或者说别人都要比自己亲自实践和实现来得容易的多得多了。因此，我也越来越觉得应该学会如何去尊重别人看似傻瓜的东西。就像有人在批评这个产品、那个产品，如果这个产品是你自己做的，你就不一定会那么说了。当然，也希望能够分享你们的任何想法和建议了。
首先，我们来看一下，用户在使用我们产品涉及的大概的交互内容（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 结束语
一个产品所涉及的细节实在是太多太多了，足够写出一大堆的书籍了。这里仅仅是描述了其中的冰山一角。产品体现价值的方式更重要的是如何获得市场的认可。而这就涉及更多的非技术性的问题了。有高层战略，也有底层策略。公认的，与人打交道是最困难的。一旦你需要负责市场扩展时，需要商业眼光、商业技巧、交际技巧、读人技巧……，实在是太多了！没有一个分工细致的团队很难能够做到成功！本文所描述的也一定有不少错误，希望多多指教和得到意见，也请分享你们的想法，当然，拍砖的同志稍微轻点。
PS：顺便提一下，目前我们在招人，地点是西安，有兴趣的可以查看“.NET软件开发工程师”招聘信息，或者直接发简历到uishell@uishell.com。 我们知道做程序不容易，因此，会尽量让每一个人开心点，体谅每一个人，尽可能保障每个人的权益。
本文转自道法自然博客园博客，原文链接：http://www.cnblogs.com/baihmpgy/archive/2010/08/18/1801963.html，如需转载请自行联系原作者