信息系统软件工程监理控制点及监理方法.doc

《信息系统软件工程监理控制点及监理方法.doc》由会员分享，可在线阅读，更多相关《信息系统软件工程监理控制点及监理方法.doc（35页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、信息系统软件工程监理控制点及监理方法1、监理控制目标应用系统建设监理工作应力求达到以下主要目标: (1)对软件开发单位、软件实施单位和系统承建单位的行为进行监控，促使开发行为符合国家法律法规、有关政策和相关技术标准，制止开发行为的随意性和盲目性，促使开发进度、质量按计划(合同)实现，力求开发行为合法、科学、合理又经济。 (2)促进用户与软件开发单位、软件实施单位和系统承建单位的有效沟通，使软件开发单位、软件实施单位和系统承建单位能够全面准确了解用户的实际需求，同时用户能及时了解项目的进展情况。 (3)促使软件开发单位、软件实施单位和承建单位为项目运行的全过程建立一套明确、合理、可行的计划或者规

2、程，并利用与之相应的审核、监理机制和手段对其执行过程进行有效控制。(4)促使系统的关键技术指标在项目实施过程中处于受控状态，及早预测和发现可能影响施工计划的各种因素，及时纠正可能影响系统功能与性能的缺陷。2、监理控制要点2.1准备阶段的监理2.1.1立项阶段的监理工作 立项阶段最终要做的工作就是编制可行性研究报告，目的是:说明项目的实现在技术、经济和社会条件方面的可行性;评述为了合理地达到开发目标而可能选择的各种方案;说明并论证所选定的方案。 从以下四个方面的进行可研监理设审核： (1)经济可行性:进行成本/效益分析。从经济角度判断系统开发是否“合算”。 (2)技术可行性:进行技术风险评价。从

3、建设基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。 (3)法律可行性:确定系统开发可能导致的任何侵权、妨碍和责任。(4)方案的选择:评价系统或产品开发的几个可能的候选方案。最后给出结论意见。2.1.2确定招标方式了解业主需求，协助业主确定招标方式。根据有关国际组织协议或国内法规以及信息服务项目招标的特点，在实践中确定信息服务招标方式的基本原则是: (1)如果可以拟定详细的条件，而且服务的性质允许采用招标方式，可采用公开或邀请招标的方式进行。 (2)如果不能确切拟定或最后拟定条件，或采购的服务相当复杂，可采用征求建议书、邀请建议书、两阶段招标、竞争性谈判、设计竞赛等

4、方式。 (3)与其他形式的服务相比，聘用专家提供咨询、研究、监理等服务更侧重对专家知识、技能、经验方面的考虑，故有独特的方式。在招标方式确定后，协助业主制定招标文件和评标标准，并对招标过程的组织提出建议。2.1.3审查承建单位资质采用公开招标方式时，协助业主对投标单位的资质进行审查，采用邀标或其他招标方式时，协助业主单位对候选承建单位进行资质审查。协助业主单位对承建单位资质进行审查，1、承建单位的软件企业认定情况、系统集成资质情况等，2、考察承建单位在以往的开发过程中是否从事过与本项目相关或相似的开发工作，帮助业主单位选择合格的承建单位，减小项目实施的风险。2.1.4审查承建单位质量管理体系软

5、件企业所遵循的质量管理体系主要有两种，一种是软件能力成熟度模型(SW-CMM )，一种是ISO质量管理体系。2.1.5监督招标过程1、开标过程监理 开标应当在招标文件确定的提交投标文件截止时间的同一时间公开进行;开标地点应当为招标文件中预先确定的地点。 开标时，要检查投标文件的密封情况，经确认无误后，由工作人员当众拆封，宣读投标人名称、投标价格和投标文件的其他主要内容。 开标过程应当记录，并存档备查。2、评标过程监理， 评标委员会由招标人的代表和有关技术、经济等方面的专家组成，成员人数为五人以上单数，其中技术、经济等方面的专家不得少于成员总数的三分之二。 专家应当从事相关领域工作满八年并具有高

6、级职称或者具有同等专业水平，由招标人从国务院有关部门或者省、自治区、直辖市人民政府有关部门提供的专家名册或者招标代理机构的专家库内的相关专业的专家名单中确定;一般招标项目可以采取随机抽取方式，特殊招标项目可以由招标人直接确定。 确认没有与投标人有利害关系的人进入相关项目的评标委员会。 评标委员会成员的名单在中标结果确定前应当保密。 确认没有任何单位和个人非法干预、影响评标的过程和结果。 评标委员会应当按照招标文件确定的评标标准和方法，对投标文件进行评审和比较;设有标底的，应当参考标底。评标委员会完成评标后，应当向招标人提出书面评标报告，并推荐合格的中标候选人。 招标人根据评标委员会提出的书面评

7、标报告和推荐的中标候选人确定中标人。招标人也可以授权评标委员会直接确定中标人。 在确定中标人前，“招标人不得与投标人就投标价格、投标方案等实质性内容进行谈判。 评标委员会成员和参与评标的有关工作人员不得透露对投标文件的评审和比较、中标候选人的推荐情况以及与评标有关的其他情况。3、决标过程监理 中标通知书对招标人和中标人具有法律效力。中标通知书发出后，招标人改变中标结果的，或者中标人放弃中标项目的，应当依法承担法律责任。招标人和中标人应当自中标通知书发出之日起三十日内，按照招标文件和中标人的投标文件订立书面合同。招标人和中标人不得再行订立背离合同实质性内容的其他协议。 依法必须进行招标的项目，招

8、标人应当自确定中标人之日起十五日内，向有关行政监督部门提交招标投标情况的书面报告。 中标人应当按照合同约定履行义务，完成中标项目。中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。 中标人按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件，并不得再次分包。中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。2.1.6合同签订管理监理工程师应对工程承建、共同承担风险的合同条款、法律条款分别进行仔细的分析解释。同时也要对合同条款的更换、延期说明、投资变化等事件进行仔细分析。合同分析和工程检查等

9、工作要同其联系起来。合同分析是解释双方合同责任的根据。监理工程师在业主与承建单位订立合同的过程中要按条款逐条分析，如果发现有对业主产生风险较大的条款，要增加相应的抵御条款。要详细分析哪些条款与业主有关、与承建单位有关、与工程检查有关、与工期有关等，分门别类分析各自责任和相互联系的关联，做到一清二楚，心中有数。合同评审过程中的考查以下内容，确定以下内容在合同中进行了明确定义; (1)定义/使用的术语: (2)保密约定;， (3)知识产权约定: (4)双方义务; (5)合同价款及付款方式; (6)各阶段工程成果及交付期限，应选取里程碑式的工程成果交付的期限，并在一定程度上把成果和付款计划联系起来;

10、 (7)验收标准和方式/工程的质量要求，应准确细致地描述工程的整体质量和各部分质量，必要时可以用明确的技术指标进行限定; (8)用户培训需求;(9)维护期约定，包括维护期长度、维护响应时间、维护方式和维护法用等;(10)违约责任;(11)期限和终止;(12)不可抗力;(13)变更，包括资金、需求、期限、合向等变更，对变更的范围进行约定，并明确每一种变更以何种方式何种程序处理;对范围外的变更，可注明另行协商并再补签合同;(14)其他约定，如适用法律、争议解决和双方的其他协作条件等。将监理意见以合同评审专题报告形式提交业主。3、分析设计阶段监理3.1软件项目计划监理的目标(1)监督承建单位形成软件

11、规模估计文档，以供计划和跟踪软件项目使用。(2)监督承建单位制定软件项目的活动和约定，并形成文档。(3)监督和控制软件项目计划的产品和活动与软件的需求规格说明一致。3.2软件项目计划监理的主要活动 (1)确保软件承建单位在项目软件过程规范约定的基础上制定软件项目计划。 (2)监督承建单位为实施软件工程和管理软件项目制定合理的软件项目计划，包括进行软件规模估计和软件风险分析，建立软件项目组织，确定软件项目生命周期，进行软件项目策划，确定必要的约定。 (3)监督承建单位依据书面规程制定项目的软件项目计划，确认计划内容是否满足标准、规范及合同要求。 (4)审查承建单位编写的项目计划文档，软件项目计划

12、包括:软件项目的用途、范围、目标和对象，软件开发计划，软件配置管理，软件质量保证，软件框架设计，问题跟踪与排除方法，软件度量。 (5)审查承建单位标明、建立和保持对软件项目的控制所必需的软件工作产品。 (6)审查承建单位依据书面规程估计软件工作产品规模，估计软件项目的工作量和成本，估计项目的关键计算机资源。 (7)监督承建单位依据书面规程制定项目的软件进度计划，分析承建单位制定项目的软件工程设备和支持工具计划的合理性、可行性，分析软件进度计划的合理性。 (8)管理和控制软件计划数据，审查软件项目计划的活动情况。(9)确保软件项自计划通过正式的评审，在评审后得到技术修改和批准，给出是否符合要求的

13、结论，确定其能否作为软件开发的前提和依据，作为应用软件系统建设进度控制的依据。3.3软件质量管理体系监理1、监督应用软件系统建设承建单位根据项目合同和业主应用软件系统需求，制定项目软件工程和管理活动，结合成为密切相关、定义完整的项目软件过程; 2、评估项目软件过程的技术合理性，包括是否符合标准和规范，是否符合项目合同和业主技术要求;3、项目软件过程文档化，并得到批准;监督和控制承建单位的项目软件过程的状杰，促使承建单位支持和实施项目软件过程，提高软件项目实施的计划性，减少软件项目实施的风险;4、监督应用软件系统建设承建单位在软件开发过程中按照项目软件过程的规范实施，跟踪、记录和审查软件管理过程

14、活动。3.4软件质量保证监理的主要内容 1、确保项目遵循书面的承建单位管理策略来实施软件质量保证，承建单位成立了软件质量保证活动的组织; 2、控制承建单位依据书面规程，为软件项目制定软件质量保证计划，保障软件质量保证计划符合项目软件过程的规范要求; 3、参加承建单位的软件质量保证组按照软件质量保证计划进行活动; 4、参加承建单位的软件质量保证组评审软件工程活动，验证软件工程活动与软件项目计划的一致性; 5、参加承建单位软件质量保证组审核指定的软件产品，依据指定的软件标准、规程和合同需求对可交付的软件产品进行评价，验证软件产品与软件项目计划的一致性; 6、控制承建单位依据书面规程，归档和处理软件

15、活动和软件工作产品中的偏差，管理和控制不一致性问题的文档;7、软件监理人员和业主的软件质量保证人员定期对软件质量保证组的活动和结果进行评审;8、跟踪和记录软件质量保证活动的情况，审查软件质量保证活动，并给出软件质量保证监理报告。3.5软件配置管理监理的主要活动 1、确保应用软件系统建设承建单位的配置管理组织和环境按照软件项目计划的要求成立并配备。 2、控制承建单位依据书面规程，为应用软件系统建设项目制定软件配置管理计划。 3、监督承建单位使用审批通过的、文档化的软件配置管理计划作为实施软件配置管理活动的基础，该计划包括:要执行的活动、活动的进度安排、指定的职责和所需的资源;监督承建单位标识将置

16、于配置管理下的软件工作产品，工作产品包括与过程相关的计划、标准或规程、软件需求、软件设计、软件代码单元、软件测试规程、为软件测试活动建立的软件系统、软件系统产品和编译程序。 4、控制承建单位依据书面规程，对所有配置项/单元的更改请求和问题报告实施初始准备、记录、评审、批准和跟踪。 5、监督承建单位依据书面规程，控制对基线的更改。监督承建单位依据书面规程，由软件基线库生成软件产品并对其发布进行控制。监督承建单位依据书面规程，记录配置项/单元的状态。 6、控制承建单位编制软件配置管理报告，证明软件配置管理活动和软件基线库的内容，并提供给业主。 7、监督承建单位依据书面规程，进行软件基线库审核。进行

17、软件配置管理活动状态的跟踪和记录。8、定期审查软件配置管理活动和软件配置管理基线，以验证它们与文档定义的一致性。9、审核软件配置管理活动及其工作产品，并给出软件配置管理监理报告。3.6需求说明书评审内容 作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审的主要内容是: 1、系统定义的目标是否与用户的要求一致; 2、系统需求分析阶段提供的文档资料是否齐全; 3、文档中的所有描述是否完整、清晰、准确反映用户要求: 4、与所有其他系统成分的重要接口是否都已经描述: 5、被开发项目的数据流与数据结构是否足够、确定; 6、所有图表是否清楚

18、，在不补充说明时能否理解; 7、主要功能是否己包括在规定的软件范围之内，是否都已充分说明; 8、软件的行为和它必须处理的信息、必须完成的功能是否一致; 9、设计的约束条件或限制条件是否符合实际; 10、是否考虑了开发的技术风险; 11、是否考虑过软件需求的其他方案_; 12、是否考虑过将来可能会提出的软件需求; 13、是否详细制定了检验标准，它们能否对系统定义是否成功进行确认; 14、有没有遗漏、重复或不一致的地方; 15、用户是否审查了初步的用户手册或原型; 16、项目开发计划中的估算是否受到了影响。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责

19、人的结论意见及签字。除承建单位分析员之外，业主单位人员和监理单位都应当参加评审工作。需求说明书要经过严格评审，一般，评审的结果都包含了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。3.7软件分包合同监理的方法 方法1:定期审查软件分包合同的管理活动。实施定期审查的主要目的是适当地、及时地掌握软件分包合同管理的软件过程活动。在满足业主单位需求的前提下，只要有适当的机制来报告异常情况，审查的时间间隔就尽可能长些。 方法2:根据实际需要随时跟踪和审查软件分包合同的管理活动。方法3:评审和(或)审核软件分包合同的管理活动及其产品，并报告结果。这些评审和(或)审核至少应验证: 1、选择分承建

20、单位的活动。 2、管理软件分包合同的活动。 3、协调主承建单位和分承建单位配置管理的活动。 4、与分承建单位按计划评审的实施情况。 5、确认分包合同达到关键里程碑或阶段完成时的评审情况。6、对分承建单位软件产品的验收过程。3.8概要设计说明书评审3.8.1评审内容 1、可追溯性:即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有己确定的软件需求，软件每一成分是否可追溯到某一项需求。 2、接口:即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。 3、风险:即确认该软件设计在现有技术条件下和

21、预算范围内是否能按时实现。 4、实用性:即确认该软件设计对于需求的解决方案是否实用。 5、技术清晰度:即确认该软件设计是否以一种易于翻译成代码的形式表达。 6、可维护性:从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。 7、质量:即确认该软件设计是否表现出良好的质量特征。 8、各种选择方案:看是否考虑过其他方案，比较各种选择方案的标准是什么。 9、限制:评估对该软件的限制是否现实，是否与需求一致。 10、其他具体问题:对于文档、可测试性、设计过程等进行评估。3.8.2衡量设计的技术标准 1、设计出来的结构应是分层结构，从而建立软件成分之间的控制。 2、设计应当模块化，从逻辑上将软

22、件划分为完成特定功能或子功能的构件。3、设计应当既包含数据抽象，也包含过程抽象。 4、设计应当建立具有独立功能特征的模块。 5、设计应当建立能够降低模块与外部环境之间复杂连接的接口。 6、设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。软件设计过程根据基本的设计原则，使用系统化的方法和完全的设计评审来建立良好的设计。3.8.3设计说明书检查表序号检查项是/不确定/否/不适用清晰性1是否所设计的架构，包括数据流、控制流和接口被清楚地表达了？2是否所有的假设、约束、策略及依赖都被记录在本文档了？3是否定义了总体设计目标？完整性4是否所有以前的TBD（待确定条目）都已经解决了？5是否设

23、计已经可以支持本文档中遗留的TBD有可能带来的变更？6是否所有的TBD的影响都已经被评估了？7是否仍存在可能不可行的设计部分？8是否已记录设计时的权衡考虑？该文件是否包括了权衡选择的标准和不选择其他方案的原因？依从性9是否遵守了项目的文档编写标准？一致性10数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？11该设计是否反映了实际操作环境（硬件、软件、支持软件）？可行性12从进度、预算和技术角度上看该设计是否可行？13是否存在错误的、缺少的或不完整的逻辑？数据使用14所有符合数据元素、参数以及对象的概念是否都已文档化？15是否还有任何需要的但还没有定义的数据结构，反之亦然？16

24、是否已描述最低级别数据元素？是否已详细说明取值范围？功能性17是否对每一下级模块进行了概要算法说明？18所选择的设计和算法能否满足所有的需求？接口19操作界面的设计是否有为用户考虑（入词汇、使用信息和进入的简易）20是否已描述界面的功能特性？21界面将有利于解决问题吗？22是否所有界面都互相一致，与其他模块一致，以及和更高级别文档中的需求一致？23是否所有的界面都提供了所需求的信息？24是否已说明内部各界面之间的关系？25界面的数量和复杂程度是否已减少到最小？可维护性26该设计是否是模块化的？27这些模块是否具有高内聚度和低耦合度？28是否已经对继承设计、代码或先前选择工具的使用进行了详细说明

25、？性能29主要性能参数是否已被详细说明（如实时、速度要求、磁盘输入/输出接口等）可靠性30该设计能够提供错误监测和恢复？31是否矣考虑非正常情况？32是否所有错误情况都被完整和准确的说明？33该设计是否满足该系统进行集成时所遵守的约定？易测性34是否能够对该系统进行测试、演示、分析、或检查来说明它是满足需求的？35该套系统是否能用增量型的方法来测试和集成？可追溯型36是否各部分的设计都能追溯到需求说明书的需求？37是否所有的设计决策都能追溯到原来确定的权衡因素？38所继承设计的已知风险是否已确定和分析？3.8.4详细设计说明书评审、测试计划评审序号检查项是/不确定/否/不适用所有单元或过程的目

26、的是否都已文档化？包括了数据流、控制流和接口的单元设计是否已清晰的说明？完整性是否已定义和初始化所有的变量、指针和常量？是否已描述单元的全部功能？是否已详细说明实现该单元的关键算法？是否已列出该单元的调用？依从性数据元素的命名和使用在整个单元和单元接口之间是否一致？所有接口的设计是否互相一致并且各更高级别文档一致？正确性是否处理所有条件（0,=0,0,switch/case）?是否存在处理“case not found”的条件？是否正确地规定了分支（逻辑没有颠倒）？数据使用是否所有声明的数据都被详细说明？事都所有该单元的数据结构都被详细说明？是否所有修改共享数据（或文件）的程序都考虑到了其他程

27、序对该共享数据（或文件）的存取权限？是否所有逻辑单元、时间标志和同步标志都被定义和初始化？接口接口参数在数量、类型和顺序上是否匹配？是否所有的输入和输出都被正确定义和检查？是否传递参数序列都被清晰描述？是否所有参数和控制标志由已描述的单元传递或返回？是否详细说明了参数的度量单位、取值范围、正确度和精度？共享数据区域及其存取规定的映射是否一致？可维护性单元是否具有高内聚度和低耦合度？性能是否该单元的所有约束都被详细说明？可靠性初始化是否使用到默认值，默认值是否正确？3.8.5软件编码规范评审3.8.5.1源程序文档化 1、符号名的命名 符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名

28、、数据区名以及缓冲区名等等。这些名称应能反映它所代表的实际东西，应有一定的实际意义。例如，表示次数的量用Times，表示总量的量用Total，表示平均值的量用Average，表示和的量用Sum等等。 名称不是越长越好，应当选择精炼的、意义明确的名称。必要时可使用缩写名称，但这时要注意缩写规则要一致，并且要给每一个名称加注释。同时，在一个程序中，一个变量只应用于一种用途。 2、程序的注释 夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中一注释行的数量占到整个源程序的1/31/2，甚至更多。注释分为序言性注释和功能性注释。 序言性注释通常置于每

29、个程序模块的开头部分，它应当给出程序的整体说明，对子理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括:程序标题;有关本模块功能和目的的说明;主要算法;接口说明(包括调用形式、参数描述、子程序清单);有关数据描述(重要的变量及其用途、约束或限制条件，以及其他有关信息);模块位置(在哪一个源文件中，或隶属十哪一个软件包);开发简历(模块设计者、复审者、复审日期、修改日期及有关说明)等。 功能性注释功能性注释嵌在源程序体中，用于描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点:描述一段程序，

30、而不是每一个语句;用缩进和空行，使程序与注释容易区别;注释要正确。 3、标准的书写格式视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少发生编码的错误;自然的程序段之间可用空行隔开;移行也叫做向右缩格，它是指程序中的各行不必都在左端对齐，不必都从第一格起排列，这样做可以使程序分清层次关系。对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行，使程序的逻辑结构更加清晰。3.8.5.2数据说明 在设计阶段己经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。 1、数据说明的次序应当规范化

31、数据说明次序规范化，使数据属性容易查找，也有利于测试、排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。 2、说明语句中变量安排有序化 当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。 3、使用注释说明复杂数据结构 如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。 4、语句结构 在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。3.8.5.3输

32、入和输出 1、对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性。 2、检查输入项的各种重要组合的合理性，必要时报告输入状态信息。 3、使得输入的步骤和操作尽可能简单，并保持简单的输入格式。 4、输入数据时，_应允许使用自由格式输入。 5、应允许默认值。 6、输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目。 7、在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息。 8、当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句的要求的一致性。

33、9、给所有的输出加注解，并设计输出报表格式。4、实施阶段监理4.1软件编码监理4.2软件编码监理的目标 1、监督承建单位定义和综合软件编码任务，并在生产软件的过程中始终如一地执行这些任务。 2、监督使得软件工作产品彼此间保持一致性。 3、监督使得软件编码的工作进度与计划保持一致性。 4、监督使得软件编码的工作质量达到计划的要求。4.3软件编码监理的活动 1、监督承建单位将合适的软件编码工程方法和工具集成到项目定义的软件过程中 (1)依据项目定义的软件过程对软件编码任务进行综合。 (2)选择软件编码可用的方法和工具，并将选择专用工具或方法的理由写成文档。对备选方法和工具进行选择的依据是:l 机构

34、标准软件过程l 项目定义的软件过程l 现有的技术基础l 可得到的培训l 合同需求l 工具的能力l 使用的方便性和提供的服务 (3)选择和使用适合于软件编码的配置管理模型。配置管理模型可能是:l 入库出库模型l 组合模型l 事务处理模型l 更改处理模型 (4)将用于软件编码的软件产品和工具置于配置管理之下。 2、监督承建单位依据项目定义的软件过程，对软件编码进行开发、维护、建立文档和验证，以实现软件需求和软件设计 (1)参与软件编码的人员评审软件需求和软件设计，以确保影响编码的各种问题得到识别和解决。 (2)使用有效的编程方法编制软件代码。编程方法可能是:l 结构化编程l 代码重用 (3)根据一

35、个计划制定代码单元的开发顺序，该计划考虑诸如关键性、难度、集成和测试问题;合适时，还要考虑客户和最终用户的需要。 (4)每个代码单元完成编码时，通过评审和单元测试。 (5)将代码置于配置管理之下。 (6)每当软件需求或软件设计更改时，适当地更改代码。 3、软件监理组跟踪和记录软件编码产品的功能性和质量 跟踪和记录的内容有: (1)跟踪、累计的软件编码产品缺陷的数量、类型和严重程度。 (2)软件编码产品工程活动的状态。 (3)有关问题严重性和持续时间的报告。 (4)用于分析每个更改建议的工作量及汇总统计量。 (5)按类别(如界面、安全性、系统配置、性能和可用性)被纳入软件基线的更改数量。4.4软

36、件编码监理的方法1、定期审查软件编码的工程活动和工程进度。 2、根据实际需要对软件编码工程活动、工作进度进行审查。 3、对软件编码工程活动和产品进行评审和(或)审核，并报告结果。这些评审和(或)审核至少应包括:l 软件编码工程任务的准备就绪和完成准则得到满足。l 软件编码符合规定的标准和需求。l 已完成所需的测试。l 检测出的问题和缺陷已建立文档，并被跟踪和处理。l 通过软件编码，对设计的跟踪得以实施。l 在软件产品提交前，依据软件基线验证了用来管理和维护软件的文档。4.5软件测试监理4.5.1软件测试监理的目标 1、监督和控制承建单位的软件测试过程，确保软件测试按照承建单位的测试文档规范和业

37、主的软件要求实施; 2、软件测试反映出、记录着软件产品的真实情况; 3、软件测试的各个阶段按计划步骤实施; 4、对于软件测试反映出的问题能有效地按回归测试规范进行处理; 5、最后得到符合软件任务书(或合同)要求的软件产品集; 6、软件测试的进度与计划保持一致性。4.5.2软件测试监理的活动 1、监督承建单位将合适的软件测试工程方法和工具集成到项目定义的软件过程中 (1)依据项目定义的软件过程对软件测试任务进行综合。 (2)选择软件测试可用的方法和工具，并将选择专用工具或方法的理由写成文档。对备选方法和工具进行选择的依据是:l 机构标准软件过程l 项目定义的软件过程l 现有的技术基础l 可得到的

38、培训l 合同需求l 工具的能力l 使用的方便性和提供的服务 (3)选择和使用适合于软件测试的配置管理模型。配置管理模型可能是:l 入库出库模型l 组合模型l 事务处理模型l 更改处理模型 (4)将用于测试软件产品的工具置于配置管理之下。 2、监督承建单位依据项目定义的软件过程，对软件测试进行开发、维护、建立文档和验证，以满足软件测试计划要求 软件测试有静态测试、单元测试、集成测试、确认测试和系统测试组成。 (1)可与客户和最终用户一同参与开发和评审测试准则。 (2)使用有效方法测试软件。 (3)基于下列因素确定测试的充分性:l 测试试级别。测试级别有单元测试、集成测试、确认测试和系统测试。l

39、选择的测试策略。测试策略有功能测试(黑盒测试)、结构测试(白盒测试)和 统计测试。l 欲达到的测试覆盖。测试覆盖方法有语句覆盖、路径覆盖、分支覆盖和运行剖 面覆盖。 (4)对每个级别的软件测试，建立和使用测试准备就绪准则。确定测试准备就绪准则包括:l 软件单元在进入集成测试前己成功地完成了代码的静态测试和单元测试l 在进入系统测试前，软件己成功地完成了确认测试l 在软件进入系统测试前，已对测试准备就绪进行评审 (5)每当被测试软件或软件环境发生变化时，则在各有关的测试级别上适当进行回归测试。 (6)对于测试计划、测试规程和测试用例，准备使用前通过评审。 (7)管理和控制测试计划、测试说明、测试

40、规程和测试用例。 (8)每当软件需求、软件设计或被测试代码更改时，适当地更改测试计划、测试说明、测试规程和测试用例。3、监督承建单位依据项目定义的软件过程、计划和实施软件的确认测试 (1)基于软件开发计划，制定确认测试计划并写成文档。 (2)负责软件需求、软件设计、系统测试及验收测试的人员，评审确认测试用例、 测试说明和测试规程。 (3)依据指定的软件需求文档和软件设计文档的指定版本，进行软件确认测试。 4、计划和实施软件系统测试，实施系统测试以保证软件满足软件需求 (1)尽早分配测试软件的资源，以做好充分的测试准备。所需的测试准备活动包括:l 准备测试文档l 准备测试资源l 开发测试程序l

41、开发模拟程序 (2)编制系统测试的计划文档。如果合适，该测试计划由业主单位进行评审和认可。此测试计划包括:l 全面测试和验证的方法l 测试职责l 测试工具、测试设备和测试支持需求l 验收准则 (3)由一个独立于软件开发者的测试小组来计划和准备所需的测试用例和测试规程。 (4)在测试开始前，对测试用例建立文档，并经评审和认可。 (5)依据已纳入基线的软件及其软件任务书(或合同)和软件需求文档，实施软件测试。 (6)对测试中发现的问题建立文档，并跟踪到关闭。 (7)建立测试结果文档，并以此作为判断软件是否满足需求的基础。 (8)管理和控制测试结果。 5、软件监理组跟踪和记录软件测试的结果 跟踪和记

42、录的内容有: (1)跟踪、累计的软件产品缺陷的数量、类型和严重程度。 (2)软件测试工程活动的状态。 (3)有关问题严重性和持续时间的报告。 (4)用于分析每个更改建议的工作量及汇总统计量。4.5.3软件测试监理的方法(1)定期审查软件测试的工程活动和工作进度。 (2)根据实际需要对软件测试工程活动进行跟踪、审查和评估。 (3)对软件测试工程活动和产品进行评审和(或)审核，并报告结果。这些评审和(或)审核至少应包括:l 软件测试工程任务的准备就绪和完成准则得到满足。l 软件测试符合规定的标准和需求。l 已完成所需的测试。l 检测出的问题和缺陷已建立文档，并被跟踪和处理。l 通过软件测试，软件产

43、品符合软件需求的要求。l 在软件产品提交前，依据软件基线验证了用来管理和维护软件的文档。5、软件验收阶段监理5.1验收阶段监理工作的重点 按照项目合同查看承建单位提供的各种审核报告和测试报告内容是否齐全，再根据平时对承建单位工作情况的了解，可以初步判断开发方是否已经进行了足够的正式测试。 验收可以分为两个大的部分:软件配置审核和验收测试。其大致顺序可分为:文档审核，源代码审核，配置脚本审核，测试程序或脚本审核和可执行程序测试。验收阶段的每一个相对独立的部分，都应该有目标(本步骤的目的)、启动标准(着手本步骤必须满足的条件)、活动(构成本步骤的具体活动)、完成标准(完成本步骤要满足的条件)和度量

44、(应该收集的产品与过程数据)。5.2组织机构及人员组成 业主单位与监理单位协调成立专门的验收委员会，作为验收的组织机构。委员会一般不少于5人(单数)组成，设主任1人，委员若千人;并成立验收测试组和配置审核组，委员可分别参与这两个组的工作。另外还需要侧试员、配置审核员和记录员若干人。 验收委员会由业主单位代表、监理单位代表、承建单位代表以及邀请的技术专家组成员组成。5.3验收测试和配置审核步骤 1、制订验收测试计划、配置审核计划，做好验收测试、配置审核准备。 2、验收委员会审定测试计划、配置审核计划和测试准备、配置审核准备情况。 3、进行验收测试、配置审核，建立完整的测试、配置审核记录。 4、编写测试报告、配置审核报告。 5、验收委员会评审。5.4验收测试和配置审核内容 1、检查“合同”或“验收标准”要求的所有功能。 2、检查“合