ERP监理的目标和内容

ERP监理的目标

 

　　ERP监理工作应力求达到以下主要目标：

　　

　　① 对软件开发单位、软件实施单位等系统承建单位的行为进行监控，促使开发行为符合国家法律法规、有关政策和相关技术标准，制止开发行为的随意性和盲目性，促使开发进度、质量按计划（合同）实现，力求开发行为合法、科学、合理、经济；

　　

　　② 促进用户与软件开发单位、软件实施单位和系统承建单位之间的有效沟通，使软件开发单位、软件实施单位和系统承建单位能够全面准确了解用户的实际需求，同时用户能及时了解项目的进展情况；

　　

　　③ 促使软件开发单位、软件实施单位等承建单位为项目运行的全过程建立一套明确、合理、可行的计划或规程，并利用与之相应的审核、监理机制和手段对其执行过程进行有效控制；

　　

　　④ 促使系统的关键技术指标在项目实施过程中处于受控状态，及早预测和发现可能影响施工计划的各种因素，及时纠正可能影响系统功能与性能的缺陷。

　　

　　一般来说，监理项目部的目标就是通过监理工程师谨慎而勤奋的工作，力求在项目的成本、进度和质量目标内实现建设项目。

　　

　　由于工程建设监理具有委托性，所以监理单位可以根据业主单位的意愿并结合自身的实际情况来协商确定监理服务范围和业务内容。既可承担全过程监理，也可以承担阶段性监理，甚至还可以只承担某专项监理服务工作。但是在ERP应用系统建设中，最好采取全过程监理方式。

　　

　　监理要达到的目的是“力求”实现项目目标。因此，监理单位和监理工程师“将不是，也不可能成为承建单位的工程承保人或保证人”。谁设计谁负责，谁施工谁负责，谁供应材料和设备谁负责，而作为工程承包合同“甲、乙方”之外的“第三方”的监理单位和监理工程师则没有承担他们双方义务的责任。

　　

监理是一种技术服务性质的活动。它不直接进行设计，不直接进行开发，不直接进行实施，不直接进行软硬件的采购、供应工作。因此，它不承担设计、开发、实施、软硬件选型采购方面的直接责任。所以，监理单位只承担整个建设项目的监理责任，也就是在监理合同中确定的职权范围内的责任。在实现ERP应用系统建设项目的过程中，外部环境潜伏着各种风险，会带来各种干扰。而这些干扰和风险并非监理工程师完全能够驾驭的，他们只能力争减少或避免这些干扰和风险造成的影响。所以，对于提供监理服务的监理单位来说，他不承担其专业以外的风险责任。他虽不能保证项目一定在预定目标内实现，但在政府有关部门和监理行业组织的规范下，出于职业道德的良知，基于他的社会信誉和经济方面的考虑他们会竭尽全力为在预定的投资、进度和质量目标范围内实现项目而努力工作。

ERP项目准备阶段的监理

准备阶段监理的主要任务是协助业主制定招标文件和评标标准，监督招标过程，对投标单位进行资质审查，确定中标单位后，参与业主和中标单位的合同谈判，协助业主确定合同条款并最终签订信息ERP应用系统建设合同。 　　 ERP项目立项监理 　　 　　一般来讲，立项过程由业主完成，业主也可以通过“任务委托书”的形式委托有关单位完成。虽然在一般的监理委托合同中，监理单位不参与项目前期立项工作。但是在咨询式监理服务中，监理单位也有可能参与工程立项工作。立项阶段最终要的工作就是编制可行性研究报告，说明项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论证所选定的方案。 　　 　　监理可协助业主单位根据实际需求编制可行性研究报告，确定系统设计目标和项目范围、功能、运行环境、投资预算和竣工时间等项目要素。可行性研究报告首先由项目负责人审查，再上报给上级主管审阅，从可行性研究应当得出“行或不行”的决断。 　　 　　一、可行性研究 　　 　　一般可行性研究包括四个方面的研究： 　　 　　经济可行性：进行成本∕效益分析。从经济角度判断系统开发是否“合算”。 　　 　　技术可行性：进行技术风险评价。从建设基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。 　　 　　法律可行性：确定系统开发可能导致的任何侵权、妨碍和责任。 　　 　　方案的选择：评价系统或产品开发的几个可能的候选方案。最后给出结论意见。 　　 　　二、可行性研究报告 　　 　　可行性报告的形式可以有多种，但最重要的监理内容应当有： 　　 Ⅰ. 项目背景：① 问题描述   ② 实现环境   ③ 限制条件 Ⅱ. 管理概要和建议：① 重要的研究结果   ② 说明   ③ 建议   ④ 影响 Ⅲ. 候选方案：① 候选系统的配置   ② 最终方案的选择标准 Ⅳ. 系统描述：① 系统工作范围的简要说明   ② 被分配系统元素的可行性 Ⅴ. 经济可行性（成本－效益分析）：① 经费概算   ② 预期的经济效益 Ⅵ. 技术可行性（技术风险评价）：① 技术实力   ② 已有工作基础   ③ 设备条件 Ⅶ. 法律可行性：① 系统开发可能导致的侵权，违法和责任 Ⅷ. 用户使用可行性：① 用户单位的行政管理，工作制度   ② 使用人员的素质 Ⅸ. 其它与项目有关的问题：① 其它方案介绍   ② 未来可能的变化

招投标阶段监理 　　 　　一、确定招标方式 　　 　　监理单位在招标阶段的第一项工作内容是了解业主需求，协助业主确定招标方式。根据有关国际组织协议或国内法规定以及信息服务项目招标的特点，在实践中确定信息服务招标方式的基本原则是： 　　 　　如果可以拟定详细的条件，而且服务的性质允许采用招标方式，如一般的电子政务信息服务软件系统、一般性质的ERP软件系统等，可采用公开或邀请招标的方式进行； 　　 　　如果不能确切拟定或最后拟定条件，或采购的服务相当复杂，可采用征求建议书、邀请建议书、两阶段招标、竞争性谈判、设计竞赛等方式； 　　 　　与其他形式的服务相比，聘用专家提供咨询、研究、监理等服务更侧重对专家知识、技能、经验方面的考虑，故有独特的方式； 　　 　　在招标方式确定后，监理单位应协助业主制定招标文件和评标标准，并对招标过程的组织提出建议。 　　 　　二、审查承建单位资质 　　 　　采用公开招标方式时，监理单位应协助业主对投标单位的资质进行审查，采用邀标或其他招标方式时，监理单位应协助业主单位对候选承建单位进行资质审查。 　　 　　目前国内信息ERP应用系统建设的过程中，某些工程项目由于在启动阶段对承建单位的选择不够慎重，片面强调了进度与投资方面的要求，导致最终选择的承建单位在企业资质及开发经验上都严重不足。承建单位选择的失误导致了后续的开发工作出现了大量问题，致使业主单位与监理单位投入大量的人力物力才能保证工程完成，而进度与投资方面也超出了原有计划。 　　 　　因此，在此阶段监理单位要协助业主单位对承建单位资质进行审查，如承建单位的软件企业认定情况、系统集成资质情况等，同时考察承建单位在以往的开发过程中是否从事过与本项目相关或相似的开发工作，帮助业主单位选择合格的承建单位，减小项目实施的风险。   审查承建单位质量管理体系 　　 　　目前国内信息ERP应用系统建设过程中，常出现承建单位对质量管理不够重视或不落实的情况，而业主单位由于进度等方面的要求和信息技术的弱势也往往忽视了承建单位此方面的工作。这造成了后续开发工作在没有严格质量保证的情况下进行，开发过程的随意性增大，容易出现不按设计编码、系统版本失控、测试工作不到位的情况，最终影响了工程建设的质量。承建单位质量管理体系是否通过相关认证或评估，标志着承建单位对质量管理的重视程度，也在一定程度上决定了承建单位产品或服务质量水平，因此，监理单位应对于承建单位质量管理体系进行审查。目前软件企业所遵循的质量管理体系主要有两种，一种是软件能力成熟度模型（SW-CMM），一种是ISO质量管理体系。        监督招标过程 　　一、开标过程监理 　　 　　开标应当在招标文件确定的提交投标文件截止时间的同一时间公开进行；开标地点应当为招标文件中预先确定的地点。 　　 　　开标时，要检查检查投标文件的密封情况，经确认无误后，由工作人员当众拆封，宣读投标人名称、投标价格和投标文件的其他主要内容。 　　 　　开标过程应当记录，并存档备查。 　　 　　二、评标过程监理 　　 　　评标委员会由招标人的代表和有关技术、经济等方面的专家组成，成员人数为五人以上单数，其中技术、经济等方面的专家不得少于成员总数的三分之二。 　　 　　专家应当从事相关领域工作满八年并具有高级职称或者具有同等专业水平，由招标人从国务院有关部门或者省、自治区、直辖市人民政府有关部门提供的专家名册或者招标代理机构的专家库内的相关专业的专家名单中确定；一般招标项目可以采取随机抽取方式，特殊招标项目可以由招标人直接确定。 　　 　　确认没有与投标人有利害关系的人进入相关项目的评标委员会。 　　 　　评标委员会成员的名单在中标结果确定前应当保密。 　　 　　确认没有任何单位和个人非法干预、影响评标的过程和结果。 　　 　　评标委员会应当按照招标文件确定的评标标准和方法，对投标文件进行评审和比较；设有标底的，应当参考标底。评标委员会完成评标后，应当向招标人提出书面评标报告，并推荐合格的中标候选人。 　　 　　招标人根据评标委员会提出的书面评标报告和推荐的中标候选人确定中标人。招标人也可以授权评标委员会直接确定中标人。 　　 　　在确定中标人前，招标人不得与投标人就投标价格、投标方案等实质性内容进行谈判。 　　评标委员会成员和参与评标的有关工作人员不得透露对投标文件的评审和比较、中标候选人的推荐情况以及与评标有关的其他情况。 　　 　　三、决标过程监理 　　 　　中标通知书对招标人和中标人具有法律效力。中标通知书发出后，招标人改变中标结果的，或者中标人放弃中标项目的，应当依法承担法律责任。 　　 　　招标人和中标人应当自中标通知书发出之日起三十日内，按照招标文件和中标人的投标文件订立书面合同。招标人和中标人不得再行订立背离合同实质性内容的其他协议。 　　 　　依法必须进行招标的项目，招标人应当自确定中标人之日起十五日内，向有关行政监督部门提交招标投标情况的书面报告。 　　 　　中标人应当按照合同约定履行义务，完成中标项目。中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。 　　 　　中标人按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件，并不得再次分包。 　　 　　中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。        合同签订监理 　　 　　合同的签订管理是指监理单位协助业主与承建单位之间的各种合同进行分析、谈判、协商、拟定、签署等。其中合同分析是合同签订中最重要的内容和环节，是合同签订的前提。监理工程师应对工程承建、共同承担风险的合同条款、法律条款分别进行仔细的分析解释。同时也要对合同条款的更换、延期说明、投资变化等事件进行仔细分析。合同分析和工程检查等工作要同其联系起来。合同分析是解释双方合同责任的根据。 　　 　　监理工程师在业主与承建单位订立合同的过程中要按条款逐条分析，如果发现有对业主产生风险较大的条款，要增加相应的抵御条款。要详细分析哪些条款与业主有关、与承建单位有关、与工程检查有关、与工期有关等，分门别类分析各自责任和相互联系的关联，做到一清二楚，心中有数。 　　 　　合同评审过程中的考查以下内容，确定以下内容在合同中进行了明确定义： 　　 　　定义/使用的术语 　　 　　保密约定 　　 　　知识产权约定 　　 　　双方义务 　　 　　合同价款及付款方式 　　 　　各阶段工程成果及交付期限。应选取里程碑式的工程成果交付的期限，并在一定程度上把成果和付款计划联系起来。 　　 　　验收标准和方式/工程的质量要求。应准确细致地描述工程的整体质量和各部分质量，必要时可以用明确的技术指标进行限定 　　 　　用户培训需求 　　 　　维护期约定，包括维护期长度、维护响应时间、维护方式和维护费用等 　　 　　违约责任 　　 　　期限和终止 　　 　　不可抗力 　　 　　变更，包括资金、需求、期限、合同等变更，对变更的范围进行约定，并明确每一种变更以何种方式何种程序处理。对范围外的变更，可注明另行协商并再补签合同。 　　 　　其他约定，如适用法律、争议解决和双方的其他协作条件等 　　 　　监理单位应将监理意见以合同评审专题报告形式提交业主。

企业调研、需求分析阶段监理

由于信息ERP应用系统建设针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求很复杂的情况。在这种情况下，如果不在监理单位的协调下进行业主单位与承建单位充分的沟通，往往造成承建单位按照自己的理解进行开发的情况，如果在测试阶段没有发现此类问题则给系统造成重大隐患，如果发现问题则造成工程建设返工与延期。

 

　　因此，在此阶段监理单位的工作重点是监督承建单位的分析人员、设计人员和测试人员对需求说明书的审查，并协调业主单位与承建单位需求说明书的评审确认。需求分析阶段工作落实的情况，直接决定了后续开发工作的质量、进度、投资与变更的情况，因此必须在监理过程中给予足够的重视。

 

需求说明书评审监理

 

　　一、需求说明书评审原则

 

　　原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”

 

　　原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

 

　　原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其它系统元素交互的方式。

 

　　原则4：规格说明必须包括系统运行的环境。

 

　　原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

 

　　原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。

 

　　原则7：规格说明必须容许不完备性并允许扩充。

 

　　原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。

 

　　这是由Balzer和Goldman提出的8条原则，主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其它各种形式的规格说明都适用。当然要结合实际来应用上述的原则。

 

　　二、需求说明书评审框架

 

　　需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。软件需求说明书的框架：

 

　　Ⅰ. 引言 A.系统参考文献   B.整体描述   C.软件项目约束

 

　　Ⅱ. 信息描述 A.信息内容表示   B.信息流表示 C数据流 D控制流

 

　　Ⅲ. 功能描述 A.功能划分 B.功能描述 C处理说明 D限制∕局限 E 性能需求

 

　　ⅳ 设计约束

 

　　ⅴ 支撑图  

 

　　Ⅳ. 行为描述 A.系统状态   B.事件和响应   C.控制描述

 

　　Ⅴ. 检验标准 A.性能范围   B.测试种类   C.期望的软件响应   D.特殊的考虑

 

　　Ⅵ. 参考书目

 

　　Ⅶ. 附录

         三、需求说明书评审内容

 

　　作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其它需求给予评价。评审的主要内容是：

 

 系统定义的目标是否与用户的要求一致；²　　

 

 系统需求分析阶段提供的文档资料是否齐全；²　　

 

 文档中的所有描述是否完整、清晰、准确反映用户要求；²　　

 

 与所有其它系统成分的重要接口是否都已经描述；²　　

 

 被开发项目的数据流与数据结构是否足够，确定；²　　

 

 所有图表是否清楚，在不补充说明时能否理解；²　　

 

 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；²　　

 

 软件的行为和它必须处理的信息、必须完成的功能是否一致；²　　

 

 设计的约束条件或限制条件是否符合实际；²　　

 

 是否考虑了开发的技术风险；²　　

 

 是否考虑过软件需求的其它方案；²　　

 

 是否考虑过将来可能会提出的软件需求；²　　

 

 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；²　　

 

 有没有遗漏，重复或不一致的地方；²　　

 

 用户是否审查了初步的用户手册或原型；²　　

 

 项目开发计划中的估算是否受到了影响。²　　

 

　　四、需求说明书评审检查

概要详细设计阶段的监理工作

软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列的设计质量的评审，以便及时发现和及时解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。

 

设计监理总则

 

　　软件设计监理的基本准则包括： 审查提交的文档是否齐全，审查文档编制与描述工具是否符合规范。确定承办单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，评价软件设计方案与数学模型的可行性，评价接口设计方案和运行环境的适应性，审查软件集成测试计划的合理性和完备性，审查数据库设计的完备性和一致性。并确定该阶段文档能否作为详细设计的依据，决定可否转入详细设计阶段。确认软件详细设计文档的内容符合软件编码的要求。

 

　　设计阶段中监理单位要尽可能与业主单位协调配合工作，听取业主单位从业务角度出发提出的对开发方设计的意见。监理单位主要从文档的规范性、可实施性出发，以国家相关标准为依据，从软件工程学的角度对承建单位提出意见与建议，配合业主单位工作，敦促承建单位做好工程项目的设计工作。在设计阶段，监理单位主要针对需求的覆盖性及可跟踪性、模块划分的合理性、接口的清晰性、技术适用性、技术清晰度、可维护性、约束与需求的一致性、可测试性、对软件设计的质量特性的评估、对软件设计的风险评估、对比情况、文档格式的规范性等几个方面进行评审。在此过程中，业主单位也需要对设计文档做检查，主要在功能设计是否全面准确地反映了需求、输入项是否完全与正确并符合需求、输出项是否符合需求、与外界的数据接口是否完全与正确并符合需求、各类编码表是否完全与准确并符合需求、界面设计是否符合需求、维护设计是否符合需求、各类数据表格式和内容是否符合要求、是否存在其它有疑问的设计等几个方面进行核查。

 

设计的评审内容

 

　　（1） 可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否复盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求。

 

　　（2） 接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。

 

　　（3） 风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。

 

　　（4） 实用性：即确认该软件设计对于需求的解决方案是否实用。

 

　　（5） 技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。

 

　　（6） 可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。

 

　　（7） 质量：即确认该软件设计是否表现出良好的质量特征。

 

　　（8） 各种选择方案：看是否考虑过其它方案，比较各种选择方案的标准是什么。

 

　　（9） 限制：评估对该软件的限制是否现实，是否与需求一致。

 

　　（10） 其它具体问题：对于文档、可测试性、设计过程，……，等等进行评估。

 

　　在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能、以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。

 

　　McGlanghlin给出在将需求转换为设计时判断设计好坏的三条特征：

 

　　① 设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。

 

　　② 设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。

 

　　③ 设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。

 

　　以上三点就是软件设计过程的目标。为达到这些目标，必须建立衡量设计的技术标准。

 

　　① 设计出来的结构应是分层结构，从而建立软件成份之间的控制。

 

　　② 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。

 

　　③ 设计应当既包含数据抽象，也包含过程抽象。

 

　　④ 设计应当建立具有具有独立功能特征的模块。

 

　　⑤ 设计应当建立能够降低模块与外部环境之间复杂连接的接口。

 

　　⑥ 设计应能根据软件需求分析获取的信息，建立可驱动可重复的方法。

 

　　软件设计过程根据基本的设计原则，使用系统化的方法和完全的的设计评审来建立良好的设计。

       一、概要设计的评审

 

　　软件概要设计监理的目的是对软件概要设计有关内容（重点是软件的结构、软件的功能、软件的结构、接口设计、接口关系等）、概要设计过程、概要设计活动、文档格式进行审查，确定承建单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件详细设计的前提和依据。

 

　　

 

二、详细设计的评审   　　软件详细设计监理的目的是对软件详细设计有关内容（重点是软件的算法、数据结构、数据类型、异常处理、计算效率等）、详细设计过程、详细设计活动、文档格式进行审查，确定承建单位提出的软件详细设计内容是否实现了软件概要设计的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件编码的前提和依据。   ＃ 检查项 Y/TBD/N/NA   清晰性     所有单元或过程的目的是否都已文档化？     包括了数据流、控制流和接口的单元设计是否已清晰的说明？     完整性     是否已定义和初始化所有的变量、指针和常量？     是否已描述单元的全部功能？     是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?     是否已列出该单元的调用？     依从性     该文档是否遵循了该项目已文档化的标准？     是否采用了所要求的方法和工具来进行单元设计？     一致性     数据元素的命名和使用在整个单元和单元接口之间是否一致？     所有接口的设计是否互相一致并且和更高级别文档一致？     正确性     是否处理所有条件 （大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？     是否正确地规定了分支（逻辑没有颠倒）？     数据使用     是否所有声明的数据都被实际使用到？     是否所有该单元的数据结构都被详细说明？     是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？     是否所有逻辑单元、时间标志和同步标志都被定义和初始化？     接口     接口参数在数量、类型和顺序上是否匹配？     是否所有的输入和输出都被正确定义和检查？     是否传递参数序列都被清晰的描述？     是否所有参数和控制标志由已描述的单元传递或返回？     是否详细说明了参数的度量单位、取值范围、正确度和精度？     共享数据区域及其存取规定的映射是否一致？     可维护性     单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？     性能     是否该单元的所有约束例如过程时间和规模都被详细说明？     可靠性     初始化是否使用到缺省值，缺省值是否正确？     是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？     是否执行输入、输出、接口和结果的错误检查？     是否对所有错误情况都发出有意义的信息？     对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？     是否考虑到意外事件？     易测性     是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。     该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）？     是否所有的逻辑都能被测试？     是否已描述测试程序、测试数据集和测试结果？     可追溯性     是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求？     是否所有的设计决定都能追溯到权衡考虑？     单元需求是否都能上溯到更高级别的文档？ 更高级别文档的需求是否已经在单元中体现？

 

编码、测试阶段的监理工作

编码监理

 

　　软件编码监理的主要目的是为了控制软件编码阶段的工程进度，监督软件编码的编程风格和质量，使得软件编码阶段的工作能可靠、高效地实现软件设计的目标，同时符合承建单位的软件过程规范的要求。

 

　　一、软件编码监理的目标

 

　　1） 监督承建单位定义和综合软件编码任务，并在生产软件的过程中始终如一地执行这些任务。

 

　　2） 监督使得软件工作产品彼此间保持一致性。

 

　　3） 监督使得软件编码的工作进度与计划保持一致性。

 

　　4） 监督使得软件编码的工作质量达到计划的要求。

 

　　二、软件编码监理的活动

 

　　1） 监督承建单位将合适的软件编码工程方法和工具集成到项目定义的软件过程中。

 

　　（1） 依据项目定义的软件过程对软件编码任务进行综合。

 

　　（2） 选择软件编码可用的方法和工具，并将选择专用工具或方法的理由写成文档。对备选方法和工具进行选择的依据是：

 

 机构标准软件过程²　　

 

 项目定义的软件过程²　　

 

 现有的技术基础²　　

 

 可得到的培训²　　

 

 合同需求²　　

 

 工具的能力²　　

 

 使用的方便性和提供的服务²　　

 

　　（3） 选择和使用适合于软件编码的配置管理模型。配置管理模型可能是：

 

 入库出库模型²　　

 

 组合模型²　　

 

 事务处理模型²　　

 

 更改处理模型²　　

 

　　（4） 将用于软件编码的软件产品和工具置于配置管理之下。

 

　　2） 监督承建单位依据项目定义的软件过程，对软件编码进行开发、维护、建立文档和验证，以实现软件需求和软件设计。

 

　　（1） 参与软件编码的人员评审软件需求和软件设计，以确保影响编码的各种问题得到识别和解决。

 

　　（2） 使用有效的编程方法编制软件代码。编程方法可能是：

 

 结构化编程²　　

 

 代码重用²　　

 

　　（3） 根据一个计划制定代码单元的开发顺序，该计划考虑诸如关键性、难度、集成和测试问题；合适时，还要考虑客户和最终用户的需要。

 

　　（4） 每个代码单元完成编码时，通过评审和单元测试。

 

　　（5） 将代码置于配置管理之下

 

　　（6） 每当软件需求或软件设计更改时，适当地更改代码。

 

　　3） 软件监理组跟踪和记录软件编码产品的功能性和质量。跟踪和记录的内容有：

 

　　（1） 跟踪、累计的软件编码产品缺陷的数量、类型和严重程度

 

　　（2） 软件编码产品工程活动的状态

 

　　（3） 有关问题严重性和持续时间的报告

 

　　（4） 用于分析每个更改建议的工作量及汇总统计量

 

　　（5） 按类别（如界面、安全性、系统配置、性能和可用性）被纳入软件基线的更改数量

 

　　三、软件编码监理的方法

 

　　1） 定期审查软件编码的工程活动和工程进度。

 

　　2） 根据实际需要对软件编码工程活动、工作进度进行审查。

 

　　3） 对软件编码工程活动和产品进行评审和（或）审核，并报告结果。这些评审和（或）审核至少应包括：

 

 软件编码工程任务的准备就绪和完成准则得到满足。²　　

 

 软件编码符合规定的标准和需求。²　　

 

 已完成所需的测试。²　　

 

 检测出的问题和缺陷已建立文档，并被跟踪和处理。²　　

 

 通过软件编码，对设计的跟踪得以实施。²　　

 

 在软件产品提交前，依据软件基线验证了用来管理和维护软件的文档。²　　

四、软件编码走查的监理

 

　　程序实际上也是一种供人阅读的文章，有一个文章的风格问题。应该使程序具有良好的风格。表现在：源程序文档化，数据说明的方法，语句结构和输入／输出方法。所以在进行编码监理时重点从一下几个方面把握：

 

　　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应用系统建设的特殊性，监理单位此阶段的重点并不在于对具体工作的检查、测试，而应该放在对承建单位的宏观监督方面。

 

　　目前国内信息ERP应用系统建设过程中，在此阶段常发生承建单位不按设计阶段制定的质量保证计划对编码工作进行约束检查，忽视开发过程的单元测试、集成测试工作等情况。上述情况会导致工程建设质量得不到保证，最终影响到工程的质量、进度与资金投入。

 

　　因此监理单位在此阶段主要监督承建单位严格按照工程设计阶段所制定的进度计划、质量保证计划、系统设计进行开发工作，检查承建单位是否按照设计中制定的规范与计划进行编码与测试。在此过程中，监理单位主要通过代码走查方式检查编码规范的执行情况，检查单元测试、集成测试和确认测试是否按计划进行并有测试与修改记录、集成测试是否按计划进行并有测试与修改记录。在此过程中需要检查测试计划是否得到落实、测试方案与规范是否合理、测试是否有详细记录并进行修改与回归测试，必要的情况下可由监理单位对测试结果进行抽检。

 

　　对于开发过程实现阶段的监理，还需要注意承建单位版本控制方面的工作是否能够正常进行，是否有专人进行版本的总体控制、开发人员是否严格按照质保人员的要求进行具体版本控制，必要的情况下需要对版本控制的工作进行抽检。但切忌由监理单位进行具体测试而取代开发方的内部测试，这种方法并不能保证工程的质量。

 

　　系统测试一般由专门委托的测试机构进行，需要对所有软硬件进行以功能为主的测试工作（必要情况下附加性能测试），需要对测试情况进行记录并进行错误的修改与回归测试，在测试完成后要根据测试全过程的情况编写正式的系统测试报告。

 

　　

 

　　在系统的实施阶段，承建单位在业主单位现有条件下进行系统的实施。承建单位制定详细的实施计划，进行现场跟踪，修改实现环境运行工程中发现的问题，对用户进行培训，制定详细的维护方案。

 

　　目前国内信息ERP应用系统建设过程中，在此阶段常发生承建单位实施计划不充分、现场跟踪不到位、错误修改及更新不落实、出现异常情况无法处理、培训工作不充分、缺少应有的维护方案等情况。虽然在前几个阶段的工作可能已基本完成工程建设的主体工作，但此环节工作不到位仍然可能造成工程建设出现大的问题。

 

　　因此，在此过程监理单位需要对承建单位在现场实施的情况及培训情况进行监督，检查承建单位是否有详细的试运行计划、是否有详细的现场跟踪检验机制、是否有稳妥可行的错误修改及更新方案、是否有详细的异常情况处理办法、是否有详细的培训计划、是否有详细的培训方案、是否有完善的正式运行维护方案。

 

　　实施阶段的监理的重点是：协助业主方和承建单位处理系统实施期间出现的各项问题，并予以记录；对于一些重复出现的问题，在验收测试时给予必要的关注，督促承建单位必要的解决措施；监督检查承建单位试运行阶段的培训工作。

 

　　技术培训监理的重点是：监督承建单位按照合同和业主的要求制定培训计划；审核培训计划的可操作性，要求在培训计划中明确：培训对象、培训教材、培训时间、培训方式和培训师资；监督技术培训计划的实施，对培训教材和师资进行评估，将培训计划执行情况和效果通报给业主

 

 

 

监理内容

　　

　　对于ERP信息系统工程监理的内容，信息产业部正式颁布的《信息系统工程监理暂行规定》第九条规定是对信息系统工程的质量、进度和投资进行监督，对项目合同和文档资料进行管理，协调有关单位间的工作关系。根据应用系统工程的实际状况，可以概括为“四控制”（即质量控制、进度控制、投资控制和变更控制）、“三管理”（合同管理、安全管理和信息管理）和“一协调”。

　　

　　一、质量控制

　　

　　质量控制要贯穿在项目建设从可行性研究、设计、建设准备、开发、实施、竣工、启用及用后维护的全过程。主要包括组织设计方案评比，进行设计方案磋商及图纸审核，控制设计变更；在实施前通过承建单位资质审查等；在实施中通过多种控制手段检查监督标准、规范的贯彻；以及通过阶段验收和竣工验收把好质量关等。

　　

　　二、进度控制

　　

　　进度控制首先要在建设前期通过周密分析研究确定合理的工期目标，并在实施前将工期要求纳入承建合同；在软件开发、实施阶段通过运筹学、网络计划技术等科学手段，审查、修改实施组织设计和进度计划，做好协调与监督，排除干扰，使单项工程及其分阶段目标工期逐步实现，最终保证项目建设总工期的实现。

　　

　　三、投资控制

　　

　　投资控制的任务，主要是在建设前期进行可行性研究，协助业主单位正确地进行投资决策，在设计阶段对设计方案、设计标准、总预算进行审查；在建设准备阶段协助确定标底和合同造价；在实施阶段审核设计变更，核实已完成的工程量，进行工程进度款签证和索赔控制；在工程竣工阶段审核工程结算。

　　

　　四、变更控制

　　

　　变更控制主要内容是对接受应用软件系统建设过程中的变更申请，收集变更信息资料，对发生的所有变更情况按照一定的程序进行处理，并对变更的内容、方式、范围、影响进行评估和控制。

　　

　　五、合同管理

　　

　　合同管理是进行投资控制、工期控制和质量控制的手段。因为合同是监理单位站在公正立场采取各种控制、协调与监督措施，履行纠纷调解职责的依据，也是实施三大目标控制的出发点和归宿。

　　

　　六、安全管理

　　

　　信息系统安全管理的作用是保证业主在ERP信息系统工程项目建设过程中，保证信息系统的安全在可用性、保密性、完整性与ERP信息系统工程的可维护性技术环节上没有冲突；在投资控制的前提下，确保信息系统安全设计上没有漏洞；督促业主的ERP信息系统工程应用人员在安全管理制度和安全规范下严格执行安全操作和管理，建立安全意识；监督承建单位按照技术标准和建设方案实施，检查承建单位是否存在设计过程中的非安全隐患行为或现象等。

　　

　　七、信息管理

　　

　　确保项目信息管理工作规范化，保证项目信息的准确性、完整性和可用性，确保项目信息交流、信息沟通渠道畅通，规范信息组织及信息管理，为项目实施管理及决策提供信息依据。

　　

　　八、协调

　　

　　协调贯穿在整个ERP信息系统工程从设计到实施再到验收的全过程。主要采用现场和会议方式进行协调。

　　

　　总之，四控三管一协调，构成了应用信息系统监理工作的主要内容。为完满地完成监理基本任务，监理单位首先要协助业主单位确定合理、优化、经济的三大目标，同时要充分估计项目实施过程中可能遇到的风险，进行细致的风险分析与估计，研究防止和排除干扰的措施以及风险补救对策。使三大目标及其实现过程建立在合理水平和科学预测基础之上。其次要将既定目标准确、完整、具体地体现在合同条款中，绝不能有含糊、笼统和有漏洞的表述。最后才是在信息工程建设实施中进行主动的、不间断的、动态的跟踪和纠偏管理。针对ERP应用系统监理的特点，在后面的章节中我们重点讲述质量控制、进度控制等方面的内容。