关于软件开发的建议
一、问题的提出
开发周期长、劳动强度大、后期维护工作多等问题是目前在应用软件开发中普通存在的问题：一个中等规模的应用系统通常需要若干个人年；大多数系统开发到一定阶段，开发人员都需要加班加点，有时还会因为种种原因需要返工；交付用户使用后，还需有很长的一段时间按照用户的要求进行调整或修改。这些问题严重地制约了专业软件开发单位的市场竞争能力和发展，致使不少公司不得不依靠硬件销售、软件代理等其他途径来维持生计。
那么专业软件开发单位应如何摆脱这种难堪的局面呢?
几乎所有的软件开发人员都知道：遵循软件开发的规律，严格按照有关软件工程的国家规范进行开发，改变手工作坊式的生产，形成流水作业，才能改变这种难堪的局面。然而在实际工作中却没有这么简单，虽然开发人员做出了相当大的努力，但由于这样或那样的原因，需求分析、概要设计相互脱节，其工程最后的功能、质量、进度、投资决策等都未能达到原先总体设计预想的要求，甚至其运行的软件与概要设计文件的叙述相差甚远，前期设计文件变成一堆废纸，导致工程返工，造成巨大的人力和财力的浪费。究其原因，可以列举出许多，比较典型的有：用户单位配合不力、需求反复变更、工作量估计不足、进度失控、人力不够等等。仔细分析起来，根本原因就是开发单位缺少一套具体措施办法，缺少规范化工艺过程，无
法对整个开发过程实施有效的控制，因而也就不能保证软件开发能够自始至终顺利进行。所以根据本单位的具体情况，制定出一套具体措施办法，形成一套质量保证体系；以保证软开发能够按照国家规范进行则成为软件工程的组织者或领导者的重要任务。
二、发扬团队精神密切合作
开发软件首先要有相应的开发队伍。这个队伍由不同的技术阶层人员组成，从软件开发单位来说，应配有系统分析员、高级程序员和程序员。
系统分析员负责需求分析、概要设计和测试。系统分析员除了应具有较强的组织能力和系统分析能力外，我们认为同时还应对当前计算机的发展比较了解，熟知各种硬件、各种数据库平台和开发工具等的主要性能和价格；同时他们最好具有丰富的独立完成应用程序全过程的实践经验。高级程序员负责概要设计、详细设计和分部测试。高级程序员应当有过较长时间的编程经历(3年～5年)，对用户一般的操作习惯、界面需求比较了解，能够熟练运用系统所选定的开发工具。程序员负责具体的编程工作及调试。
根据经验：以上三种人员的比例应为1∶2∶5为好。队伍成员应相对稳定，各个成员之间具有良好的团队协作精神。队伍中如果有些成员只关心自己的技术进步，而对项目本身却漠不关心，那么这个队伍的人员就应当调整。
三、需求分析要细致周到
需求分析工作是整个系统设计中最关键的一环。有些系统在投入运行后，发现与实际要求差距较大，甚至没有使用价值，这就是因为需求分析工作没有做好。有些开发者在进行需
求调查时要求用户提供应用模型和原始数据，用户往往不知道应该提供什么，也不知道深度如何，所以经常会出现，用户所提供的需求并没有真正完全反映应用以上的要求。为了克服这种现象，高质量的完成需求分析工作，通过长期实践我们总结出一套行之有效的规范性需求调查过程。
开发者与用户见面，用户介绍其单位管理流程；
开发者分头去用户单位各部门进行需求调查，最好一人只负责3个部门左右。调查时主要做这样两方面的工作：一是发放、解释数据调查表，让用户部门主要管理人员填写，然后回收数据调查表。二是收集各种统计汇总报表。
由系统分析员汇总数据调查表，剔除那些物理意义重复的数据，特别注意：有些数据在不同的部门有不同的提法而物理意义却是相同的，这类数据也要注意剔除掉。汇总收集上来的统计汇总报表，检查报表上所需要的数据是否在数据调查表中有遗漏；并按照这些数据的物理含义和使用部门，对这些需求数据进行分类。
根据用户介绍的管理流程和需求数据，按各部门的管理范围画出粗略的数据流程图和功能要求清单，征求各部门的意见。
根据需求工作的结果及收集上来的反馈意见，制作一个DEMO演示程序；该程序只是大概反映出功能调用、界面等，请用户审看，提出意见(这里主要是对功能)。
根据用户意见进行修改并形成交付用户审阅的需求分析文件，为了便于用户审阅取以下结构方式描述：
具体功能描述——涉及的数据说明用户核准签字后，需求调查工作结束。开发单位的技术总负责人应组织力量进行检查，以确保需求调查工作的质量。
来自何部门发往何处产生报表说明：数据编码—某一数据的符号名；数据含义—具体数据内容说明；类型及长度—数据的类型按通常习惯分为“文字”(字符)，“数字”，“日期”，“图像”；精度要求—小数点后保留位数；推导关系—该数据如果是通过其他数据计算出来的，则说明其计算公式；自何部门—数据如果是其他部门提供的，要说明那个部门的名称；发往何处—数据如果其他部门需要使用，要说明那个部门的名称；产生报表—该数据如果是某个报表中的内容，则要说明报表的名称。
四、系统功能确定力求准确概要
设计确定系统功能时，要注意系统是否满足应用需求；在这个问题上，许多设计者往往只注意是否满足用户提出的要求，而忽视了其他伴随出现的要求。这些容易被忽视的要求通常是为了保证整个系统能够正常运行的辅助功能，用户一般不会意识到，这类要求我们称为“系统需求”。另一方面，还应当对用户
一些自己说不清楚的，同时技术上非常复杂的功能要求要特别慎重。概要设计文件完成后，开发单位的技术总负责人应严格审查其中的功能及如何实现这些功能的描述。如果出现不清楚的描述或根本不可能实现的功能则属于设计质量不合格。
五、开发工具或数据库平台的选择
选择系统的开发工具或数据库平台时应考虑以下问题。
否能够完成系统的功能要求——要特别注意是否安全、一定单位时间内的交易数据等是否能够满足系统的功能要求；
用户是否还需要增加大量的投资：
社会上使用此类开发工具的人员是否比较多——使用的人多必然交流方便，市场上有关
的资料相应的就会比较多，这些有利因素都会给开发工作带来很大的便利，这一点往往容易被忽视；
开发、维护是否方便——如果开发维护很困难，则不宜选择。在目前普遍使用Windows 环境的情况下，应主要考虑可视性的编程工具，如VC、VB、FoxPro、PowerBuilder等；
vb软件开发前景如何——当由于某些原因不得不考虑选择开发者不太熟悉的开发工具时，就应当考虑该工具的前景如何，如果不属于今后的发展方向，社会上使用此类开发工具的人员也比较少，那么应当与用户协商更换开发工具。
六、详细设计规范化
详细设计的主要对象应该是具体的程序编制人员，是编程人员编写程序的指导性文件。根据某一功能模块的详细设计说明，编程人员就能十分清楚自己应该做什么，应该怎么编写这个模块；而且不必知道其他模块或上一层模块是如何设计的，有些人形容好的详细设计文件是：“编程序的不用动脑子”；如果编程人员在仔细阅读了某一功能模块的详细设计说明文件后，依然不知道这个模块应该如何设计，需要原详细设计的设计人不断解释，这就表明该详细设计的深度不够。显然，详细设计深度不够将难以形成流水作业。详细设计的深度应当列为详细设计质量重要检查项目。
开发人员应严格按照国家规范《计算机软件产品开发文件编制指》(GB8567\88)上规定的深度编写(即包括了功能、性能、输入项、输出项、算法、流程逻辑等的说明)详细设计文件。按照国家规范编写详细设计文件必须将整个系统所有的功能模块整理一遍，同时要整理出全局量、局部量、公共函数等，其工作量可想而知。根据我们以往的实践，详细设计的工作量几乎占编程前所有工作量的65%以上。所以有些开发单位由于软件力量不够，在时间进度的压力下，往往跳过详细设计这一步，而直接进入编程阶段，
试图加快开发进度，结果适得其反，非但不能加快开发进度，反而带来很严重的后果。没有规范的详细设计文件则很难约束、协商编程人员之间的工作。即使在某些小型的系统中编程人员就是概要设计人员，也很难约束他的“随心所欲”，难于统一界面风格，数据交换混乱，程序源码冗余。当编程工作时间吃紧时，由于没有规范的详细设计文件，别人又没有介入前期准备工作，所以很难再添加新的力量，造成计划调度的混乱。
本文特别强调指出：在当前普遍采用面向对象的设计方法时，详细设计文件应当说明应用的各个对象如“窗口”、“控件”、“按扭”等对象属性、触发事件和事件过程等内容。
七、技术储备工作有待加强
对于非单一产品的软件开发单位来说，由于用户、任务类型经常变更，开发人员总是在开发新的项目，而不是在更新原有产品，所以开发人员在开发新项目时能够利用的只是自己过去的经验而不是技术成果，尽管他们的经验丰富，可依然不能从根本上加快开发速度、减轻劳动强度。加强技术储备工作是改变这种情况的有效办法。
所谓技术储备是指将一些常用的处理形成标准“类库”，每开发一个新项目时，如遇某一处理与“类库”中的某一对象类似，则直接继承该对象；如果“类库”内容越丰富、涉及的内容越广泛，可以被继承的东西就越多，项目开发的工作量就越少，而且由于标准“类库”里内容是经过反复考核的，所以项目的正确性也
大大提高。每项工程结束后，开发单位应当组织原开发人员认真地进行技术总结，将一些出现次数比较多的操作进行软件动作抽象化，然后按照抽象后的需求进行对象或函数设计，并将设计放入“类库”中。例如在许多数据库应用系统中都有对某个数据关系表中的数据进行维护的要求，有些还要求在数据维护过程中能够搜
索、排序显示等功能。对这一要求，就可以设计成“类库”中的一个对象，它包含窗口记录移动、删除、恢复删除、删除列表、添加、修改、条件搜索、条件过滤、条件排序等；凡在应用系统中有此类似要求的，只要继承这个对象，给出访问的数据表名，访问条件即可，这样就大大节省了设计时间。
技术储备是开发单位内部建设一项必须重视的工作，这方面的工作做的越好，“类库”就会越丰富，利用的程度也就越高，以后的设计也就越来越简便，当然也就大大提高了单位的市场竞争能力，所以单位技术主管应当重视此项工作。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。