会计信息系统开发审计

答：会计信息系统开发审计的目标包括以下几点：

（1）审查系统的可行性

并不是所有的问题都有明显的解决办法，事实上，有许多问题是不可能在预定的系统规模中得到解决的。那么，面临根本无法解决的问题，如果还投入过多的人力、物力、财力就成为一种无谓的浪费，因此，在进行系统开发之前，对于系统是否可能有解决的方案进行研究。即在项目开发确定之前，对系统开发的必要性和可能性进行分析、评价和论证，这就是可行性研究，它是会计信息系统开发的第一步，也是必须的一步。

如果系统在开发之前，没有进行可行性研究，则审计人员要与用户及有关人员共同对系统进行可行性研究，确定系统的目标是否能够达到，建立新系统是否必要，从经济、技术、运行上分析开发是否可行，只有得出新会计信息系统既有必要又有可能开发的结论，才能开发新系统。

如果系统在开发之前已经进行了可行性研究，则审计人员应对可行性研究的资料和结论进行审查，关注其是否进行了必要性分析，是否已经从经济上、技术上、运行上的可行性方面进行了分析，分析工作是否全面。特别要注意的，一是在经济可行性分析时费用的估算是否合理，效益方面是否有估计过高的显现；二是在技术可行性分析时，硬件、软件是否能够满足本单位数据处理的要求，人员的技术力量能否满足要求。

（2）审查系统的合规性、合法性

会计电算化系统虽然在很多方面区别于手工会计系统，但是，二者都必须遵循国家有关的法律、法令、方针、政策，必须符合有关部门颁布的各种规章、制度、准则等。另外，会计电算化系统也有一些相关的针对性的规章制度，例如，《会计电算化工作规范》、《会计电算化管理办法》、《会计核算软件基本功能规范》等，因此，在系统开发过程中，审计人员应对系统开发的文档资料进行审查，对系统的设计给予适当的监督、指导，保证系统的功能符合有关的法律法规、规章制度。

（3）审查系统内部控制的适当性

内部控制是指被审计单位为了保证业务活动的有效进行，保护资产的安全完整，防止、发现和纠正错误与舞弊，保证会计资料的真实、合法、完整，而制定和实施的政策和程序。内部控制不仅包括对企业经济活动进行综合计划、控制和评价而制定或设置的各项规章制度，也包括核算、审核、分析各种信息资料与报告的程序与步骤，还包括企业高级管理层用来授权和分配责任的各种方式。

从传统的手工会计到会计电算化系统，企业内部控制的基本要求和目标没有改变，但由于会计信息处理方式和方法的电算化，使得会计业务处理程序和工作组织发生了质的变化，由此引发内部控制的具体内容也出现了一些新的特点和变化。在会计电算化条件下，尽管计算机不能取代所有会计工作，但是，关键的会计信息处理和业务核算工作已由会计电算化软件集中进行，这样会计软件导致的系统问题将成为会计电算化系统中内部控制的主要风险，比如在信息处理过程中存在“垃圾进，垃圾出”的特点，使得数据输入操作不当的控制成为整个会计电算化程序中最关键的控制环节。另外，电算化条件下数据与责任的高度集中衍生出一系列内部控制的问题，如会计资料存储介质的变化影响到会计数据的安全，程序被非法调用篡改的可能性加大等。这一系列新特点都意味着会计电算化系统应该比手工会计系统更加重视内部控制。

在审计过程中，审计人员除了要监督系统开发人员在进行系统开发时遵循应有的系统开发控制，同时，还要在新系统中建立必要的内部控制。要注意的是，如果片面强调内部控制就会降低系统开发效率和系统运行效率。因此，审计人员还要注意新系统中设计的内部控制是否恰当，评价控制所带来的效益是否大于控制的成本，否则应取消该项控制措施。

（4）审查系统的可审性

所谓可审性，是指有能力、有资格的审计人员，能够在一个合理的时间和人力限度内，对系统的正确性和可靠性等做出公正的评价。一般来说，影响会计电算化系统可审性的因素较多，例如，客户管理当局的正直性、系统内部控制情况、系统开发的步骤、各项业务活动的历史记录情况等。其中，有关各项业务活动的历史记录情况是一个非常重要的因素，审计人员一般称这些能够提供发现问题的途径的历史记录为审计线索。在会计电算化系统中的审计线索既容易被销毁，也容易被篡改，甚至会因为设计时的考虑不周而使审计线索彻底消失。正是因为审计线索的这些特点，使得审计人员进行系统开发审计的过程中必须要注意审查系统是否能够保留足够的审计线索，以利于以后进行的事后审计。必要时，在系统开发过程中，审计人员可以要求在应用程序中嵌入适当的审计程序，以便日后开展审计工作。

（5）审查系统测试的全面性、恰当性

系统测试是系统开发过程中必不可少的一个环节，在正式投入运行之前，每个会计电算化系统都必须进行。审计人员对系统测试进行审计时，审查要点包括：一是测试数据的选取及系统测试是否按测试计划进行，即是否根据一定的规则来设计测试用例并选取合适的测试数据，是否根据测试计划进行并记录了相关结果；二是系统测试是否在公正、客观的立场上进行，因此应该避免由源代码编写人员来执行；三是系统测试是否有客户参加，是否按照客户手册进行，因为只有软件的功能和性能符合客户的需求，软件才是有效的，所以，系统测试必须有用户的积极参与，在必要的情况下，还要对用户进行相关的培训，使用户有能力设计测试并评价测试结果；四是系统测试结果是否得到开发、运行、维护及用户的负责人认可，因为系统测试是对前面各个阶段工作的一个检验，同时也是后期运行维护工作的基础和重要的参考依据，所以获得相关人员的认可可以明确各阶段职责，实现各阶段工作相互交接和衔接的基础；五是是否对系统测试的结果进行了记录与保管，对于系统测试应有详细的测试记录，包括测试人员、测试时间、所采用的测试用例和测试数据的来源、测试的过程以及测试的结果，并填写完成测试报告。

在系统测试的审计阶段，测试计划和测试报告是审计人员开展工作的重要依据。一方面，审计人员要审查测试计划的制订和测试方案的设计是否充分合理；另一方面，还要审查测试计划和测试方案的执行情况。在必要的情况下，审计人员可以根据系统功能的重要性，抽取相关的测试用例重新执行来进行检验，同时，也可自行设计测试用例进行验证。只有在实际开发出的会计电算化系统在合法性、功能、性能、安全等方面均达到系统目标以后，才能通过测试，否则，审计人员应与有关人员共同分析存在的问题及原因，并督促相关人员进行改正。

（6）审查系统文档资料的完整性

会计电算化系统的开发过程中会涉及多种文档，这些系统文档是一个完整的会计电算化系统不可或缺的部分。系统的文档资料包括：可行性研究报告及其批准资料，系统分析及系统设计资料，程序设计资料及操作手册等。这些资料一方面可以为负责维护和使用系统的人员提供必要的资料，另一方面也是今后审计的重要线索。因此，审计人员要审查开发各阶段的系统文档资料是否完整、规范，如果不符合要求，应监督相关人员编制或修改相应的文档资料。

（7）审查系统的可维护性

系统维护是指系统在正式投入使用以后，为了改正错误或满足新的要求而修改系统的过程。系统维护的工作量很大，而且也很复杂，但是它可以延长系统的寿命、提高系统的效率。系统的可维护性是指系统易理解、易修改和扩充的程度。审计人员在审查系统的可维护性时，主要是审查系统的开发是否采用了软件工程的方法，严格按各工作阶段的要求工作；是否有必要的措施，对系统开发活动进行管理和控制；系统是否采用了结构化分析和设计技术；是否按功能来划分模块，模块的划分是否遵循“高内聚，低耦合”的原则；数据与程序是否相对独立；系统是否留有规范化的接口，以便今后扩充系统；系统文档资料是否完整准确地描述了开发的系统等。

答：系统分析主要是为了了解、选择和确定准备开发的系统。一般先由分析人员进行调查，提出一个新系统的总体方案，再进行可行性研究，如果通过可行性研究，便可以进行需求分析，并将用户的需求和解决的方法确定下来。

系统分析工作是系统开发的第一步，它的好坏直接关系到开发工作的成败。由于在实际情况中，系统分析的工作量非常大，所涉及的业务、人员、数据和信息非常多，而且，用户的需求是难以一次确定的，并且会不断地变化；另外，分析人员对业务或用户的行业可能并不熟悉，常常会发生理解上的偏差，从而导致模型的错误。因此，这一阶段的审计也就显得尤为重要。如果这个阶段的审计工作进行得比较充分完整，就能尽早发现错误和疏漏的地方，及时提出并解决它们，进而可以大大减少后期修正的工作量，同时也使整个系统的安全、可靠及有效得到保证。

这一阶段的审计工作主要包括两方面：一是要审计整个系统分析工作是否按照计划的、必要的步骤来进行的，二是要审计系统分析所涉及的内容及决策是否是合理的、准确的。下面对系统分析阶段的四个方面进行说明：

（1）系统目标的确定

要开发新系统就要先确定新系统的目标，系统分析人员必须就企业正在面临的问题和新系统要解决的问题加以确定，并且要考虑问题的性质以及对现行系统的影响。

如果新的信息系统解决企业所面临问题的方案对企业现行的组织系统或其他系统有比较大的影响，那么分析人员就要考虑企业对这种影响的接受程度有多大；如果信息系统解决方案有很多不确定的需求，那么分析人员要考虑是否能够采取措施减少这些不确定的因素；另外，分析人员还要对问题的定义征求客户的同意，如果不同意还要采取办法解决。

因此，在这一阶段，审计人员主要考虑用户是否对问题的定义达成了共识，并且要考虑该定义对系统有效性和系统效率的影响。

（2）分析已有系统

开发人员如果想高质量地开发新的系统，就应该对已有的系统进行一定的了解。比如，利益是组织非常关心的问题，那么系统开发人员就要对新系统会对员工在利益方面产生多大的影响加以分析。分析已有系统主要包括两个任务：一是研究组织已有的结构和文化，二是研究已有的产品和信息流。

①研究组织已有的结构和文化。研究组织已有的结构和文化，是要了解系统所处的环境、系统处理的方法和用户需求，并将此应用于系统开发后续的步骤中。系统开发人员耗费精力去了解现行系统不仅是为了改进系统，而且也是为了避免系统的设计存在社会问题或技术问题。

②研究已有的产品和信息流。新系统的设计是基于已有的产品和信息流的，因此开发人员还需要通过研究已有的产品和信息流的优缺点来确定新系统的需求。例如，现行系统的缺点可以帮助开发人员确定对新系统的需求；同样，对已有产品和信息流的理解可以帮助评价新系统带给企业的改变程度，以便于开发人员对怎样实施这些变化做出更好的决策。

在此阶段，审计人员应取得现行系统的全部资料，并考虑两方面的内容：一是评估开发人员所选择考察的企业范围是否适当，以及其做出的决策是否正确合理；二是检查开发人员是否已与用户进行了充分的交流，并通过交流了解新系统的目标是否满足其要求。

（3）可行性分析

可行性分析实质上是进行一次简化的系统分析和设计的过程，它的目的是以最小的代价，在尽可能短的时间内确定问题是否能够解决。

进行可行性分析，首先要进一步分析和澄清问题的定义；在澄清问题后，系统分析人员应导出系统的逻辑模型；然后，从系统逻辑模型出发，得出若干种可供选择的主要解法；再对每种解法从经济、技术、运行三方面研究它们的可行性，从而判断系统目标能否实现，评估系统完成后所能带来的效益以确定是否值得投资开发新系统。如果问题没有可行的解法，分析人员应建议停止该项开发工程，以避免人力、财力、资源、时间的浪费；如果问题值得且能够解决，分析人员应该推荐一个较好的解决方案，并制订一个初步的计划。

在该阶段，审计人员应注意检查对系统开发人员提出的各种解法的可行性研究，尤其要注意在经济可行性方面，对于新系统成本或效益的估计不能过低或过高。审计人员可以向有关主管或会计部门查询，确定成本与效益的计算的合理性。

（4）需求分析

在可行性研究阶段，系统分析人员粗略地了解了用户的需求，还提出了一些可行的方案。需求分析就是要对目标系统提出完整的、准确的、具体的要求。简言之，需求分析的任务就是解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达出用户的需求。因此，需求分析是系统分析阶段最重要的环节之一，这一步工作的质量对于整个开发工作的成败来说都是决定性的。

需求分析阶段的工作可以分为四个方面：一是问题识别，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准，这些需求包括：功能需求（做什么）、性能需求（要达到什么指标）、环境需求（如机型，操作系统等）、可靠性需求（不发生故障的概率）、安全保密需求、用户界面需求等；二是分析与综合，逐步设计所有的系统功能，分析它们是否满足需求，剔除不合理部分，增加需要部分，最后，综合成系统的解决方案，给出目标系统的详细逻辑模型（做什么的模型）；三是编写文档，描述需求的文档称为软件需求规格说明书，并应向下一阶段提交；四是评审，对功能的正确性、完整性和清晰性给予评价，评审通过后才可进行下一阶段的工作，否则重新进行需求分析。

需求分析阶段中系统分析员应给出软件需求规格说明书等书面材料，这些文档是审计人员进行这一阶段审计工作的重要依据。审计人员要注意文档是否有明确的评价指标，比如系统性能要求，以作为将来系统质量评价的依据。另外，清楚地描述需求对接下来进行的设计工作非常重要，因此审计人员应考察系统开发人员是否认识到了这一点，并检查其描述是否和用户需求一致。

答：系统设计是信息系统开发过程中另一个重要的阶段。主要是根据前一阶段系统分析的结果，进行系统设计。系统设计通常分为总体设计和详细设计两个阶段。总体设计的任务是确定系统的模块结构和软件结构；详细设计的任务是描述每个模块内部具体的处理过程。对系统设计的审计主要就是对上述两个阶段进行审计，找出设计过程中存在的错误与疏漏的地方。比如，设计的电算化会计信息系统不符合《会计核算软件基本功能规范》的要求，甚至某些会计处理违反会计制度和有关法规的规定，设计出来的报表不符合会计制度的要求等。

（1）总体设计

经过需求分析阶段所做的工作，系统“做什么”已经清楚了，现在要确定的是系统“怎样做”。总体设计就是回答“概括地说，系统应该如何实现”这个问题的。因此，总体设计又称为概要设计。通过这一阶段的工作将划分出组成系统的各种元素，包括数据库、模块等，但是这些元素仍然处于黑盒子状态，另外系统开发人员还要确认组成系统的模块之间的关系如何。

总体设计一般应采用结构化设计方法。结构化设计方法是以模块化设计为中心，将目标系统划分为若干个相互独立的模块，这样使每一个模块需完成的工作变得明确，为设计复杂的系统打下了良好的基础。其中，模块是指数据说明、可执行程序等程序对象的集合。模块化就是把系统划分为若干个模块，每个模块完成一个独立功能，把这些模块集中起来组成一个整体，就可以完成指定的功能并满足问题的需求。由于模块相互独立，在设计其中一个模块时，不会受到其他模块的牵连，因而可将原来较为复杂的问题简化为一系列简单模块的设计。但是，如果系统开发人员要实现模块的相互独立，就应在该阶段模块进行划分时遵循“高内聚，低耦合”的原则。其中，内聚（Cohesion）是一个模块内部各成分之间相关联程度的度量。耦合（Coupling）是模块之间依赖程度的度量。

审计人员在总体设计阶段应该获取相关的文档资料，查明系统设计人员是否采用了结构化设计方法，设计的系统是否易于修改和扩充。另外，还需通过询问客户，查明系统的功能模块划分能否满足会计核算和内部管理控制的需要。

（2）详细设计

详细设计阶段的主要工作是要确定新系统的各项功能应该具体如何实现，也就是说这一阶段应该得出对目标系统的精确描述，从而在系统编码阶段可以直接翻译成用某种程序设计语言编写的程序。

详细设计阶段包括以下四项工作：

①数据库文件设计。数据库文件设计包括决定它的内容和结构。在设计数据库文件时应满足三点：一是应满足核算的需要和客户的需求，保证用户输入、处理后输出的数据存放在适当的数据库文件中；二是每个字段的设计应简洁、准确、可读，字段类型的设计应符合字段特征，字段长度的设计应在满足需要的前提下避免浪费存储空间；三是应尽量降低数据的冗余度，即要考虑数据结构规范化。

审计人员应仔细阅读数据库文件设计说明书，评估数据库文件是否按业务内容而设计的，是否符合范式要求。审计人员还可以询问客户，确定数据库文件的设计是否考虑到了用户的输入数据、输出信息的要求。

②代码设计。数据代码有很多的优点，它能够唯一地标识一个实体或一个属性，即每个实体或属性在系统中只能用一个代码来表示；它还可以压缩文字性或叙述性的描述信息。但是代码如果设计不好也会增大无效或错误数据的概率，因此在具体进行编码时应该掌握四个原则：一是灵活性，即当增加或减少实体或属性时，代码可在不变动原代码体系的基础上追加或减少；二是有意义，即一个代码能且只能标识出一个实体或属性；三是压缩性，即一个代码应利用尽可能少的字符传达尽可能多的信息；四是可扩展，即代码能不断使用用户的新需求。比如开发电算化会计信息系统时的科目代码设计。

审计人员应该结合目标系统的特点和要求，评价所采用的编码类型是否适应本系统的需求，是否符合国家、行业颁布的标准代码；审阅代码设计的相关文档，看其能否满足数据处理的要求，代码及其名称是否具有唯一性。

另外，为了防止录入数据时发生的错误可能导致的严重后果，对于重要的代码设计人员可以考虑设计校验码。校验码是指在编码中加入一个或几个冗余位来检验代码中其他位的准确性，既可以作为前缀或后缀，也可以放在中间。因此，审计人员也要复核重要代码的校验码设计情况，如校验码的计算规则是否正确、校验方法的选择是否恰当。

③输入输出设计。针对电算化会计信息系统的输入输出设计，设计人员需要考虑是否满足《会计核算软件基本功能规范》中有关输入、输出设计的要求。

审计人员在审查该项工作时，应详细调查目标系统的输入输出设计环节，查明系统是否存在适当的控制措施保证，确保所有的输入数据、输出信息都是完整正确的。另外，审计人员还要重点关注系统能否由输入查至输出，或由输出追踪至输入，因为只有这样才能保证系统保留有适当的审计线索，以利于后期的审计工作。

④处理功能设计。针对电算化会计信息系统的处理功能设计，设计人员仍然需要考虑是否满足《会计核算软件基本功能规范》中有关数据处理设计的要求。

审计人员可以通过审阅相关文档，或者通过询问客户，查明目标系统的数据处理功能是否符合相关规定的要求并满足用户的需求。

答：系统实施是在完成系统分析、系统设计的基础上所进行的工作，主要包括三项内容：编码、测试和试运行。

（1）编码

编码主要是依据系统设计阶段的数据库结构和代码设计，用计算机程序语言来实现系统设计中的每一个细节。程序编写得好坏直接影响到信息系统的质量，因为即使系统分析和系统设计工作都很充分，如果编程的质量无法保证也会大大影响整个系统的实现。由于程序编码的工作量较大，审计人员对编码的审计主要从编程语言的选择、编程方法、相关文档的编写这几方面来进行。

①编程语言的选择。计算机语言可以分为汇编语言和高级语言。汇编语言的语句和计算机硬件操作有一一对应的关系，一般这种语言是支持这种语言的计算机所独有的，因此使用不够方便。我们目前通常使用的是高级语言，比如C语言等。在实际选择中，设计人员一般会考虑客户的要求及软硬件的局限性，只有这样才能使编码更容易阅读与维护。审计人员应收集相关证据，以证明系统开发人员是否利用了科学的依据，并在平衡了各种因素后才作出的选择。

②编程方法。编码一般应选择合适的数据结构和正确的算法，采用结构化的程序设计方法。结构化的程序设计方法的特点有：编码一般是自顶向下进行的，即高层模块比底层模块先编码；程序中的每个模块都只能有一个入口和一个出口，且模块长度限制在50～100个语句的范围；程序只有三种基本结构，即顺序结构、选择结构、循环结构，禁止使用其他结构。审计人员一般要先了解开发人员是否采用了结构化的编程方法，并通过检查部分代码来评价代码的质量。如果代码质量较低，审计人员需要考虑对接下来的测试范围和测试量的影响。

③相关文档的编写。编码完成后，每个程序都应有程序运行手册以及程序文档，并应提供程序主要组成部分和相关关系的图表。程序文档一般包括程序设计说明书、流程图、源程序清单等。审计人员应通过审查抽取的文档样本判断文档是否完整、规范。如果文档质量较高，审计人员就可以考虑减少接下来的测试量了。

由此可以看出，编码审计不用审计人员通读整个代码，更主要的是对整个编码过程的跟踪和控制。

（2）测试

测试就是在软件交付用户使用或投入运行前，对系统需求说明、设计规格说明和程序规格说明的最终复审，是软件质量保证的关键步骤。一般应由系统开发人员、客户、审计人员共同参与。

软件测试是为了发现错误而执行程序的过程。软件测试在软件生命周期中横跨两个阶段：通常在编写出每一个模块之后就需要对它做必要的测试（称为单元测试），编码和单元测试同属于软件生命周期中的一个阶段；在结束这个阶段后对软件系统还要进行各种综合测试，如集成测试、验收测试、性能测试等，这是系统开发过程中的一个独立阶段，即测试阶段。

测试一般包括七个步骤：

①选择测试边界。测试可以针对一个模块、几个模块或者整个程序。

②确定测试目标。一个具体测试可针对若干个目标进行。

③选择测试方法。可选择常用的测试方法进行测试，如黑盒测试、白盒测试。黑盒测试是通过使用整个软件或者某种软件功能，以用户的观点，从输入数据到输出数据的对应关系出发进行测试，而没有检查程序的源代码。白盒测试是通过检查程序的源代码，根据程序的内部结构进行的，它并不使用用户界面。

④开发测试方案。主要工作是开发测试用例，并根据测试用例设计测试数据或测试方案，定义相应的测试结果。对于测试用例的设计，不但要有正常的、有效的各类业务，还应包括各种可能的错误，以查明系统能否接受并处理正常业务而拒绝接受不合理或错误的业务。

⑤执行测试。

⑥评估测试结果。开发人员将测试结果与预期结果比较，以查找程序中可能的错误。

⑦完成测试文档。将测试过程中的所有步骤和结果记录到文档里。

在系统测试阶段，测试计划和测试报告是审计人员开展审计工作的重要依据。一方面，审计人员要审查测试计划的制订和测试方案的设计是否充分合理，测试工作的执行是否遵循测试计划和测试方案进行的；另一方面还要检查审计报告所记录的测试过程、结果是否得到了系统开发人员及客户的认可。如果审计人员怀疑测试未按计划、方案进行，则审计人员可以抽取相关的测试用例重新执行来进行检验；同时，审计人员可以考虑自行设计一组测试用例进行验证。

（3）试运行

新系统开发出来之后，往往并不能立即投入运行，而是要经过一段时间的试运行。尤其是新系统代替旧系统这种系统转换的过程会更加艰巨，就更加需要进行充足的试运行。

电算化会计信息系统正式使用之前，也必须与手工并行运行一段时间，以检验其是否达到预定目标，软件是否有缺陷或错误，以及系统的合法性、安全性、可靠性等。这种并行方式是系统转换方式中常用的一种。在整个试运行的过程中，系统开发人员所要达到的目的包括：

①会计核算软件的功能检查。通过试运行，检查核算软件所能完成的功能是否达到了原设计的要求，每一功能模块是否按规定的处理程序及方法完成核算业务。

②正确性检查。通过试运行，并与手工比较，检验会计核算软件在记账、编制报表、成本核算、工资计算等业务处理的正确与否。

③合法性检查。检查会计核算软件是否符合财政部关于会计核算软件的几项规定的有关要求，是否符合财政部门制订的财务会计制度。

④可靠性、安全性检查。检查整个系统在运行过程中是否安全可靠，能否保证会计核算工作的正常进行，能否防止一些意外事故等。

⑤及时性。系统运转，能否保证及时提供、上报有关会计信息，包括账、表等。

⑥例外情况检查。通过试运行，及时发现一些原先设计时未加考虑的例外事件，并及时采取措施，改进完善软件。

总之，通过试运行，及时发现设计中的一些错误、问题，排除一些隐患，完善功能，保证会计核算软件在投入使用后尽量不发生或少发生问题。

财政部规定，会计核算软件要经过三个月以上的试运行。对于由财政部主持评审的商品化会计核算软件，要求在四个以上用户跨年度运行半年以上。

在试运行阶段，一方面手工核算工作仍要继续，另一方面要花力量组织并输入计算机会计核算所需的当月数据，包括记账凭证、成本核算数据、职工考勤等，操作计算机完成有关会计核算业务，并输出所有总账、明细账、报表和有关核算的中间结果。分析计算机输出结果与手工账表数据比较，查找差异原因，若属软件设计原因，就必须由有关人员修改程序，改正缺陷。

系统试运行方案是审计人员这一阶段审计工作的重要依据。审计人员根据试运行方案审查系统试运行的准备情况，实施情况以及检测反馈情况。其中，审计人员尤其要重点核对新系统输出与老系统数据的结果。

答：当电算化会计信息系统经过一定时期的试运行，达到有关要求规定，就可以甩掉手工记账，由计算机完成会计核算工作。会计电算化的首要目的，就是要使财会人员摆脱烦琐的记账、算账、报账工作。但是即使系统开发的前期阶段的控制与审计都是成功的，也不能保证在正式运行中不出问题。因此，系统运行维护过程中仍需要对系统的运行和维护进行审计。

（1）系统运行

电算化会计信息系统要保证正常运转，还需要具备相应的条件，因此，财政部在《会计核算软件管理的几项规定》中规定，替代手工记账必须具备以下条件，这也是审计人员在进行系统运行的审计时需要关注的控制点：

①单位获得“会计工作达标单位”证书。

②采用的会计核算软件已通过评审。

③与手工系统并行运行三个月以上，保存有完整的与手工核算相一致的数据。

④配有专门或主要用于会计核算工作的计算机和计算机终端，并配有指定的专职或兼职的上机操作人员。

⑤有严格的操作管理制度，主要包括四方面内容：

A.操作人员工作职责和工作权限，包括每个操作人员只能拥有其分工范围内的操作使用权限，不得越权操作与己无关的内容；操作人员不得拥有对系统的修改权，包括对软件、代码、会计数据的修改权等；系统发生故障时，操作人员应采取相应的措施，记录故障及其处理结果，并及时报告系统管理员；在系统运行过程中，如果操作人员要离开现场，必须退出系统，以防他人越权操作；操作人员的操作密码不得告知其他任何人，而且密码要经常更换，密码一经泄露必须立即更换。

B.预防记账凭证等数据未经审核而输入计算机的措施，即输入数据要按规定程序采集，经审核确认为合法真实的数据后才能输入系统。

C.预防已输入计算机的记账凭证未经复核而登账的措施。

D.必要的上机操作记录制度，操作记录可以根据情况采用手工记录和计算机自动记录两种形式。对于记录的责任人、内容要求及事后的分析处理工作事先均应有明确的规定，以防记录工作流于形式。一般每次上机人员及上下机时间，系统运行过程中出现的异常情况、故障及恢复处理情况都适用手工记录；而对于系统运行的操作记录可以采取计算机自动记录的方式，比如在软件中建立日志文件功能，可以通过日志文件自动记录。

⑥有严格的硬件、软件管理制度，包括三方面内容：

A.保证机房设备安全和计算机正常运转的措施。

B.会计数据和会计软件安全保密的措施。会计软件应规定访问的权限，由指定人员保管会计软件的备份，并对运行的会计软件实行严格的登记、监督制度。另外对于会计数据应按规定的程序、权限和要求输出，即应根据数据不同保密的要求，确定不同人员对各类数据访问的权限，操作人员只能按照相应的权限查询和打印相应的信息，而且应要求操作人员按照规定定期打印输出机内账簿等数据资料。

C.修改会计核算软件的审批、监督制度。

⑦有严格的电算化会计档案管理制度。系统运行阶段的审计是审计人员在系统正式运行阶段，针对信息系统是否被正确操作和是否有效地进行，从而真正实现信息系统的开发目标、满足客户需求而进行的审计。审计人员应采用多种审计方法执行审计工作。审计人员可以通过观察系统操作人员的工作情况，审阅被审单位电算化会计信息系统的操作管理制度，查明系统的各岗位人员的职责是否明确，有无不相容职务由同一人兼任及未经授权批准的人员接触程序和数据并对其进行修改的状况。审计人员还可以检查上机操作记录，查明记录是否及时、完整，有无异常情况，系统的故障及恢复处理是否及时。

（2）系统维护

系统维护是指在系统交付使用以后，可能是为了改正系统的错误或缺陷，也可能是为了适应软硬件环境的变化，或者是为了改进设计以满足客户需求，而对它所作的修改。由此可见，系统维护对于系统的正常运行起着至关重要的作用。而对系统维护的审计也是系统审计中的重要部分。以下通过系统维护阶段工作过程的顺序分别介绍。

对信息系统进行维护，首先要建立一个维护组织，这是进行信息系统维护的第一步。建立的维护组织既可以是短期的、临时的维护小组，也可以是长期的、永久的维护小组。在对维护组织进行审计时，审计人员应该考虑维护组织的大小是否适应信息系统的规模的要求，组织中人员的职责分工是否明确，以及是否有一套科学的内部管理机制和协调工作机制。

当接到维护申请后，维护小组首先应根据具体情况制订维护计划，维护计划的主要内容包括：维护任务的性质和范围，维护任务所需要的资源，确认维护的要求、维护的费用预算以及进度计划等。审计人员在对维护计划进行审计时，主要审计维护计划的内容是否完整，维护资源的配置是否明确，维护费用的预算是否能满足维护活动的需要，进度安排是否合理等。

制订计划后，就可以开始实施具体的维护工作。系统测试人员一般要先分析和理解源程序，在分析和理解程序后再设计程序的修改计划，接着就可以对程序代码进行修改了。在整个过程中，审计人员应检查维护计划是否是在分析和理解程序后进行的；程序设计说明书是否按维护计划进行修改并得到了负责人的认可；程序的修改是否在得到维护负责人的同意后才得以实施，是否按照修改后的程序设计说明书进行的修改。

最后就是对维护活动的验收，即维护确认工作。审计人员要考虑修改程序的测试工作是否按照维护测试计划进行的，是否有用户参与到修改程序的测试中，修改后的程序是否进行了与新开发的程序同等程度的测试，最后是否得到开发、运行、维护及用户负责人的认可。对于测试数据及其结果要检查是否记录并妥善地保存下来。