免费智能真题库 > 历年试卷 > 信息系统监理师 > 2017年下半年 信息系统监理师 下午试卷 案例
  第1题      
  知识点：   承建单位   概要设计   监理单位   建设单位   瀑布模型   软件设计   设计阶段   详细设计   项目计划   需求分析   招标   变更控制   进度控制   开发过程   配置管理   配置管理计划   软件需求   数据库   数据库设计   数据库设计说明   信息管理   需求分析阶段   质量保证

 
【说明】
X省通信运营商拟开发运营支撑系统应用软件，管理企业的业务流程和基础资源。建设单位通过公开招标方式选择了监理单位，以便协助建设单位做好全过程的监理工作。该项目承建单位采用瀑布模型进行软件开发。在项目开发过程中，发生如下事件：
【事件1】监理单位根据项目的实际状况，拟将进度控制、变更控制、信息管理、协调作为全部监理内容。
【事件2】为了赶进度，承建单位编写了系统开发计划、质量保证计划、配置管理计划等项目计划及《软件需求规格说明书》后，认为需求分析阶段的工作已完成，立即开始进行软件设计。
【事件3】承建单位按照规定日期提交了概要设计说明书、数据库设计说明书、详细设计说明书，监理工程师老姚认为承建单位完成了设计阶段的任务。
 
问题：1.1   （4分）
对于事件1，监理单位的监理内容还应包括哪些？
 
问题：1.2   （5分）
对于事件2，作为监理工程师，请指出承建单位工作的不足之处。
 
问题：1.3   （5分）
(1) 针对事件3，监理工程师还应该从哪些方面对设计文档进行审查?
(2) 请说明对概要设计说明书应重点审查的内容。
 
问题：1.4   （6分）
为了有效地实施监理工作，提高监理质量，监理单位建立了完善的质量控制体系。监理单位的质量控制体系应包括哪些内容？
 
 
 

   知识点讲解    
   · 承建单位    · 概要设计    · 监理单位    · 建设单位    · 瀑布模型    · 软件设计    · 设计阶段    · 详细设计    · 项目计划    · 需求分析    · 招标    · 变更控制    · 进度控制    · 开发过程    · 配置管理    · 配置管理计划    · 软件需求    · 数据库    · 数据库设计    · 数据库设计说明    · 信息管理    · 需求分析阶段    · 质量保证
 
       承建单位
        负责具体实施的承建方应该有自己的项目管理，监理方代表项目建设方对承建方提出的工程计划进行监督和协调，对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴，但不能涉及管理细节。工程项目管理主要以承建方为主，并强调在项目中组织并制定相关计划。
        在一个大型信息系统工程项目的建设中，承建方可能有多个，比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天，专业化能促进生产效率和提高生产质量，故而承建方常常分解成一定的层次结构，如总承包商和分包商等，从而使一部分人或企业专注于项目管理的科学化。
        从市场的角度看，总承包商既是买方又是卖方；从工程合同的角度来讲，他既要对建设方负全部法律责任，又要根据分包合同对分包商进行管理并履行义务，所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商，但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。
        作为分包商，一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度，它只对总承包商承担分包合同内规定的责任并履行规定的义务。
        如果总承包商违反分包合同，则应该赔偿分包商的经济损失；分包商违反分包合同并造成建设方对总承包商的罚款或制裁，则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的，如果总承包商无力偿还债务，则分包商也同样蒙受损失，因此分包商的利益通常与总承包商的利益密切相关。
 
       概要设计
        概要设计也称为高层设计，即将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系。
        概要设计主要包括设计软件的结构、确定系统由哪些模块组成，以及每个模块之间的关系。它采用的是结构图（包括模块、调用和数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入／处理／输出图）。整个过程主要包括复查基本系统模型、复查并精化数据流图、确定数据流图的信息流类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析，以及根据软件设计原则对得到的软件结构图进一步进行优化。
 
       监理单位
        项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后，监理方作为工程承包合同的监督者，所执行的原则是使工程承包合同成为“平等条约”；作为工程承包合同管理和工程款支付的签认者，所执行的原则是等价交换。因此监理方是为双方的利益服务的，而不仅仅为委托方服务。
        根据工程监理的深入程度不同，信息系统工程监理可分为如下三种。
        （1）咨询式监理。只解答用户方就企业信息化过程中提出的问题，其性质类似于业务咨询或方案咨询。这种方式费用最少，监理方的责任最轻，适合于对信息化有较好把握，并且技术力量较强的用户方采用。
        （2）里程碑式监理。将信息系统的建设划分为若干个阶段，在每一个阶段结束都设置一个里程碑，在里程碑到来时通知监理方进行审查或测试。一般来讲，这种方式比咨询式监理的费用要多，监理方也要承担一定的责任。不过，里程碑的确定需要承建方的参与，或者说监理合同的确立需要开发方的参与，否则就会因对里程碑的界定不同而引起纠纷。
        （3）全程式监理。一种复杂的监理方式，不但要求对系统建设过程中的里程碑进行审查，还应该派相应人员全程跟踪并收集系统开发过程中的信息，不断评估承建方的开发质量和效果。这种方式费用最高，监理方的责任也最大，适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。
        监理单位的主要作用如下。
        （1）信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资，并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督，这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中，监理单位要依据国家有关法律和相关技术标准，遵循守法、公平、公正、独立的原则，对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下，合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制，对承建单位项目控制过程进行监督管理。
        （2）在信息系统工程建设中，建设单位和承建单位有许多问题存在争议，双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价，这就需要监理单位来协调和保障这些工作的顺利进行。
        （3）由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题，实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务，帮助建设单位对项目实施控制，并对建设单位和承建单位都做出约束，是监理作用一个重要体现。
 
       建设单位
        建设方是建设项目的主要投资者，有时也是项目的最终使用者，是在工程建设阶段的全权代表，建设项目的经济效益，如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体，但由于建设方是投资方，掌握着项目的最终资源——决定了其他方为从属地位，所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。
        作为项目管理集体中的主要负责人，建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急，组织协调参与各方为此目标而通力合作，在管理决策过程中做出决策。但在某些具体的项目管理事务中，建设方并不总是处于主要负责人的地位，还要作为裁判、支持者、服务员及督促员的角色。
 
       瀑布模型
        瀑布模型也称为生命周期法，是生命周期法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。采用瀑布模型的软件过程如下图所示。
        
        软件生存周期的瀑布模型
        （1）软件计划（问题的定义及规划）。主要确定软件的开发目标及其可行性。
        （2）需求分析。在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。
        （3）软件设计。主要是指根据需求分析的结果，对整个软件系统进行设计，如系统框架设计和数据库设计等。软件设计一般分为总体设计（概要设计）和详细设计。
        （4）程序编码。将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须要制定统一的、符合标准的编写规范，以保证程序的可读性和易维护性，提高程序的运行效率。
        （5）软件测试。在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
        （6）软件维护。软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件可能会不能继续适应用户的要求，这时如果要延续软件的使用寿命，就必须对软件进行维护。
        瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是“一次通过”，即每个活动只做一次，最后得到软件产品，也称做“线性顺序模型”或者“传统生命周期”，其过程是从上一项活动接收该项活动的工作对象并作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，然后作为输出传给下一项活动。同时对该项活动实施的工作进行评审，若其工作得到确认，则继续下一项活动，否则返回前项，甚至更前项的活动进行返工。
        瀑布模型有利于大型软件开发过程中人员的组织与管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下的，而是呈线性，因此，瀑布模型存在严重的缺陷。
        （1）由于开发模型呈线性，因此，当开发成果尚未经过测试时，用户无法看到软件的效果。这样，软件与用户见面的时间间隔较长，也增加了一定的风险。
        （2）在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会导致整个软件项目开发失败。
        （3）在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。
 
       软件设计
        软件概要设计监理的主要任务和目的是对软件概要设计有关内容（重点是软件的结构、软件的功能、接口设计和接口关系等）、概要设计过程、概要设计活动和文档格式等进行审查，确定承建单位提出的软件总体结构设计是否实现了软件需求规格说明的要求；给出是否符合要求的结论；确定其可否作为软件详细设计的前提和依据。具体来说，在概要设计阶段，监理的主要工作如下。
        （1）组织有关单位参加《概要设计说明书》评审会议，并根据国家相关标准、软件工程理论、《需求规格说明书》及工程建设合同等对《概要设计说明书》进行审查并提出监理意见。审核的重点是《概要设计说明书》是否能覆盖《软件需求说明书》，内容是否齐全规范且条理清晰，对潜在的用户需求是否给予了充分考虑并在技术层面上予以解决。
        （2）根据《项目开发计划》检查项目进展状况。根据具体情况及时提醒承建单位整合资源并调整项目的进度计划，检查承建单位是否依据《项目开发计划》配备相应的资源。
        （3）主持监理例会，做好监理日记。协调建设单位和承建单位对《软件需求说明书》所做的修改带来的相关问题，并定期将项目进展情况及发现的问题汇总，以项目月报的形式向建设单位做书面汇报。
        （4）做好项目往来文档的整理及存档工作。
        （5）督促承建单位尽早编写《软件集成测试计划》。
        （6）在概要设计进行前提交总体设计阶段的监理细则和监理周记，在概要设计完成后提交概要设计监理报告。
        软件详细设计监理的主要任务和目的是对软件详细设计有关内容（重点是软件的算法、数据结构、数据类型、异常处理和计算效率等）、详细设计过程、详细设计活动和文档格式等进行审查，确定承建单位提出的软件详细设计内容是否实现了软件概要设计的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件编码的前提和依据。具体来说，在详细设计阶段，监理的主要工作如下。
        （1）检查承建单位的实际工作进度是否与计划相一致，定期与承建单位沟通，检查文档及工作成果。
        （2）检查《详细设计说明书》及其相关文档的质量是否符合国家规范、行业规范及合同的要求。在详细设计的各个阶段点进行成果评审，以检验详细设计的内容是否能实现概要设计的要求，以及系统需求指标。
        （3）在详细设计前提交该阶段监理细则和监理周记，在详细设计完成后提交《详细设计说明书》的确认报告。
 
       设计阶段
        设计阶段监理进行质量控制的要点如下。
        （1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。
        （2）对各种设计文件提出设计质量标准。
        （3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。
        （4）协助承建单位建立质量保障体系。
        （5）协助承建单位完善现场质量管理制度。
        （6）组织设计文件及设计方案交底会，制定质量要求标准。
 
       详细设计
        详细设计也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。同样，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。
        详细设计确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）及PDL（伪码）。
        总的来说，在整个软件设计过程中，需完成以下工作任务。
        （1）制定规范，作为设计的共同标准。
        （2）完成软件系统结构的总体设计，将复杂系统按功能划分为模块的层次结构，然后确定模块的功能，以及模块间的调用关系和组成关系。
        （3）设计处理方式，包括算法、性能、周转时间、响应时间、吞吐量和精度等。
        （4）设计数据结构。
        （5）可靠性设计。
        （6）编写设计文档，包括概要设计说明书、详细设计说明书、数据库设计说明书、用户手册和初步的测试计划等。
        （7）设计评审，主要是对设计文档进行评审。
        在设计阶段，必须根据要解决的问题做出设计的选择。例如，半结构化决策问题就适合由交互式计算机软件来解决。
 
       项目计划
        项目计划阶段，监理的主要工作如下。
        （1）对软件计划的相关内容（重点是组织、技术标准、开发计划和进度要求等）、项目计划过程、项目计划组织和文档格式等进行审查，确认是否满足要求。
        （2）给出符合要求的结论。
        （3）确定其可否作为软件开发的前提和依据。
        项目计划监理的基本准则如下。
        （1）承建单位制订了软件项目计划，同时该项目计划通过了正式的评审，软件项目计划对项目组织、进度计划、工程标准进行了承诺，项目的风险分析合理，风险管理方案可行。
        （2）项目的阶段划分是明确的。
 
       需求分析
        软件需求分析监理的主要任务和目的是对软件需求分析的相关内容（重点是工程需求、功能需求、性能需求和设计约束等）、需求分析过程、需求分析活动及文档格式进行审查，确认是否满足要求，并确定其可否作为软件开发的前提和依据。
        （1）参与用户需求调研，尤其是关键业务及有甲乙双方决策人物参与的大型交流会等。
        （2）组织有关单位参加《需求规格说明书》技术联合评审会议，并根据国家相关标准、软件工程理论、用户需求及工程建设合同等进行审查并提出监理意见。
        （3）根据项目管理的理论，审核承建单位递交的《项目开发计划》。审核的重点是项目参与人员的技术工作背景是否适应本项目、工作分配及进度计划是否合理，以及软件开发风险因素分析、风险防范措施是否到位等。
        （4）审核承建单位提交的软件开发的质量保证及配置管理计划等软件生存周期支持过程的文档。
        （5）审核承建单位针对本工程投入的软硬件资源是否满足工程需要并及时到位。
        （6）审核承建单位在开发过程中使用的软件工具的合法性。
        （7）主持监理例会，做好监理日记，定期将项目进展情况及发现的问题汇总，并以项目月报的形式向项目建设单位做书面汇报。
        （8）做好项目往来文档的整理及存档工作。
        在需求分析阶段，监理工作的重点是对软件需求规格说明书和项目开发计划的审核。
 
       招标
        下列工程建设项目包括项目的勘察、设计、施工、监理，以及与工程建设有关的重要设备、材料等的采购，因此必须进行招标。
        （1）大型基础设施、公用事业等关系社会公共利益、公众安全的项目。
        （2）全部或部分使用国有资金投资或者国家融资的项目。
        （3）使用国际组织或者外国政府贷款、援助资金的项目。
        任何单位和个人不得将依法必须进行招标的项目化整为零或者以其他任何方式规避招标。招标投标活动应当遵循公开、公平、公正和诚实信用的原则。必须进行招标的项目，其招标投标活动不受地区或者部门的限制。任何单位和个人不得违法限制或者排斥本地区、本系统以外的法人或其他组织参加投标，不得以任何方式非法干涉招标投标活动。
        招标分为公开招标和邀请招标。公开招标是指招标人以招标公告的方式邀请不特定的法人或者其他组织投标。邀请招标是指招标人以投标邀请书的方式邀请特定的法人或者其他组织投标。国务院发展计划部门确定的国家重点项目和省、自治区、直辖市人民政府确定的地方重点项目不适宜公开招标的，经国务院发展计划部门或者省、自治区、直辖市人民政府批准，可以进行邀请招标。
               招标代理机构
               招标人有权自行选择招标代理机构，委托其办理招标事宜。任何单位和个人不得以任何方式为招标人指定招标代理机构。招标人具有编制招标文件和组织评标能力的，可以自行办理招标事宜。任何单位和个人不得强制其委托招标代理机构办理招标事宜。依法必须进行招标的项目，招标人自行办理招标事宜的，应当向有关行政监督部门备案。
               招标代理机构是依法设立、从事招标代理业务并提供相关服务的社会中介组织。招标代理机构应当具备下列条件。
               （1）有从事招标代理业务的营业场所和相应资金。
               （2）有能够编制招标文件和组织评标的相应专业力量。
               （3）有符合规定条件，可以作为评标委员会成员人选的技术、经济等方面的专家库。
               从事工程建设项目招标代理业务的招标代理机构，其资格由国务院或者省、自治区、直辖市人民政府的建设行政主管部门认定。具体办法由国务院建设行政主管部门会同国务院有关部门制定。从事其他招标代理业务的招标代理机构，其资格认定的主管部门由国务院规定。
               招标代理机构与行政机关和其他国家机关不得存在隶属关系或者其他利益关系。招标代理机构应当在招标人委托的范围内办理招标事宜。
               招标公告
               招标人采用公开招标方式的，应当发布招标公告。依法必须进行招标的项目的招标公告，应当通过国家指定的报刊、信息网络或者其他媒介发布。招标公告应当载明招标人的名称和地址、招标项目的性质、数量、实施地点和时间，以及获取招标文件的办法等事项。
               招标人采用邀请招标方式的，应当向3个以上具备承担招标项目的能力、资信良好的特定法人或者其他组织发出投标邀请书。投标邀请书应当载明的事项与招标公告相同。
               招标人可以根据招标项目本身的要求，在招标公告或者投标邀请书中要求潜在投标人提供有关资质证明文件和业绩情况，并对潜在投标人进行资格审查。国家对投标人的资格条件有规定的，依照其规定。招标人不得以不合理的条件限制或者排斥潜在投标人，不得对潜在投标人给予歧视待遇。
               招标文件
               招标人应当根据招标项目的特点和需要编制招标文件。招标文件应当包括招标项目的技术要求、对投标人资格审查的标准、投标报价要求和评标标准等所有实质性要求和条件，以及拟签订合同的主要条款。
               国家对招标项目的技术、标准有规定的，招标人应当按照其规定在招标文件中提出相应要求。招标项目需要划分标段、确定工期的，招标人应当合理划分标段、确定工期，并在招标文件中载明。招标文件不得要求或者标明特定的生产供应以及含有倾向或者排斥潜在投标人的其他内容。
               招标人根据招标项目的具体情况，可以组织潜在投标人踏勘项目现场。招标人不得向他人透露已获取招标文件的潜在投标人的名称、数量，以及可能影响公平竞争的有关招标投标的其他情况。招标人设有标底的，标底必须保密。
               招标人对已发出的招标文件进行必要的澄清或者修改的，应当在招标文件要求提交投标文件截止时间至少15日前，以书面形式通知所有招标文件收受人。该澄清或者修改的内容为招标文件的组成部分。
               招标人应当确定投标人编制投标文件所需要的合理时间。但是，依法必须进行招标的项目，自招标文件开始发出之日起至投标人提交投标文件截止之日止，最短不得少于20日。
 
       变更控制
        变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。
               变更控制委员会
               变更控制委员会（Change Control Board，CCB）也称配置控制委员会（Configuration Control Board），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以全职的，也可以是兼职的。
               如果CCB除控制变更以外，还要承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。
               变更控制的流程
               变更管理的基本流程如下：
               ①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
               ②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
               ③变更决策。由具有相应权限的人员或机构决定是否实施变更。
               ④变更实施。由管理者指定的工作人员在受控状态下实施变更。
               ⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
               ⑥沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。
               变更申请需要采用书面的形式提出，主要内容有如下3个方面：
               ①变更描述。包括变更理由、变更的影响、变更的优先级等，就是要描述做什么变更，为什么要做，以及打算怎么做的问题。
               ②对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。
               ③变更实施的信息。
               利用配置库实现变更控制
               配置项可以有3种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于不处理工作状态下（自由状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始于稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库（实施检入），开始冻结，此时开发人员不允许对其任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示。
               
               配置项的状态变化过程
               处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。
 
       进度控制
               进度控制概述
               进度控制是指在项目实施过程中，监控项目实施进程，并将实施情况与计划进行对比分析，采取必要的措施，使项目按预定的进度目标进行，以使预定目标按时实现。
               进度控制根据管理层次的不同，控制的视角和内容也会有所不同。对于项目经理等高层次管理部门，对项目控制的关注点是各里程碑事件的进度控制，也称为项目总进度控制；对于项目部门而言，关注点是项目中各主要事件的进度控制，在多级项目中，这些事件可能就是各个分项目，通过控制项目主要事件的进度，可促使其按计划进行，保证总进度的完成，此类控制称为项目主进度控制；对于各作业部门，其焦点是对各具体作业进度计划进行有效控制，这是进度控制的基础，此类控制称为项目详细进度控制。
               各层次进度控制都应遵循以下原则：
               （1）动态控制。项目进度控制是一个动态的过程。从项目开始实施，项目计划就进入了执行的轨道，实时观测进度是否按计划进行，及时发现偏差，分析偏差产生原因，采取有效措施调整，是一项动态持续的过程。
               （2）系统全面。编制全面的项目计划，包括进度计划、资源计划等、费用计划等，计划的对象由上而下，内容从粗到细，形成系统性的项目计划。项目涉及各个相关主体及责任人，需要建立一个完整的项目实施组织系统；对项目的检查、统计、分析、调整等工作，应责任到人，分工协作。无论是控制对象还是控制主体、是进度计划还是控制工作，都是一个完整的系统。
               （3）封闭循环。项目进度控制是一个循环性的例行工作，从编制计划、实施计划、检查、比较与分析、确定调整措施、修改计划等，是不断监测、反馈的过程，自然形成一个封闭的循环系统。
               （4）信息通畅。信息是项目进度控制的依据，项目进度计划和实施中的信息，应做到上通下达，保持信息传递和反馈时效性和有效性，使项目各环节了解项目计划目标和实际进度信息，以便分析、决策和调整，以使进度计划仍能符合预定工期目标。
               （5）弹性机制。对于大型项目，一般工期长且影响因素多，这就要求计划编制人员能根据统计经验，预估各种因素对进度的影响，将风险因素纳入进度计划的方案设计中，并建立风险防范预案，使进度计划留有余地，形成项目进度控制的弹性机制。
               （6）应用网络计划技术。网络计划技术不仅可以用于编制进度计划，而且可以用于计划的优化、管理和控制。网络计划技术是科学实施项目进度控制理论的基础和工具。
               进度监测和控制
                      项目监测
                      在项目实施过程中，为了收集反映项目进度实际状况的信息，掌握项目进展动态，应对项目进展状态进行观测，这一过程称为项目进度动态监测。对于项目进展状态的观测，通常采用日常监测和定期监测的方法进行，并将监测的结果用项目进展报告的形式加以描述。
                      在日常监测中，一般注意观测进度计划中各工作的实际开始时间、实际完成时间、实际持续时间、目前状况等内容，并加以记录，以此作为进度控制的依据。记录的方法有图示记录法、报告表法、进度动态曲线等。
                      在定期监测中，可以确定一个间隔时间，每隔一定时间对项目进度计划执行情况进行一次较为全面、系统的观测、检查。间隔的时间因项目的类型、规模、特点和对进度计划执行要求程度的不同而异，可以按日、周、月、季等作为一个观测周期。观测的主要内容包括：观测、检查关键工作的进度和关键线路的变化情况；观测、检查非关键工作的进度，以便发掘潜力，调整或优化资源，保证关键工作按计划实施；检查工作之间的逻辑关系变化情况，以便适时进行调整；有关项目范围、进度计划和预算变更的信息。
                      定期观测、检查的结果应加以记录，信息记录的方式可以是图或表。如若进度计划是甘特图，则可在图中用不同的线条分别表示计划进度和实际进度。也可绘制实际进度网络图，表达各工作实际开工、完工时间，并标注项目进展中出现的问题、影响因素等，它可明确表达实际与计划不相符合的情况，有助于计划工作的总结和资料的积累。
                      项目定期检查及记录后，应形成项目进展报告。项目进展报告根据报告的对象不同，其内容也不尽相同。一般的项目进展报告分为项目概要及进度控制报告、项目管理及进度控制报告和业务管理及进度控制报告。项目概要及进度控制报告是以整个项目为对象说明进度计划执行情况的报告；项目管理及进度控制报告是以分项目为对象说明进度计划执行情况的报告；业务管理及进度控制报告是以某重点部位或重点问题为对象所编写的报告。
                      项目报告除了用文字表达外，图表亦是传送信息的重要工具。常见的项目进展报告有：项目关键点检查报告，将对项目关键点的监测、检查的结果加以分析、归纳所形成的报告；项目执行状态或工作完成报告，反映已完成工作或实施中工作的基本情况；重大突发性事件的报告，就某一重大突发性事件的基本情况及其对项目的影响等有关问题所形成的特别分析报告；项目变更申请报告，反映项目变更的状况及其对项目产生的影响。
                      项目报告应注意频次的把握。项目进展报告与项目行动计划和WBS的关系是确定报告内容和频次的关键，信息报告应和计划、预算、进度系统的逻辑相一致，主要目的是控制实现项目计划，报告的频次应达到在计划完成期间满足控制所需信息的要求。原则上项目进展报告应及时给出，以便实时控制。报告的时间一般对应于项目里程碑时间。对高层管理者，一个项目可能只有几个里程碑；而对于基层管理，在项目计划的实施过程中存在许多关键点，一般这些关键点就是基层项目的里程碑，里程碑数量越多，所要求报告的信息内容越详细、报告次数也越多。一般来说，报告期越短，早发现问题并采取纠正措施的机会就越多。
                      项目进度控制实施
                      项目进度控制的实施在保证项目按预期实现中，起着十分重要的作用。在项目进展中，工作即按时完成，也会提前或延期完成，这些都会对项目的未完成部分产生影响。对项目的实际进展状况进行有效控制，核心就是根据项目的实际进展情况，不断地进行进度计划的优化和更新，进度计划的更新是进度控制的结果。
                      进度控制中最简单的方法是比较与分析法。将项目的实际进度与计划进度进行比较分析，确定进度偏差原因，寻找对策。比较分析的方法主要有以下几种：甘特图比较法，是将在项目进展的信息用横线并列标于原计划的横线旁，进行直观比较；实际进度前锋线比较法，是从计划检查时间的坐标点出发，用点画线依次连接各项工作的实际进度点，最后到计划检查时间的坐标点为止，形成前锋线，根据前锋线与工作箭线交点的位置判断项目实际进度与计划进度的偏差；S形曲线比较法，以横坐标表示进度时间、纵坐标表示累计完成任务量而绘制出的一条按计划时间累计完成任务量的S形曲线，用S形曲线可将项目的各检查时间实际完成的任务量与S形曲线进行实际进度与计划进度相比较，从而得出进度的偏差，如下图一所示；香蕉型曲线比较法，是两条S形曲线组合而成的闭合曲线，对于一个项目的网络计划，在理论上总是分为最早和最迟两种开始和完成时间，因此，任何一个项目的网络计划，都可以绘制出两条S形曲线，即以最早时间和最迟时间分别绘制出相应的S形曲线，在项目实施过程中，根据工作完成的情况绘制出实际进度累计曲线，即可对实际进度与计划进度进行比较，如下图二所示。
                      
                      S形曲线示意图
                      
                      香蕉形曲线
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
        ：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       配置管理
        随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
               （1）该项目对配置管理的要求。
               （2）实施配置管理的责任人、组织及其职责。
               （3）需要开展的配置管理活动及其进度安排。
               （4）采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。
               （1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
               （2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
       配置管理计划
        主要内容
        配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。由配置控制委员会审批该计划。
        主要步骤
        制订配置管理计划的主要步骤如下：
        （1）建立并维护配置管理的组织方针。
        （2）确定配置管理所需要的资源。
        （3）分配责任。
        （4）培训计划。
        （5）确定和配置管理有关的项目干系人并确定其介入时机。
        （6）制订识别配置项的准则。
        （7）制订配置项管理表。
        （8）制订基线计划。
        （9）制订配置库备份计划。
        （10）制订变更控制流程。
        （11）制订审批计划。
 
       软件需求
        在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
        （1）功能需求。
        （2）性能需求。
        （3）用户或人的因素。
        （4）环境需求。
        （5）界面需求。
        （6）文档需求。
        （7）数据需求。
        （8）资源使用需求。
        （9）安全保密要求。
        （10）可靠性要求。
        （11）软件成本消耗与开发进度需求。
        （12）其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               （1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               （2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               （3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
               （4）修正项目开发计划。
               （5）如有必要，可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               （1）功能需求。所开发的软件必须具备什么样的功能。
               （2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
               （3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       数据库
        数据库（DataBase，DB）是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
 
       数据库设计
        数据库的设计质量对整个系统的功能和效率有很大的影响。数据库设计的核心问题是：从系统的观点出发，根据系统分析和系统设计的要求，结合选用的数据库管理系统，建立一个数据模式。设计的基本要求是：
        .符合用户需求，能正确反映用户的工作环境
        .设计与所选用的DBMS所支持的数据模式相匹配
        .数据组织合理，易操作、易维护、易理解
               数据库设计步骤
               数据库的设计过程可以分为4个阶段，即用户需求分析、概念结构设计、逻辑结构设计和物理结构设计。下图反映和分析了这一设计过程，其中：
               
               数据库设计步骤
               .用户需求分析是对现实世界的调查和分析
               .概念结构设计是从现实世界向信息世界的转换。根据用户需求来进行数据库建模，也称为概念模型，常用实体关系模型表示。
               .逻辑结构设计是从信息世界向数据世界的转化。将概念模型转化为某种数据库管理系统所支持的数据模型。
               .物理结构设计是为数据模型选择合适的存储结构和存储方法。
               用户需求分析
               用户需求分析需要结合具体的业务需求分析，确定信息系统的各类使用者以及管理员对数据及其处理、数据安全性和完整性的要求。主要设计如下三方面：
               （1）系统应用环境分析。
               系统应用环境及系统所服务和运行的特殊组织环境。不同业务单位有不同的组织结构和业务工作流程。环境的特殊性将决定数据库的整体设计思路和风格。
               （2）用户数据需求及加工分析。
               用户需求及加工分析指用户希望从数据库中获得那些信息以及对信息的处理要求。由此决定数据库中应该存储哪些信息以及对数据需要进行哪些加工处理，包括在处理过程中特定的查询要求、响应时间要求，以及数据安全性、保密性、完整性和一致性等方面的要求，应在此基础上编制数据字典。
               （3）系统约束条件分析。
               系统约束条件分析及分析现有系统的规模、结构、资源和地理分布，明确现有系统存在的种种限制或约束，从而使系统设计不至于脱离实际条件，确保系统设计顺利实施。
               数据库概念结构设计
               概念结构设计是指由现实世界的各种客观事物及其联系转化为信息世界中的信息模型的过程，即为数据库的概念结构设计。E-R模型即实体-联系模型是描述数据库概念结构的有力工具。下面结合实例说明E-R模型的构建。
               在一个政府部门中存在着多个不同科室，每一个由若干名科员构成，每个科室都有一名主管上级领导，科室公务员负责为前来机关办事的群众提供相关的服务。现分别画出各个科室的E-R模型图，再画出整个机关的E-R模型。
               一个科室结构应包括：
               （1）实体，即上级领导、科室、科员、群众。
               （2）实体联系，主管领导与科室之间是一对多的关系，科室与科员之间的联系也是一对多的关系，科员与群众之间是多对多的关系。
               （3）各个实体所具有的属性。
               .主管上级领导，属性可以有编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室的属性可以包括科室号
               .科员的属性包括编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众属性包括服务日期、服务事宜、处理结果
               .服务，包括服务日期、服务事宜、处理结果
               通过以上分析，可以得到如下的E-R模型，如下图所示（部分属性）。
               
               科室E-R模式图
               数据库逻辑结构设计
               逻辑结构设计的任务是要将概念结构设计阶段完成的概念模型转换成能被选定的数据库管理系统支持的数据模型。现行的数据库管理系统一般支持网状、层次和关系三种数据模型中的一种，其中关系型的数据模型在DBMS中的应用和支持较为广泛，已成为主流。
               下面简单介绍一下由E-R模型转换为关系数据模型的转化规则。在关系数据模型下，数据的逻辑结构是一张二维表，每个关系为一张二维表格。E-R模型转换为关系数据模型的转化规则如下。
               .每一实体及其属性对应于一个关系模式。实体名作为关系名，实体的属性作为对应关系的属性。所谓关系模式，就是对关系的描述，用关系名（属性1、属性2、属性3，……属性n）来表示。
               .两两实体之间的联系及其属性一般对应一个关系模式，联系名作为对应的关系名，联系的属性作为对应关系的属性；不带属性的联系可以去掉。
               .实体和联系中关键字属性在关系模式中仍作为关键字。
               上图中所示的实体关系图可以按照这些转换规则进行转化得到如下对应的关系模型。
               .主管上级领导，编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室，包括主管上级领导编号、科室号
               .科员，包括科室号、编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众，包括来访者编号、姓名、性别、年龄、来访日期、服务事宜
               .服务，包括受理公务员编号、来访者编号、服务日期、服务事宜、处理结果
               不同的系统配备的数据库管理系统性能不同，因而必须结合具体DBMS的性能和要求将一般数据模型转换成所选用的数据管理系统支持的数据模型，若选用的DBMS支持层次、网络模型，则还要完成从关系模型向层次或网络模型的转换。
               数据库物理结构设计
               数据库的物理设计以逻辑结构设计的结果为输入，结合关系数据库系统的功能和应用环境、存储设备等具体条件为数据模型选择合适的存储结构和存储方法。从而提高数据库的效率。物理结构设计的主要任务如下。
               （1）确定存储结构。
               根据用户对数据结构和处理的要求，权衡数据存取时间、空间利用率和维护代价等三方面的利弊，综合考虑存储效率、维护成本等相关因素，从数据库管理系统提供的各种存储结构（例如顺序存储结构、索引存储结构，等等）中，选取合适的结构并加以实现。
               （2）选择和调整存储路径。
               数据库必须支持多个用户的多种应用，因此必须提供多个存取入口、多条存取路径，建立多个辅助索引。此过程中需要考虑一些问题，例如如何选取合适的数据项建立索引，如何建立辅助索引从而达到检索效率和存储空间的统一等。
               （3）确定数据存储位置。
               按照不同的应用可将数据分为若干个组。根据各组数据利用频率和存储要求的不同，各类数据的存放位置、存储设备以及区域划分都应有所不同。应该把存取频率和存取速度要求较高的数据存储在高速存储器上，把存取频率和存取速度要求较低的数据存储在低速存储器上。
               （4）确定存储分配。
               大多数据库管理系统会提供一些存储分配参数，例如溢出区大小、块大小、缓冲区大小和个数等，设计人员应全面考虑这些参数，以进行物理优化。
               （5）确定数据的完整性与安全性约束。
               进行物理设计时不仅要考虑所选用数据库管理系统提供的安全机制和完整性约束，还要考虑用户使用制度、应用程序、计算机系统等各个涉及具体应用的方面。
               （6）考虑数据恢复方案。
               数据库的物理设计阶段也要考虑数据库的恢复问题，采取必要的物理措施和手段，为突发事件和故障后的恢复做好准备，提供必要的物理工具。
 
       数据库设计说明
        数据库设计是指数据库应用系统的设计。编制数据库设计说明书的目的是对设计中的数据结构的所有标识、逻辑结构和物理结构做出具体的设计规定。编写提纲和内容要求如下。
        （1）概述。
        .目标，说明开发的意图、应用目标、作用范围以及有关数据库开发的背景材料
        .主要功能，简要说明数据库系统的主要功能。
        .用户的安排，指最终用户。说明操作人员、数据管理人员和维护人员的水平。
        （2）需求规定。
        .性能规定
        .精度，简述对数据精度的要求。
        .有效性，说明对数据库存取数据的有效性的要求。
        .时间要求，如响应时间、数据的转换和传送时间等。
        .其他专门要求。
        （3）运行环境要求。
        .设备，简述运行数据库系统的硬设备及其专门功能。
        .支撑软件，列出支撑软件并说明测试前的软件。
        .安全保密，说明在安全保密方面的全部要求。
        .其他要求。
        （4）设计考虑。
        .逻辑结构设计，简要说明本系统（或子系统）内所使用的数据结构中，有关数据项、记录、文件的标识定义、长度及它们之间的相互关系。
        .物理结构设计，简要说明本系统内所使用的数据结构中有关数据库的存储要求、访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密处理。
        （5）评价。
        简要说明对时间、空间效率、维护代价和各种用户要求进行权衡所产生的方案性能情况。
        （6）验收。
 
       信息管理
        管理信息系统是由人、计算机和管理规则等组成，以采集、加工、维护和使用信息为主要功能的人－机系统。例如金融、财会、经营、管理、教育、科研、医疗、人事、档案、物资等各方面都有大量的信息需要及时分析和处理，以便为决策提供依据。虽然在这方面应用中计算公式并不复杂，但数据量极大，在当今信息爆炸的时代，人工已难以胜任这一重任，计算机则成为信息管理的重要工具。该系统一般以数据库管理系统为核心，以其他软件和网络系统为支撑环境，而用户则通过专门的人机交互界面，进行数据的查询、修改等操作，并实现统计分析、规划、决策等功能。在信息管理方面，我们正经历着从单项事务的电子数据处理，向以数据库为基础的管理信息系统，及以数据库、模型库和方法库为基础的决策支持系统发展的过程，并且呈现出系统集成化、结构分布化、信息多元化、功能智能化等趋势。
 
       需求分析阶段
        . 确定软件的可靠性目标；
        . 分析可能影响可靠性的因素；
        . 确定可靠性的验收标准；
        . 制定可靠性管理框架；
        . 制定可靠性文档编写规范；
        . 制定可靠性活动初步计划；
        . 确定可靠性数据收集规范。
 
       质量保证
        系统质量是指反映系统或产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动，由质量保证、质量规划和质量控制三个主要活动构成。质量保证是指为保证系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是开发高质量的系统。
               质量特性
               讨论系统质量首先要了解系统的质量特性。已经有多种软件质量模型来描述软件质量特性，目前较多采用的如ISO/IEC 9126软件质量模型和Mc Call软件质量模型。ISO/IEC 9126已经被ISO/ICE 25010系统和软件质量模型所取代，其主要改进包括将兼容性作和安全性作为质量特性，ISO/IEC 25012数据质量模型与ISO/IEC 25030使用质量模型作为补充。
                      ISO/ICE 25010系统和软件质量模型
                      ISO/ICE 25010系统和软件质量模型包含8个质量特性，每个特性由一组相关的质量子特性组成，如下图所示。该产品质量模型既可以用于软件，又可以用于任何包含软件的计算机系统。
                      
                      产品质量模型
                      其中，各质量特性和质量子特性的含义如下。
                      （1）功能适合性（functional suitability）。与一组功能及其指定的性质的存在有关的一组属性。功能是指满足规定或隐含需求的那些功能。
                      .功能完整性（functional completeness）：与对规定任务和用户目标加以实现的功能是否完整有关的属性。
                      .功能适当性（functional appropriateness）：与对规定任务和用户目标能否提供一组功能以及这组功能是否适合有关的属性。
                      .功能正确性（functional correctness）：与能够得到正确或相符的结果或效果有关的产品或系统属性。
                      （2）性能效率（performance efficiency）。在规定条件下，系统的性能水平与所用资源量之间的关系有关的一组属性。
                      .时间特性（time behavior）：与响应和处理时间以及软件执行其功能时的吞吐量有关的属性。
                      .资源利用率（resource utilization）：与系统执行其功能时所使用的资源量以及使用资源的类型有关的属性。
                      .容量（capacity）：与系统满足特定需求时指标参数的最大限制有关的属性。
                      （3）兼容性（compatibility）。与系统或组件与其他系统或组件进行信息交换，或在不同软硬件环境中执行所需功能有关的一组属性。
                      .共存性（co-existence）：与同其他系统运行在同一环境使用相同的资源而不相互影响的能力相关的属性。
                      .互操作性（interoperability）：与同其他指定系统进行交互操作的能力相关的属性。
                      （4）易用性（usability）。与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性。
                      .可识别性（appropriateness recognizability）：与用户识别系统是否满足需求有关的属性。
                      .易学性（learnability）：与用户为学习使用产品（例如操作控制、输入、输出）的有效性、效率、风险和满意度相关的属性。
                      .易操作性（operability）：与用户为进行操作和操作控制所付出的努力有关的属性。
                      .错误防御（user error protection）：与阻止用户错误输入有关的属性。
                      .界面美观性（user interface aesthetics）：与系统用户界面使用户进行愉快满意交互有关的属性。
                      .可访问性（accessibility）：与用户可访问系统完成特定目标的范围和能力有关的属性。
                      （5）可靠性（reliability）。与在规定的一段时间内和规定的条件下，系统维持在其性能水平有关的能力。
                      .成熟性（maturity）：与正常操作情况下满足可靠性需求有关的属性。
                      .可用性（availability）：与系统运行可用使用能力有关的属性。
                      .容错性（fault tolerance）：与在系统错误或违反指定接口的情况下，维持指定的性能水平的能力有关的属性。
                      .易恢复性（recoverability）：与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和努力有关的属性。
                      （6）安全性（security）。与避免对程序及数据的非授权故意或意外访问的能力有关的系统属性。
                      .机密性（confidentiality）：与系统确保只有授权才能访问其数据能力有关的属性。
                      .完整性（integrity）：与系统防止未经授权对数据和程序进行访问和修改能力有关的属性。
                      .不可抵赖性（non-repudiation）：与对系统使用行为及发生时间真实性有关的属性。
                      .可审计性（accountability）：与对系统使用行为进行追踪有关的属性。
                      .真实性（authenticity）：与证明主体或资源身份是所声称的身份有关的属性。
                      （7）可维护性（maintainability）。与进行规定的修改所需要的努力有关的一组属性。
                      .模块性（modularity）：与所组成系统的模块独立性有关的属性。
                      .可复用性（reusability）：与模块用于其他系统有关的属性。
                      .易分析性（analyzability）：与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的属性。
                      .易修改性（modifiability）：与进行修改、排错或适应环境变换所需努力有关的属性。
                      .易测试性（testability）：为确认经修改系统所需努力有关的属性。
                      （8）可移植性（portability）。与系统可从某一环境转移到另一环境的能力有关的一组属性。
                      .适应性（adaptability）：与系统转移到不同环境时的处理或手段有关的属性。
                      .易安装性（installability）：与在指定环境下对系统进行安装／卸载所需努力有关的属性。
                      .易替换性（replaceability）：与一产品在该软件环境中用来替代指定的其他软件的可能和努力有关的属性。
                      Mc Call软件质量模型
                      Mc Call软件质量模型从软件产品的运行、修正、转移三个方面确定了11个质量特性，如下图所示。Mc Call也给出了一个三层模型框架，第一层是质量特性，第二层是评价准则，第三层是度量指标。
                      
                      Mc Call软件质量模型
               质量保证
               质量保证是指为保证系统或产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的产品。在系统质量方面强调三个要点：首先系统必须满足用户规定的需求，与用户需求不一致的系统，就无质量可言；其次系统应遵循规定标准所定义的一系列开发准则，不遵循这些准则的系统，其质量难以得到保证；最后系统还应满足某些隐含的需求，例如希望有好的可理解性、可维护性等，而这些隐含的需求可能未被明确地写在用户规定的需求中，如果系统只满足它的显性需求而不满足其隐含需求，那么该系统的质量是令人担忧的。
               质量保证包括7个主要活动相关的各种任务，分别是应用技术方法、进行正式的技术评审、测试系统、标准的实施、控制变更、度量（metrics）、记录保存和报告。
   题号导航      2017年下半年 信息系统监理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第1题    在手机中做本题