IPMP认证ERP监理方法系列.docx

IPMP认证ERP监理方法系列ERP监理的目标ERP监理工作应力求达到以下主要目标：对软件开发单位、软件实施单位等系统承建单位的行为进行监控，促使开发行为符合国家法律法规、有关政策和相关技术标准，制止开发行为的随意性和盲目性，促使开发进度、质量按计划(合同)实现，力求开发行为合法、科学、合理、经济;促进用户与软件开发单位、软件实施单位和系统承建单位之间的有效沟通，使软件开发单位、软件实施单位和系统承建单位能够全面准确了解用户的实际需求，同时用户能及时了解项目的进展情况;促使软件开发单位、软件实施单位等承建单位为项目运行的全过程建立一套明确、合理、可行的计划或规程，/考试大/收集/并利用与之相应的审核、监理机制和手段对其执行过程进行有效控制;促使系统的关键技术指标在项目实施过程中处于受控状态，及早预测和发现可能影响施工计划的各种因素，及时纠正可能影响系统功能与性能的缺陷。一般来说，监理项目部的目标就是通过监理工程师谨慎而勤奋的工作，力求在项目的成本、进度和质量目标内实现建设项目。由于工程建设监理具有委托性，所以监理单位可以根据业主单位的意愿并结合自身的实际情况来协商确定监理服务范围和业务内容。既可承担全过程监理，也可以承担阶段性监理，甚至还可以只承担某专项监理服务工作。但是在ERP应用系统建设中，最好采取全过程监理方式。监理要达到的目的是“力求”实现项目目标。因此，监理单位和监理工程师“将不是，也不可能成为承建单位的工程承保人或保证人”。谁设计谁负责，谁施工谁负责，谁供应材料和设备谁负责，而作为工程承包合同“甲、乙方”之外的“第三方”的监理单位和监理工程师则没有承担他们双方义务的责任。监理是一种技术服务性质的活动。/考试大/收集/它不直接进行设计，不直接进行开发，不直接进行实施，不直接进行软硬件的采购、供应工作。因此，它不承担设计、开发、实施、软硬件选型采购方面的直接责任。所以，监理单位只承担整个建设项目的监理责任，也就是在监理合同中确定的职权范围内的责任。在实现ERP应用系统建设项目的过程中，外部环境潜伏着各种风险，会带来各种干扰。而这些干扰和风险并非监理工程师完全能够驾驭的，他们只能力争减少或避免这些干扰和风险造成的影响。所以，对于提供监理服务的监理单位来说，他不承担其专业以外的风险责任。他虽不能保证项目一定在预定目标内实现，但在政府有关部门和监理行业组织的规范下，出于职业道德的良知，基于他的社会信誉和经济方面的考虑他们会竭尽全力为在预定的投资、进度和质量目标范围内实现项目而努力工作。监理内容对于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.特殊的考虑.参考书目.附录三、需求说明书评审内容作为需求分析阶段工作的复查手段，在需求分析的最后一步，/考试大/收集/应该对功能的正确性、完整性和清晰性，以及其它需求给予评价。评审的主要内容是：系统定义的目标是否与用户的要求一致;系统需求分析阶段提供的文档资料是否齐全;文档中的所有描述是否完整、清晰、准确反映用户要求;与所有其它系统成分的重要接口是否都已经描述;被开发项目的数据流与数据结构是否足够，确定;所有图表是否清楚，在不补充说明时能否理解;主要功能是否已包括在规定的软件范围之内，是否都已充分说明;软件的行为和它必须处理的信息、必须完成的功能是否一致;设计的约束条件或限制条件是否符合实际;是否考虑了开发的技术风险;是否考虑过软件需求的其它方案;是否考虑过将来可能会提出的软件需求;是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;有没有遗漏，重复或不一致的地方;用户是否审查了初步的用户手册或原型;项目开发计划中的估算是否受到了影响。四、需求说明书评审检查检查项Y/TBD/N/NA清晰性系统的目标是否已定义？是否对关键术语和缩略语进行定义和描述？所使用的术语是否和用户/客户使用的一致？需求的描述是否清晰，不含糊？是否有对整套系统进行功能概述？是否已详细说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？如果有会影响实施的假设情况，是否已经声明？是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？完整性是否列出了系统所必须的依赖、假设以及约束？是否对每个提交物或阶段实施都进行了需求说明？需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。依从性该文档是否遵守了该项目的文档编写标准？一致性需求说明是否存在直接相互矛盾的条目？本需求说明书是否与相关需求素材一致？可行性所描述的所有功能是否必要并充分地满足了客户/系统目标？需求说明书的描述的详细程度是否足以进行详细的设计？已知的限制（局限）是否已经详细说明？是否已确定每个需求的优先级别？可管理性是否将需求分别陈述，因此它们是独立的并且是可检查的？是否所有需求都可以回溯到相应的需求素材，反之亦然？是否已详细说明需求变更的过程？需求说明书评审报告在需求说明书评审结束后，监理单位应将评审意见以专题监理报告形式提交业主单位。编码监理软件编码监理的主要目的是为了控制软件编码阶段的工程进度，监督软件编码的编程风格和质量，使得软件编码阶段的工作能可靠、高效地实现软件设计的目标，同时符合承建单位的软件过程规范的要求。一、软件编码监理的目标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)监督承建单位依据项目定义的软件过程，对软件测试进行开发、维护、建立文