一个软件项目研发的设计流程是怎样的呢？以通常标准的设计方法为例。
一、市场调研
技术和市场要结合才能体现最大价值

二、需求分析
这个阶段需要出三样东西，用户视图，数据词典和用户操作手册。
用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了很多操作方面的流程和条件。数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。用户操作手册是指明了操作流程的说明书。

注意，用户操作流程和用户视图是由需求决定的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。
需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方（客户或公司市场部门）能够有真正的沟通和了解。

三、概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求
作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新领域，技术主管人员一上来无法给出明确的详细设计说明书，但是并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和经验教训的总结，还要重新进行详细设计的步骤。

四、详细设计
这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最‘干净’的方式(黑箱结构）提供给编码者，使得系统整体模块化达到最大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软件系统在完成了一半的时候，其实还没有开始一行代码工作。那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。

五、编码
在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？从来没有！

六、测试
测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。
总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。

完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，知道这个软件被彻底淘汰为止。

写这些步骤算不上卖弄什么，因为实话讲我手边是一本《软件工程》，在大学里这是计算机专业的必修课程，但是我知道很多程序员似乎从来都只是热衷于什么《30天精通VC》之类的，他们有些和我一样游击队出身，没有正规学过这个专业，还有一些则早就在混够学分后就把这些真正有用的东西还给了老师。

fans乱嚷嚷，混淆视听，实际上真正的技术专家很少在网上乱发帖子的，如笔者这样不知天高地厚的，其实实在是算不上什么高手，只不过看不惯这种对技术，对程序员的误解和胡说，只好挺身而出，做拨乱反正之言，也希望那些还fans们能认真想想，走到正途上，毕竟那些聪明的头脑还远远没有发挥应有的价值。沉迷于一些错误人士的coding

从程序员升级到工程师大多数象我这样对软件有浓厚兴趣的人，毕业后义无反顾地走进了企业，开始了程序员的生涯。那时，我们迷恋“大全”、“秘籍”一类的书籍，心中只有代码。当我看到一行行枯燥的代码变成了能够打电话的设备，变成了屏幕上漂亮的表格，变成了动听的音乐，成就感油然而生。我觉得自己也是一个出色的程序员了。在用户的机房中苦熬三昼夜解决软件的bug，也成了一种可以夸耀的资历。五年前的某一天，我把曾经让我兴奋自豪的大量代码和少得可怜的文档移交之后，来到了华为。这里有更多的年轻人，我如鱼得水，可以充分发挥自己的想象力。依然是代码，依然是匆匆地在纸上记下稍纵即逝的灵感（我们把它称作文档），依然是无休止地和bug作斗争。当有一天，一个新来的同事拿着署着我的大名的文档，小心翼翼地来问我时，我发现自己好象有点不认识它了。我心里有点沮丧，再看看代码，发现文档上记录的一些灵感已面目全非。我当时不知道那位新来的同事感受如何，但我从那时起，好象意识到什么。现在来看，那时的很多事情都是事倍功半。

去年年底，公司派我到印度从事项目开发，学习印度的软件开发管理方法。一种久违的冲动在心底升起。印度，我已去过两次，虽说是走马观花，但是，印象还是比较深刻。我在访问过程中和印度的工程师交流过，他们言谈中透着自信。他们给我讲解正在做的软件的测试环境，给我看他们写的单元测试文档。当我看到一个软件模块的单元测试用例有三百多页时，我觉得心里很是沉重。当我第三次踏上这片土地时，我又见到了熟悉的人们，明亮的眼睛，温和的笑容，随意的穿着，风驰电掣的摩托，还有大学校园中穿着拖鞋，手抱书本的年轻人。我也见到了我的项目经理，一个个子较高，瘦瘦的年轻人，据说刚从美国回来，已工作了五、六年。我听了心里很高兴，这回要一招一式地学两手。需求分析的时间是一个月，项目经理和我们（实际上代表客户）讨论了proposal中的内容，确定每一项都是需要的。然后他把模块大致划分了一下，开始进入计划中的学习阶段。每个人在学习阶段要写出功能描述的胶片，给其他人讲解，不知不觉中，项目组的所有人对项目有了整体的了解。
他还安排了一些培训，如他们公司的软件开发模型、项目组中各角色的定义，以后及时的培训不断，只要项目组中有需求，他总是把qa或相关的人请来，培训很专业。需求分析完成后提交了一份四十多页的文档，当我看到这份英文文档中我写的部分整整齐齐地列在其中时，我的感觉很复杂，有些喜悦，但更多的是苦涩，我以前怎么就从来没有这样做过需求分析呢。

在我写文档的过程中，qa给我们培训过srs的写作模板，后来我还是不放心，让他们一个有经验的工程师写了一段，我们再琢磨着照着写。这份srs虽然是多个人合写，但风格一致，内容详实。更为可贵的是，一直到最后，这份需求分析的内容都没有改过，以至于我们没有机会走一下他们的需求更改流程。

需求分析是项目的第一阶段，第二阶段的开发时间要根据需求分析的结果来确定。当对方的首席技术官（相当于我们业务部的总体组长）来和我们讨论计划时，他们已列出了对每个模块的代码行数的预测，可能存在的风险。根据他们公司的生产率－－300行/人月，他得出了项目第二阶段需要多少周。
我们当时就提出了异议：1）公司对该项目需求很急；2）每月300行是否太少；3）我们还有下载的源代码参考。他解释说，300行/人月是使得项目能达到他们质量标准的经验数据，考虑到有源代码参考，生产率最多不能超过350行/人月。当他问我们公司的生产率时，我脑袋里转了三个圈，没敢多说，大概六、七百行吧。他沉默了一会儿，然后坚定地说，我们这个计划是建立在确保质量的基础上的，我想你们到印度来开发软件，首先看中的应该是我们印度公司的质量保证。我知道你们不缺乏软件开发人员，你们为什么不选择下载的软件呢。几句话说到了我的痛处，现在国内的弟兄们还在为使用下载软件移植的产品四处奔波呢！

随后的开发活动有条不紊，我们老老实实地跟着做。系统测试计划、用例，概要设计，集成测试计划、用例，详细设计，单元测试计划、用例，编码，单元测试，集成测试，系统测试。一个完整的v模型开发过程，其中每个过程都有review。当我们对一些设计的方法不太明白时，项目经理给我们发来了相关的资料，我不知道他当时是怎么想的，一些基本的分析、设计方法是十年，甚至二十年前的软件工程书中就讲到的，印度每个计算机专业的人员都是必修这些内容的。而我们除了对一些具体协议的代码很熟之外，对这些常用的方法似乎一无所知。我感到一些羞愧，进城直奔书店，把他给我开列的书找了出来，晚上躺在床上，仔细研读，我仿佛突然又遇到了能给我指点迷津的良师益友。现在印度所已形成了强烈的学习风气。我回来后也推销了700多本书，这些书教我们如何用工程化的方法开发软件，是成为一个软件工程师必读的资料。

我们的项目经理的计划控制能力很强，当有什么影响到项目计划的事情发生时，如人员辞职、实验室搬家、某一模块预测不准（该模块是我们预测的），他总是采取必要的措施，减少延期，调整计划。刚开始，我们对他们每天上午11点，下午4点下楼喝咖啡还有点意见，后来也跟着喝去了，原来，喝咖啡时的交流非常丰富，从项目管理到设计方法，从技术发展到风土人情，无所不包，对我们互相之间的理解，对团队的气氛很有帮助。我们项目的qa也在适当的时候出现在我们的面前，我们对她的工作只有一些感性认识。她每次参加会议时，手里时常拿着一个checklist，项目经理准备相应的资料，回答一些问题，她打着勾，或写着项目经理的解释。她给我们做培训时也很耐心，体现出很好的职业素养，我至今还在怀念她给我们的帮助。

我从事软件开发已有九个年头了，可我现在仍然不能说自己是个合格的软件工程师，更不用谈什么合格的管理者。我看到一份报道说，瑞士洛桑一权威机构把中国的科技综合竞争力从原来的第十三位调到二十多位，原因是他们调整了一些评估标准，其中有一条是中国合格工程师的可获得性非常低。想着弟兄们熬红的双眼，四处奔波升级的疲惫身影，我有一个强烈的愿望：快把我们自己升级成合格的工程师吧!