软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列的设计质量的评审，以便及时发现和及时解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。
设计监理总则
软件设计监理的基本准则包括： 审查提交的文档是否齐全，审查文档编制与描述工具是否符合规范。确定承办单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，评价软件设计方案与数学模型的可行性，评价接口设计方案和运行环境的适应性，审查软件集成测试计划的合理性和完备性，审查数据库设计的完备性和一致性。并确定该阶段文档能否作为详细设计的依据，决定可否转入详细设计阶段。确认软件详细设计文档的内容符合软件编码的要求。
设计阶段中监理单位要尽可能与业主单位协调配合工作，听取业主单位从业务角度出发提出的对开发方设计的意见。监理单位主要从文档的规范性、可实施性出发，以国家相关标准为依据，从软件工程学的角度对承建单位提出意见与建议，配合业主单位工作，敦促承建单位做好工程项目的设计工作。在设计阶段，监理单位主要针对需求的覆盖性及可跟踪性、模块划分的合理性、接口的清晰性、技术适用性、技术清晰度、可维护性、约束与需求的一致性、可测试性、对软件设计的质量特性的评估、对软件设计的风险评估、对比情况、文档格式的规范性等几个方面进行评审。在此过程中，业主单位也需要对设计文档做检查，主要在功能设计是否全面准确地反映了需求、输入项是否完全与正确并符合需求、输出项是否符合需求、与外界的数据接口是否完全与正确并符合需求、各类编码表是否完全与准确并符合需求、界面设计是否符合需求、维护设计是否符合需求、各类数据表格式和内容是否符合要求、是否存在其它有疑问的设计等几个方面进行核查。
设计的评审内容
（1） 可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否复盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求。
（2） 接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。
（3） 风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
（4） 实用性：即确认该软件设计对于需求的解决方案是否实用。
（5） 技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。
（6） 可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
（7） 质量：即确认该软件设计是否表现出良好的质量特征。
（8） 各种选择方案：看是否考虑过其它方案，比较各种选择方案的标准是什么。
（9） 限制：评估对该软件的限制是否现实，是否与需求一致。
（10） 其它具体问题：对于文档、可测试性、设计过程，……，等等进行评估。
在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能、以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。
McGlanghlin给出在将需求转换为设计时判断设计好坏的三条特征：
① 设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
② 设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。
③ 设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。
以上三点就是软件设计过程的目标。为达到这些目标，必须建立衡量设计的技术标准。
① 设计出来的结构应是分层结构，从而建立软件成份之间的控制。
② 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
③ 设计应当既包含数据抽象，也包含过程抽象。
④ 设计应当建立具有具有独立功能特征的模块。
⑤ 设计应当建立能够降低模块与外部环境之间复杂连接的接口。
⑥ 设计应能根据软件需求分析获取的信息，建立可驱动可重复的方法。
软件设计过程根据基本的设计原则，使用系统化的方法和完全的的设计评审来建立良好的设计。一、概要设计的评审
软件概要设计监理的目的是对软件概要设计有关内容（重点是软件的结构、软件的功能、软件的结构、接口设计、接口关系等）、概要设计过程、概要设计活动、文档格式进行审查，确定承建单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件详细设计的前提和依据。
二、详细设计的评审
软件详细设计监理的目的是对软件详细设计有关内容（重点是软件的算法、数据结构、数据类型、异常处理、计算效率等）、详细设计过程、详细设计活动、文档格式进行审查，确定承建单位提出的软件详细设计内容是否实现了软件概要设计的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件编码的前提和依据。
四、软件编码走查的监理
程序实际上也是一种供人阅读的文章，有一个文章的风格问题。应该使程序具有良好的风格。表现在：源程序文档化，数据说明的方法，语句结构和输入／输出方法。所以在进行编码监理时重点从一下几个方面把握：
1） 源程序文档化
（1） 符号名的命名
符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等等。
名字不是越长越好，应当选择精炼的意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。
（2） 程序的注释
夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。注释决不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1／3到1／2，甚至更多。注释分为序言性注释和功能性注释。
序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其它有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。
功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。
（3） 标准的书写格式
视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少发生编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行。使程序的逻辑结构更加清晰。
2） 数据说明
在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。
（1） 数据说明的次序应当规范化
数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
（2） 说明语句中变量安排有序化
当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。
（3） 使用注释说明复杂数据结构
如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
（4） 语句结构
在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；让编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。
3） 输入和输出
输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入／输出风格还受到许多其它因素的影响。如输入／输出设备（例如终端的类型，图形设备，数字化转换设备等）、用户的熟练程度、以及通信环境等。不论是批处理的输入／输出方式，还是交互式的输入／输出方式，在设计和程序编码时都应考虑下列原则：
（1） 对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；
（2） 检查输入项的各种重要组合的合理性，必要时报告输入状态信息；
（3） 使得输入的步骤和操作尽可能简单，并保持简单的输入格式；
（4） 输入数据时，应允许使用自由格式输入；
（5） 应允许缺省值；
（6） 输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；
（7） 在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；
（8） 当程序设计语言对输入／输出格式有严格要求时，应保持输入格式与输入语句的要求的一致性；
（9） 给所有的输出加注解，并设计输出报表格式。测试监理
目前国内信息ERP应用系统建设过程中，在此阶段常发生未经过严格系统测试就匆忙上线试运行的情况，这往往会造成不稳定的新系统对实际工作环境的影响，在某些情况下会阻碍系统的正式上线运行。
因此监理单位在此阶段主要检查承建单位是否按照设计中制定的规范与计划进行测试。但切忌由监理单位进行单元、集成或确认测试而取代开发方的内部测试，这种方法并不能保证工程的质量。
如果监理单位具有丰富的测试工作资质与经验，可以考虑在此阶段由监理方在业主单位、承建单位的配合下具体进行系统测试工作。由于监理单位对工程建设启动阶段、需求分析阶段、设计阶段、实现阶段的工作有深入的了解，由监理单位进行系统测试工作往往能够得到较好的效果。
一、软件测试监理的目标
1） 监督和控制承建单位的软件测试过程，确保软件测试按照承建单位的测试文档规范和业主的软件要求实施；
2） 软件测试反映出、记录着软件产品的真实情况；
3） 软件测试的各个阶段按计划步骤实施；
4） 对于软件测试反映出的问题能有效地按回归测试规范进行处理；
5） 最后得到符合软件任务书（或合同）要求的软件产品集；
6） 软件测试的进度与计划保持一致性。
二、软件测试监理的活动
1） 监督承建单位将合适的软件测试工程方法和工具集成到项目定义的软件过程中。
（1） 依据项目定义的软件过程对软件测试任务进行综合。
（2） 选择软件测试可用的方法和工具，并将选择专用工具或方法的理由写成文档。对备选方法和工具进行选择的依据是：
机构标准软件过程
项目定义的软件过程
现有的技术基础
可得到的培训
合同需求
工具的能力
使用的方便性和提供的服务
（3） 选择和使用适合于软件测试的配置管理模型。配置管理模型可能是：
入库出库模型
组合模型
事务处理模型
更改处理模型
（4） 将用于测试软件产品的工具置于配置管理之下。
2） 监督承建单位依据项目定义的软件过程，对软件测试进行开发、维护、建立文档和验证，以满足软件测试计划要求。软件测试由静态测试、单元测试、集成测试、确认测试和系统测试组成。
（1） 可以客户和最终用户一同参与开发和评审测试准则。
（2） 使用有效方法测试软件。
（3） 基于下列因素确定测试的充分性：
测试级别。测试级别有：单元测试、集成测试、确认测试和系统测试。
选择的测试策略。测试策略有：功能测试（黑盒测试）、结构测试（白盒测试）和统计测试。
欲达到的测试覆盖。测试覆盖方法有：语句覆盖、路径覆盖、分支覆盖和运行剖面覆盖。
（4） 对每个级别的软件测试，建立和使用测试准备就绪准则。确定测试准备就绪准则包括：
软件单元在进入集成测试前已成功地完成了代码的静态测试和单元测试
在进入系统测试前，软件已成功地完成了确认测试
在软件进入系统测试前，已对测试准备就绪进行评审
（5） 每当被测试软件或软件环境发生变化时，则在各有关的测试级别上适当进行回归测试。
（6） 对于测试计划、测试规程和测试用例，准备使用前通过评审
（7） 管理和控制测试计划、测试说明、测试规程和测试用例。
（8） 每当软件需求、软件设计或被测试代码更改时，适当地更改测试计划、测试说明、测试规程和测试用例。
3） 监督承建单位依据项目定义的软件过程，计划和实施软件的确认测试。
（1） 基于软件开发计划，制定确认测试计划并写成文档。
（2） 负责软件需求、软件设计、系统测试及验收测试的人员，评审确认测试用例、测试说明和测试规程。
（3） 依据指定的软件需求文档和软件设计文档的指定版本，进行软件确认测试。
4） 计划和实施软件系统测试，实施系统测试以保证软件满足软件需求。
（1） 尽早分配测试软件的资源，以做好充分的测试准备。所需的测试准备活动包括：
准备测试文档
准备测试资源
开发测试程序
开发模拟程序
（2） 编制系统测试的计划文档，如果合适，该测试计划由业主单位进行评审和认可。此测试计划包括：
全面测试和验证的方法
测试职责
测试工具、测试设备和测试支持需求
验收准则
（3） 由一个独立于软件开发者的测试小组来计划和准备所需的测试用例和测试规程。
（4） 在测试开始前，对测试用例建立文档，并经评审和认可。
（5） 依据已纳入基线的软件及其软件任务书（或合同）和软件需求文档，实施软件测试。
（6） 对测试中发现的问题建立文档，并跟踪到关闭。
（7） 建立测试结果文档，并以此作为判断软件是否满足需求的基础。
（8） 管理和控制测试结果。
5） 软件监理组跟踪和记录软件测试的结果。跟踪和记录的内容有：
（1） 跟踪、累计的软件产品缺陷的数量、类型和严重程度
（2） 软件测试工程活动的状态
（3） 有关问题严重性和持续时间的报告
（4） 用于分析每个更改建议的工作量及汇总统计量
（5） 按类别（如界面、安全性、系统配置、性能和可用性）被纳入软件基线的更改数量
三、软件测试监理的方法
1） 定期审查软件测试的工程活动和工作进度。
2） 根据实际需要对软件测试工程活动进行跟踪、审查和评估。
3） 对软件测试工程活动和产品进行评审和（或）审核，并报告结果。这些评审和（或）审核至少应包括：
软件测试工程任务的准备就绪和完成准则得到满足。
软件测试符合规定的标准和需求。
已完成所需的测试。
检测出的问题和缺陷已建立文档，并被跟踪和处理。
通过软件测试，软件产品符合软件需求的要求。
在软件产品提交前，依据软件基线验证了用来管理和维护软件的文档。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：ERP软件编码、测试阶段的监理
相关文章
