关于软件开发的几点个人体会

首先看一下这幅漫画：

我就不在这里显示了，就是网上盛行的那幅，一棵树，一个秋千，尤其是销售顾问描述的发光的沙发，很有才。图片免。

明确——明确要干什么？要建设某某综合管理系统，是因为有此需求，明确用此系统完成何种任务，所以在开发上经常讲：解决方案-解决某个问题的方案，所以要明确问题是根本所在。“以其昏昏，使人昭昭”是坚决要不得的。（1）最终用户要明确自己要什么？（2）需求分析师要明确用户要的是什么？如果最终用户不知道或者描述不清楚自己要什么，需求分析师有责任和最终用户确定一个明确的需求。（3）程序员要明确自己将要开发什么东西。（4）测试人员要明确自己要测试的产品是一个什么样的才符合标准，有标准可以依据。根据个人喜好来变更需求是要不得的。（5）部署培训人员要明确客户是否得到了他想要的东西。可以作为一个反馈的环节。

计划——说白了就是某某系统何时开工竣工, 什么时间干什么活。软件企业做开发：(1)缩短开发周期最明显的就是能降低成本。（2）开发周期的确定很大程度上是由客户定的，客户准备什么时间使用该系统，项目承建企业就要在预定日前完成，并有合同制约。（3）按时保质的完成项目需要“明确”这个条件作为基础，如果客户给出需求，中间有需求变更，这些都要折算开发周期，严重影响开发周期的，双方需要协商解决。对于企业内部的子部门，即使没有开发周期的限制，我个人认为详细的开发计划还是必要的，从而保证开发的时效性。凡事预则立。

创新——对于软件企业所开发的系统并不一定是其所熟悉的行业，要有快速学习的能力。并且要敢于接受未曾接触过的挑战。创新不是说每天去接触新的东西，在一个新的系统中偶尔做出一个亮点的东西，对于软件企业可以作为短期的卖点。平时注重内功修为，必要时方可出奇制胜。不闭门造车，不固步自封。

交流——与客户的交流、与调研人员的交流、与开发人员的交流以及他们之间的交流。交流是一门艺术，可以从中汲取所需的知识，共同进步。另外在交流比较少的团队，最简单的例子就是对同一个术语持不同的理解，都会给开发带来很多麻烦。

几点个人想法：

第一、强调需求。强调需求分析在开发中的地位，在需求分析阶段至少应该有《用户需求说明书》作为此阶段的里程碑文档。在开发之前应该有至少一次的阶段性评审，评审人员至少应包括一名有决策性的用户和最终使用的用户、需求调研人员、项目负责人员。

第二、合理方案。为了树立在软件方面的权威，就要求我们做事情必须要严谨，要加强学习，增强业务能力和专业技能。对于用户提出的一些不合理的想法应该果断的委婉拒绝。果断的意思是必须拒绝，委婉是拒绝的技巧。对于用户描述不清楚的需求，应该帮助用户制作出可行的解决方案，并最终让用户接受。需求分析人员很多不从事开发，但是很少有不懂开发的。

第三、实用、适用。不但是按照用户需求开发，更应该让用户舒适的实用。Google suggest输入前提示功能无论是不是用户的需求，它实用也很适用。伴随着web2.0的发展Ajax的异步刷新的发展，很多富客户端的东西诞生，使B/S程序获得新的动力。但是我们在考虑开发一个系统的时候不一定非的盯着B/S程序不放。也许某个系统用C/S的程序完全能够解决问题。某项语言对某个领域都有他的特性。比如当初最早做portal的是python的zope，并非流行的java或者c#，所以从多方面权衡，一家专业的软件企业会考虑学习python。并不一定使用他们熟悉的语言。我们团队都实用.NET平台，在具体的业务需求下我们可以从成本考虑选择一个较合适的平台开发。

第四、第一印象，和实用、适用类似。第一印象是在初次使用的时候给客户留下的感觉。软件产品选用精美的包装，使用CD或者移动存储设备存储，这是对开发企业的包装。程序界面才是对程序的包装，然后是用户体验，然后才是真正的程序代码，代码的优劣是数据达到一定程度的时候才能显现的。举个例子来说：很多网站的留言本下面是编辑区，输入提交之后，是把新发布的放在最后呢？还是放在最上面。如果有分页如何处理？但是用户第一眼看到的是你的界面是不是漂亮，第二是不是把我发布的信息让我迅速的看到，第三才是程序是否稳定、健壮。

第五、模糊分工。我们不得不承认我们是小开发团队，不可能分工非常明确具体，所以希望每个人都以一当十。即使比较大的企业也是类似情况，为了提高工作效率，很多软件企业都分成开发小组，每个小组也是几个人，所以说我们可以算是一个开发小组。程序员不了解色彩没关系，至少要了解div+css，至少能够学着处理简单的图片。美工不了解程序没问题，至少应该知道html标签。测试人员不单单是黑盒测试，至少了解要白盒测试。需求分析不是转告用户的需求，而是提炼用户的需求。

希望开发过程中能够有：①项目启动报告：项目开发之初对整个项目做出总体的规划，时间，人员，开发环境，部署环境，设置项目进展的几个关键性里程碑。使用工具：Microsoft project 2003或word模板文档②用户需求说明书：需求分析师前期调研的产品，由阶段性评审确定。内容应概括描述系统包含的模块以及模块间关系以及相应接口。使用工具：word

用户详细规格说明书：需求分析阶段的最终产品。有阶段性评审确定。内容包括系统的模块，模块间关系，接口，每个功能的前置后置条件。使用工具：word、viso，或其他建模工具

③数据库设计：根据用户详细规格说明书设计数据库。使用工具：Power Design或其他

④软件代码产品：根据数据库设计的数据库和用户详细规格说明书开发程序。工具：待定

⑤测试阶段：根据用户详细规格说明书测试，不单纯白盒测试还应注意黑盒测试。工具：待定⑥涉及的发布形式，是否加密发布（光盘、包装、培训手册等）项目验收标准。

综上所述，我个人认为一、应该注重需求，允许需求变更，但要控制变更。需求分析不能完全听客户的，客户的未必是对的。二、产品要实用，但是不可否定在这个有特色的国度，漂亮的界面还是需要的。注重一些比较花哨的卖点，做产品还要跟紧跟主流概念，形成卖点，这是营销的范畴了。三、让所有参与项目的人看到模型，需求调研阶段给出可以提高其工作效率的解决方案，有模型，甚至有草图。四、规范开发代码，多个程序员在都理解业务的前提下应该书写大体相同的代码。五、开发过程最好也是分期分模块开发，软件开发一般是一个漫长的过程，用户希望在短期内见到东西。所以软件要总体设计，分期开发。同时可以将问题分期解决，不至于到上线后要大规模修改。六、产品部署维护的界定。那些是我们该做的，那些是我们友情客串的，那些需要付款解决的。以上几点不单纯是从技术角度考虑，因为项目的开发一般都有合同，前期的方案、需求书、甚至草图以及验收报告都是合同的一部分。

以上仅是我的个人工作经历的内容和想法，有精华，有糟粕，请领导指正。