开发手记（三）

【 tulaoshi.com - ASP.NET 】

    人们常问：“需求、设计、编程、测试四者究竟哪个重要？” 这个问题不好回答。四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏的影响。若站在风险管理的角度讲，也许需求开发与管理是最重要的环节。因为需求是产品的根源，对产品需求的认识是否彻底对产品的影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。庆幸的是我本人既是软件的开发者又是这套系统的最终用户，个人亲身在造价管理部门、投标部门、项目法人结算部门工作过，对系统的大部分需求比较了解，这也给需求分析工作减轻了负担。

    也许是对需求的理解过于自负，因此对水利设计单位的需求调查深度不够，导致了目前系统针对设计单位用户功能的提供存在一个缺陷，而且是不容易弥补的，这一点的需求与许多模块相关联，牵一发而动全军。正如Frederick Brooks在他1987年的经典文章“No Silver Bullet”中阐述需求的重要性：“开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其他软件系统的接口。此工作一旦有失误，将会给系统带来极大的损害，并且以后对他修改也极为困难。” 软件需求是系统设计之源，详细的需求分析完成后接下来的工作便要进入系统的设计阶段。软件系统设计核心内容包括：体系结构设计、用户界面设计、数据库设计、模块设计、数据结构与算法设计等几方面。根据这套软件的具体开发情况，系统设计准备了两套方案：一个是继承市场上现有水利造价软件的主流设计思路，对其不完善的部分改进并加入一些先进的设计思想。另一种方案是抛弃主流设计思路，另辟新径开发一个面目一新的产品。

    我对两种方案的优缺点进行了对比：第一种方案的优点： 1、 主流水利造价系统结构设计的可实现性具有先例，开发风险系数低。 2、 有大量的老用户习惯了以前的软件操作模式，主流的用户界面和模块画分会给老用户以熟悉感，用户不用重新学习软件的使用方法。 3、 可以吸收市场上较成熟的同类软件的数据库设计思想，缩短了开发时间。第二种方案的优点： 1、 全新模式设计，可以彻底抛弃现有同类软件在需求、设计方面的不足。 2、 给用户以全新的感觉，避免用户产生新软件是某一款老软件升级版的错觉。 3、 避免了因与某一同类软件的部分结构相似而产生的版权纠纷问题。我对两套方案进行了详细分析对比，权衡利弊决定采用第一个方案。并运用以下方式对第一套设计方案中的不足进行弥补： 1、 彻底分析市场现有同类软件的不足，从需求、设计方面入手，增强系统的功能与操作的人性化，让软件更体贴用户需要。改进计算与导出模块的数据结构算法，提高系统的整体性能。因水利造价管理的需求是随时代发展而变化的，预留软件接口，提高可扩展性。对部分模块全新设计，提高系统的兼容性。 2、 只吸收设计思想，不抄袭整个软件，尽量避免版权争议。 3、 本人在天津水利造价管理领域有一些人脉，因此软件设计主要吸收天津某单位开发的一套系统的优秀思想。即使将来产生版权争议也容易摆平，再不行还可以合作吗。根据《计算机软件保护条例》第六条的规定，除计算机的程序和文档外，著作权法不保护计算机软件开发所用的思想、概念、发现、原理、算法、处理过程和运算方法。也就时说，利用以有的上述内容开发软件，并不构成侵权。因为开发软件时所采用的思想、概念等均属计算机软件基本理论的范围，是设计开发软件不克缺少的理论依据，属于社会公有领域，不能为个人专有。所以市面上的同类型的软件结构布局、使用方法都有几分相似，这给用户的使用也提供了很大的方便。但他们之间肯定是有差异的，各有长短，一些后者吸收前人的思想并发展继承后异军突起了。因为已经完成了系统需求详细分析，对业务流程十分熟悉，而这种数据处理系统的技术含量不很高，所以对市场现有水利造价软件的体系结构、用户界面、模块划分的分析相对容易一些。软件所依赖的数据结构与算法可结合程序实现时一同考虑。在对现有软件的剖析过程中最让人头痛的是数据库结构的分析过程。需要搞清每个库的作用，每个库之间的联系；库中每个表的作用，他们之间的联系；表中的每个字段的作用，他们之间的联系；之后他们所有互相之间的联系。我耗时一个月对软件的6个库、120张表、3000多个字段进行了详细的功能及关系描述，描述文档约有10万字。算起来比全新设计库结构所要耗费的精力一点不少，这样做只是为了增加软件的成功系数。至此软件的分析工作全部完成，接下来的工作就是要真刀真枪的编码了。