免费智能真题库 > 历年试卷 > 信息系统监理师 > 2014年下半年 信息系统监理师 下午试卷 案例
  第4题      
  知识点:   承建单位   电子政务   集成测试   建设单位   软件测试   系统测试   项目验收   调试   风险评估   结果分析   评估   软件故障   软件系统   实施计划   系统故障   项目管理   信息安全

 
【说明】
某重点大型电子政务工程项目建设中,建设单位甲与承建单位乙签订了实施合同,工期为18个月。合同规定,项目完成后首先进行各子项目内部验收,再按照《国家电子政务工程建设项目管理暂行办法》的相关规定进行项目验收,并委托某监理公司丙承担项目全过程的监理任务。建设过程中发生了以下事件:
亊件1 :承建单位根据项目建设需要制定了周密的实施计划,部分节点是:项目实施后第8个月完成主机等设备的安装调试工作和子项目内部验收,第9个月完成软件开发和子项目内部验收,第10个月开始进行试运行,第14个月完成信息安全风险评估,第15个月完成项目出入验收……
亊件2 ;承建单位项目经理在安排软件测试任务的动员会上讲:软件测试环节是软件系统质量形成的主要环节,各开发小组,特别是测试小组,应重视软件集成此时的工作。因此,项目经理安排测试组进行测试的时间非常充足,测试周期占整个软件系统开发周期的40%,约15周。在软件系统测试的过程中,项目经理安排了详细的测试跟踪计划,统计每周所发现的软件系统故障数量,以及所解决的软件故障。根据每周集成测试结果分析软件系统故障随时间的推移呈明显下降趋势:第1周发现约100个故障,第2周发现约90个故障,第3 周发现50个故障……第10周发现2个故障,第11周发现1个故障,第12周和第13周发现0个故障。因此,项目经理认为应用软件达到了内部经验验收的条件。
亊件3:项目初步验收完成后,建设单位要求监理机构协助整理提交竣工验收申请报告时所需要的、作为附件一并上交的其他文件。
 
问题:4.1   针对事件1,作为该项目的监理工程师,你认为承建单位项目经理做的项目计划可行吗? 说出理由。
 
问题:4.2   针对事件2,作为监理工程师,请指出:
(1) “软件测试环节是软件系统质量形成的主要环节”的说法妥当吗?说出理由。
(2) 第12周和第13周发现0个故障,因此项目经理认为应用软件达到了内部验收的条件,这种说法妥当吗?说出理由。
 
问题:4.3   请给出事件3中提交竣工验收申请报告时所需的,作为附件一并上交的其他文件。
 
 
 

   知识点讲解    
   · 承建单位    · 电子政务    · 集成测试    · 建设单位    · 软件测试    · 系统测试    · 项目验收    · 调试    · 风险评估    · 结果分析    · 评估    · 软件故障    · 软件系统    · 实施计划    · 系统故障    · 项目管理    · 信息安全
 
       承建单位
        负责具体实施的承建方应该有自己的项目管理,监理方代表项目建设方对承建方提出的工程计划进行监督和协调,对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴,但不能涉及管理细节。工程项目管理主要以承建方为主,并强调在项目中组织并制定相关计划。
        在一个大型信息系统工程项目的建设中,承建方可能有多个,比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天,专业化能促进生产效率和提高生产质量,故而承建方常常分解成一定的层次结构,如总承包商和分包商等,从而使一部分人或企业专注于项目管理的科学化。
        从市场的角度看,总承包商既是买方又是卖方;从工程合同的角度来讲,他既要对建设方负全部法律责任,又要根据分包合同对分包商进行管理并履行义务,所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商,但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。
        作为分包商,一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度,它只对总承包商承担分包合同内规定的责任并履行规定的义务。
        如果总承包商违反分包合同,则应该赔偿分包商的经济损失;分包商违反分包合同并造成建设方对总承包商的罚款或制裁,则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的,如果总承包商无力偿还债务,则分包商也同样蒙受损失,因此分包商的利益通常与总承包商的利益密切相关。
 
       电子政务
        所谓电子政务,就是政府机构应用现代信息和通信技术,将管理和服务通过网络技术进行集成,在因特网上实现政府组织结构和工作流程的优化重组,超越时间和空间及部门之间的分隔限制,向社会提供优质和全方位的、规范而透明的、符合国际水准的管理与服务。电子政务的主要模式有4种,分别为G2G、G2E、G2B和G2C。
        (1)政府对政府(Government To Government,G2G):政府内部、政府上下级之间、不同地区和不同职能部门之间实现的电子政务活动。G2G模式是电子政务的基本模式,包括电子法规政策系统、电子公文系统、电子司法档案系统、电子财政管理系统、电子办公系统、电子培训系统和业绩评价系统等。
        (2)政府对公务员(Government To Employee,G2E):政府与公务员(即政府雇员)之间的电子政务,主要是利用Intranet建立起有效的行政办公和员工管理体系,为提高政府工作效率和公务员管理水平服务。G2E是政府机构通过网络技术实现内部电子化管理的重要形式,也是G2G、G2B和G2C电子政务模式的基础。
        (3)政府对企业(Government To Business,G2B):政府与企业之间的电子政务,包括电子采购与招标、电子税务、电子证照办理、信息咨询服务和中小企业电子服务等。
        (4)政府对公民(Government To Citizen,G2C):政府与公民之间的电子政务,是指政府通过电子网络系统为公民提供各种服务。包括教育培训服务、就业服务、电子医疗服务、社会保险网络服务、公民信息服务、交通管理服务、公民电子税务和电子证件服务等。
 
       集成测试
        集成测试也称为组装测试、联合测试(对于子系统而言,则称为部件测试)。它将已通过单元测试的模块集成在一起,主要测试模块之间的协作性。从组装策略而言,可以分为一次性组装和增量式组装(包括自顶向下、自底向上及混合式)两种。集成测试计划通常是在软件概要设计阶段完成的。
        软件集成的过程是一个持续的过程,会形成多个临时版本。在不断的集成过程中,功能集成的稳定性是真正的挑战。在每个版本提交时,都需要进行“冒烟”测试,即对程序主要功能进行验证。冒烟测试也称为版本验证测试或提交测试。
 
       建设单位
        建设方是建设项目的主要投资者,有时也是项目的最终使用者,是在工程建设阶段的全权代表,建设项目的经济效益,如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体,但由于建设方是投资方,掌握着项目的最终资源——决定了其他方为从属地位,所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。
        作为项目管理集体中的主要负责人,建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急,组织协调参与各方为此目标而通力合作,在管理决策过程中做出决策。但在某些具体的项目管理事务中,建设方并不总是处于主要负责人的地位,还要作为裁判、支持者、服务员及督促员的角色。
 
       软件测试
        在软件测试阶段,监理的主要活动如下。
        (1)监督承建单位将合适的软件测试工程方法和工具集成到项目定义的软件过程中。
        (2)监督承建单位依据项目定义的软件过程,对软件测试进行开发、维护、建立文档和验证,以满足软件测试计划的要求。
        (3)监督承建单位依据项目定义的软件过程和计划实施软件的确认测试。
        (4)计划和实施软件系统测试,实施系统测试以保证软件满足软件需求。
        (5)软件监理组跟踪和记录软件测试的结果。
        在软件测试阶段,监理的主要方法有定期检查、必要抽查、评审。
        (1)定期审查软件测试的工程活动和工作进度。
        (2)根据实际需要对软件测试工程活动进行跟踪、审查和评估。
        (3)对软件测试工程活动和产品进行评审和(或)审核,并报告结果。
 
       系统测试
        如果项目不只包含软件,还有硬件和网络等,则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列集成与确认测试。一般来说,系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。系统测试计划通常在系统分析阶段(需求分析阶段)完成。
 
       项目验收
        信息应用系统验收需由建设单位组织,监理辅助和承建单位配合。建设单位的工作主要是审核承建单位的验收方案并确定验收方案,承建单位的工作主要是内部测试准备、验收准备工作、验收申请提交和验收方案准备。监理的工作重点是软件配置审核和验收测试,具体分为文档审核、源代码审核、配置脚本审核、测试程序或脚本审核和可执行程序测试。
        信息应用系统验收的过程与信息网络系统的验收过程是一致的,其基本步骤为提出验收申请、制订验收计划、成立验收委员会、进行验收测试和配置审计、进行验收评审、形成验收报告并移交产品。验收的地点及条件要符合合同或验收方案的规定。
               验收委员会
               在信息应用系统验收阶段,验收委员会人数为不少于5人的单数,验收委员会的任务及其权限如下。
               (1)判定所验收的软件是否符合合同要求。
               (2)审定验收环境。
               (3)审定验收测试计划。
               (4)组织验收测试和配置审核,进行验收评审,并形成验收报告。
               验收的原则
               信息应用系统的验收,要遵循以下基本原则。
               (1)验收测试和配置审核是验收评审前必须完成的两项主要检查工作,由验收委员会主持。
               (2)测试组在认真审查需求规格说明、确认测试和系统测试的计划与分析结论的基础上制订验收测试计划。
               (3)配置审核组在需求规格说明、确认测试和系统测试等过程中形成的产品的变更管理及审核工作的基础上开展审计。
               (4)原有测试和审核结果凡可用的就可用,不必重做该项测试或审核。同时,可根据建设单位的要求临时增加一些测试和审核内容。
               (5)测试组在完成测试验收的同时,完成功能配置审核,即验证软件功能和接口与“合同”的一致性。
               (6)配置审核组完成物理配置审核,检查程序和文档的一致性、文档和文档的一致性、交付的产品与“合同”要求的一致性及符合有关标准的情况。
               验收的准则
               信息应用系统验收的准则如下。
               (1)软件产品符合“合同”或“验收标准”规定的全部功能和质量要求。
               (2)不同安全性关键等级的软件均通过了《软件测试细则》文档要求的各项测试。
               (3)文档齐全,符合“合同”或“验收标准”的要求及有关标准的规定。
               (4)文档和文档一致,同时程序和文档相符。
               (5)对被验收软件的可执行代码,在验收测试中查出的错误总数,以及错误严重性不超过建设单位事先约定的限制值。
               (6)配置审核时查出的交付文档中的错误总数不超过建设单位事先约定的限制值。
               验收报告
               验收报告的主要内容包括验收的各项内容、评价与验收结论、验收委员会全体成员签字及验收委员会主任的意见。
               如果验收未通过,则需要重新验收或进入合同争议。如果验收通过,则监理需要审查承建单位的项目资料清单、协助建设单位和承建单位交接项目资料、确保软件文档和软件的一致性,同时将开发软件做好备份,保管在安全的地方,文件材料归档。
 
       调试
        调试的任务就是根据测试时所发现的错误,找出原因和具体的位置,进行改正。调试主要由程序开发人员来进行,谁开发的程序就由谁来进行调试。常用的调试方法有试探法、回溯法、对分查找法、归纳法和演绎法。
 
       风险评估
        一种对风险评估很有用的技术就是定义风险参照水准。对于大多数软件项目来说,成本、进度和性能就是三种典型的风险参照水准。也就是说,对于成本超支、进度延期、性能降低(或它们的某种组合),有一个表明导致项目终止的水准。
        在进行风险评估时,需要建立(rilixi)形式的三元组。其中,ri表示风险,li表示风险发生的概率,xi则表示风险产生的影响。在风险评估过程中,需要执行以下4个步骤:
        (1)定义项目的风险参考水平值。
        (2)建立每一组(rilixi)与每一个参考水平值之间的关系。
        (3)预测一组临界点以定义项目终止区域,该区域由一条曲线或不确定区域所界定。
        (4)预测什么样的风险组合会影响参考水平值。
 
       结果分析
        当数据挖掘出现结果后,要对挖掘结果进行解释和评估。具体的解释和评估方法一般根据数据挖掘操作结果所制定的决策成败来定,但是管理决策分析人员在使用数据挖掘结果之前,又希望能够对挖掘的结果进行评估,以保证数据挖掘结果在实际应用中的成功率。因此,在对数据挖掘结果进行评价时,可以考虑这样几个方面的问题:第一,建立模型相同的数据集在模型上进行操作所获得的结果要优于用不同数据集在模型上的操作结果;第二,模型的某些结果可能比其他预测结果更加准确;第三,由于模型是以样板数据为基础建立的,因此,实际结果往往会比建模时的结果差。另外,利用可视化技术可将数据挖掘结果表现得更清楚,更有利于对数据挖掘的结果分析。
 
       评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如ATM或FDDI等)的评估。评估测试不适用于全局网络,因为全局网络拓扑负载、网络设备太多,不好准确定位引起问题的原因和位置,不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商,如路由器、集线器或交换机的供应商,通常很少再做设备比较测试,但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题,所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时,除了使用专用于待测设备或技术的工程负载外,有经验的程序员也使用真实负载,使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较,可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能/特征测试一样,用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础,评估测试中对几种设备或技术进行比较;衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划/设计阶段进行测试是非常好的方法,最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试,在设备选型、技术选型,以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形(工程负载)和真实负载模式进行测试,两种方式都提供了唯一的、重要的检测结果,测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果,因此不能在真实运行环境里显示它们的运行性能;真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能,但无法预测设备的总容量。如果时间允许,两种测试都要做。通常测试人员只有时间进行一种测试,一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形(工程负载)下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置,任何有效、公正的测试配置都能对被测产品进行很好的比较。然而,测试配置和负载越接近运行网络的配置和负载,测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意:要确保配置中所有测试组件都是最新版本,使测试尽可能地公正和统一,以取得最好的测试结果。在测试非正式版时一定要小心,因为发布日期经常有错误。测试配置中安装了非正式版后,它还可能会变,所以非正式版的测试结果和正式版的测试结果经常不一致,分析非正式版的设备经常会延误项目的进行。
        进行评估测试时,除了被测设备,测试配置中的所有网络组件都要保持不变。这一点非常重要,只有这样才能保证被测设备可以进行公平比较。对于子网,这一点很容易做到(一个网络设备很容易被另一个设备所替代)。
        网络技术评估要比较各种网络技术,因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换,路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务,逐步完成测试、数据收集和数据解释。在评估测试中,各测试进行的先后次序没有关系,因为它们不是线性关系,而是多次重复进行的。当在测试中发现了新的信息时,以前所做的测试可能要重新进行以确定它的测试结果,或要对以前的测试稍作改变以检验网络运行的其他方面。此外,在评估期间设备提供商经常发布新的版本或非正式的版本,所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时,不仅要参考评估测试所得的测试结果数据,还要综合考虑其他一些信息,如各设备的性能价格比,但由于没有运行网络的持续和峰值负载要求,所以缺少比较基准,往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估,并撰写网络系统评估报告。
 
       软件故障
        计算机软件系统是实现信息系统运行的支持平台和应用工具,软件故障是指信息系统中所涉及的各种软件程序发生的故障。例如,操作系统崩溃,应用程序运行过程中发生重大错误等。
        软件故障发生的原因也有很多种,比如软件参数配置错误,软件使用人员错误操作,系统程序安全漏洞,应用程序设计缺陷,计算机病毒破坏等。
 
       软件系统
        网络系统软件包括网络操作系统和网络协议等。网络操作系统是指能够控制和管理网络资源的软件,是由多个系统软件组成,在基本系统上有多种配置和选项可供选择,使得用户可根据不同的需要和设备构成最佳组合的互联网络操作系统。网络协议是保证网络中两台设备之间正确传送数据的约定。
 
       实施计划
        (1)工作任务的分解:指对开发中应完成的各项工作按子系统(或系统功能)划分,指定专人分工负责。
        (2)进度:指给出各项工作的预定日期和完成日起,规定任务完成的先后顺序及完成的界面。可用PERT图或甘特图表示进度。
        (3)预算:指逐项列出本项目所需要的劳务以及经费的预算,包括办公费、差旅费、资料费,等等。
        系统说明书内容指南
        1.引言
        1.1摘要
        (摘要说明所建议开发的系统的名称、目标和功能。)
        1.2背景
        (1)项目的承担者
        (2)用户
        (3)本系统和其他系统或机构的关系和联系
        1.3参考和引用资料
        (1)本项目的经核准的计划任务书或合同、上级机关的批文
        (2)属于本项目的其他已发表的文件
        (3)本文件中各处引用的文件资料
        (列出上述文件资料的标题、编号、发表日期和制定单位,说明这些文件资料的来源。)
        1.4专门术语定义
        (本文件所用到的术语。)
        2.项目概述
        2.1项目的主要工作内容
        (简要地说明本项目在开发中须进行的各项主要工作,这些工作是建立新系统逻辑模型的必要条件,而逻辑模型是书写系统说明书的基础。)
        2.2系统需求说明
        (新系统是在现行系统的基础上建立起来的。在新系统设计工作开展之前,必须对系统调查清楚,掌握现行系统的真实情况,了解用户的新要求和问题所在。)
        2.2.1现行系统的现状调查说明
        (列出现行系统的目标、主要功能、用户要求等,并简要指出问题所在。)
        2.2.2业务流程说明
        (简要说明现行系统现场工作流程和事务流程概况。反映这些业务流程的业务流程图,若需要,可另附。)
        2.3系统功能说明
        (在现行系统现状调查的基础上,进一步透过具体工作,分析组织内信息、数据流动的路径和过程,真正弄清用户要解决什么问题,明确系统的功能要求。)
        2.3.1新系统功能要求
        (数据流程图是系统需求的高度概括,是调查研究的重要产物,它源于现行系统,又高于现行系统。这里主要通过数据流程图概况说明系统的功能要求。)
        (1)系统的目标
        (从新系统数据流程图的分析中,说明新系统有哪些目标。)
        (2)新系统的功能要求
        (列出新系统的主要功能)
        (3)验收
        (简单说明分析员和用户一起讨论分析的验收是否达到要求。)
        2.4系统的数据要求说明
        (从数据流程图和数据字典分析逻辑数据结构,标识每个数据结构中的每个数据项、记录和文件的长度以及它们之间的关系。)
        2.4.1系统的数据要求
        (这里的数据是指静态数据,即在运行过程中主要作为参考的数据,它们在很长一段时间内不会变化,一般不随运行而改变。)
        (1)数据项定义
        (说明数据项定义中出现的例外情况,列出作为控制或参考的主要数据项。)
        (2)容量
        (本系统所有数据项的总长度。)
        (3)用户
        (4)验收
        (指出验收情况。)
        2.4.2系统的数据要求的粗略估计
        (粗略估算系统在运行过程中动态数据的内容。)
        上述工作,再加上环境对系统影响的估计,以及研制时间和人力、物力引起的费用估计,构成系统规格说明书。
        3.实施总计划
        3.1工作任务的分解
        (对于项目开发中应完成的各项工作,按系统功能(或子系统)划分,指定专人(或小组)分工完成,指明每项任务的负责人。)
        3.2进度
        (给出每项工作任务的预定开始日期和完成日期,规定各项工作任务完成的先后顺序以及每项工作任务完成的界面。)
        3.3预算
        (逐项列出本开发项目所需要的劳务(包括工作量/人)以及经费的预算(包括办公费、差旅费、资料费等)。)
 
       系统故障
        系统故障是指硬件故障、软件(如DBMS、OS或应用程序)漏洞的影响,导致丢失了内存中的信息,影响正在执行的事务,但未破坏存储在外存上的信息。这种情况称为故障-停止假设(fail-stop assumption)。
        系统故障中止了事务的执行过程,破坏了事务的原子性,由于缓冲区中的内容可能部分已写入数据库,系统重启后数据库可能处于不一致状态。
 
       项目管理
        构建嵌入式系统是一项复杂的任务,尤其是涉及到很多人员共同长期工作的时候。为了使嵌入式项目开发获得成功,必须对系统开发项目的工作范围、花费的工作量(成本)、可能遇到的风险、进度的安排、要实现的任务、经历的里程碑以及需要的资源(人、硬/软件)等做到心中有数,而项目管理可以提供这些信息。项目管理的过程一般包括初启、计划、执行、监控、结项,项目管理的范围覆盖整个系统生命周期过程。
               管理范围
               有效的项目管理集中于4P,即人员(People)、产品(Product)、过程(Process)和项目(Project)。必须将人员组织起来以有效地完成产品构建工作;必须和客户及其他利益相关者很好地沟通,以便了解产品的范围和需求;必须选择适合于人员和产品的过程;必须估算完成工作任务的工作量和工作时间,从而制订项目计划。
               “人的因素”非常重要,在所有项目中,最关键的因素是人员,涉及项目管理人员、高级管理人员、开发人员、客户和最终用户。人员能力成熟度模型(People Capability Maturity Model,PCMM)针对人员定义了以下关键实践域:人员配备、沟通与协调、工作环境、业绩管理、培训、报酬、能力素质分析与开发、个人事业发展、工作组发展以及团队精神或企业文化培育等。PCMM成熟度达到较高水平的组织,更有可能实现有效的项目管理事件。
               在制订项目计划之前,首先确定产品的目标和范围,考虑可选的解决方案,识别技术和管理上的限制。如果没有这些信息,就无法进行合理(精确)的成本估算,也无法进行有效的风险评估和适当的项目任务划分,更无法制定可管理的项目进度计划来给出意义明确的项目进展标志。确定产品的目标只是识别出产品的总体目标,而不用考虑如何实现这些目标。确定产品的范围是识别出产品的主要数据、功能和行为特性,并且应该用量化的方式界定这些特性。然后开始考虑备选解决方案,不讨论细节,使管理者与参与开发的人员根据特定的约束条件选择相对最佳的方案,约束条件有产品的交付期限、预算限制、可用人员、技术接口以及其他各种因素。
               开发过程提供了一个框架,一小部分框架活动适用于所有的项目,多种不同的任务集合使得框架活动适合于不同项目的特性和项目团队的需求。普适性活动(如质量管理、配置管理、测量等)覆盖了过程模型,独立于任何一个框架活动,且贯穿于整个过程之中。
               为了成功地管理项目,需要有计划、可控制,这样才能管理复杂的系统开发;需要了解可能会出现的各类问题以便加以避免。可以采用的方法有:
               (1)在正确的基础上开始工作。
               (2)保持动力。
               (3)跟踪进度。
               (4)做出正确的决策。
               (5)进行事后分析。
               成本估算
               系统开发成本估算主要指系统开发过程中所花费的工作量及相应的代价。为了使开发项目能够在规定的时间内完成,而且不超过预算,成本预算和管理控制是关键。项目开发成本的估算主要靠分解和类推的手段进行。分解技术是将项目分解成一系列较小的、容易理解的问题进行估算。常用的分解技术有:基于问题的估算、基于代码行(LOC)估算、基于功能点(FP)的估算、基于过程的估算、基于用例的估算。选择或结合使用分解技术,进行成本估算。基本的成本估算方法有如下几种。
               (1)自顶向下估算方法。估算人员参照以前完成的项目所耗费的总成本(或总工作量)来推算将要开发的系统的总成本(或总工作量),然后把它们按阶段、步骤和工作单元进行分配。
               自顶向下估算方法的主要优点是对系统级工作的重视,所以估算中不会遗漏集成、配置管理等系统级事务的成本估算,且估算工作量小、速度快。其缺点是不清楚低级别上的技术性困难,而这些困难将会使成本上升。
               (2)自底向上估算方法。自底向上估算方法是将待开发的系统细分,分别估算每一个子任务所需要的开发工作量,然后将它们加起来,得到系统的总开发量。这种方法的优点是对每一部分的估算工作交给负责该部分工作的人来做,所以估算较为准确。其缺点是缺少对各项子任务之间相互联系所需要工作量和与开发有关的系统级工作量的估算,因此预算往往偏低。
               (3)差别估算方法。差别估算方法是将开发项目与一个或多个已完成的类似项目进行比较,找出与某个相类似项目的若干不同之处,并估算每个不同之处对成本的影响,导出开发项目的总成本。该方法的优点是可以提高估算的准确度,缺点是不容易明确“差别”的界限。
               除以上方法外,还有许多方法,大致可分为三类:专家估算法、类推估算法和算式估算法。
               (1)专家估算法。该方法依靠一个或多个专家对要求的项目做出估算,其精确性取决于专家对估算项目的定性参数的了解和他们的经验。
               (2)类推估算法。在自顶向下的方法中,它是将估算项目的总体参数与类似项目进行直接比较得到结果;在自底向上方法中,类推是在两个具有相似条件的工作单元之间进行。
               (3)算式估算法。专家估算法和类推估算法的缺点在于它们依靠带有一定盲目性和主观性的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响,用于估算的方法有两种基本类型:由理论导出和由经验导出。
               典型的成本估算模型主要有动态多变量普特南(Putnam)模型和层次结构的结构性成本模型(Constructive Cost Model,COCOMO)的升级模型COCOMOII等。普特南模型基于软件方程,它假设在软件开发的整个生命周期中有特定的工作量分布。COCOMOII模型层次结构中有三种不同的估算选择:对象点、功能点和源代码行。
               风险分析
               新的系统建立时,总是存在某些不确定性。例如,用户要求是否能确切地被理解?在项目最后结束之前要求实现的功能能否建立?是否存在目前仍未发现的技术难题?在项目出现严重延期时是否会发生一些变更?等等。风险是潜在的,需要识别、评估发生的概率、估算其影响、并制定实际发生时的应急计划。
               风险分析在项目管理中具有决定性作用。当在软件工程的环境中考虑风险时,主要关注以下三个方面。一是关心未来。风险是否会导致项目失败;二是关心变化。用户需求、开发技术、目标机器以及所有其他与项目有关的实体会发生什么变化;三是必须解决需要做出选择的问题,即应当采用什么方法和工具,应当配备多少人力,在质量上强调到什么程度才满足要求等。
               风险分析实际上是贯穿软件工程中的一系列风险管理步骤,其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。
               进度管理
               进度安排包括把一个项目所有的工作分解为若干个独立的活动,并描述这些活动之间的依赖关系,估算完成这些活动所需的工作量,分配人力和其他资源,制定进度时序。进度的合理安排是如期完成软件项目的重要保证,也是合理分配资源的重要依据,因此进度安排是管理工作的一个重要组成部分。有两种安排软件开发项目进度的方式:
               (1)系统最终交付日期已经确定,系统开发部门必须在规定期限内完成;
               (2)系统最终交付日期只确定了大致的年限,最后交付日期由软件开发部门确定。
               进度安排的常用图形描述方法有Gantt图(甘特图)和PERT(Program Evaluation&Review Technique,项目计划评审技术)图。
               (1)Gantt图。Gantt图中横坐标表示时间(如时、天、周、月、年等),纵坐标表示任务,图中的水平线段表示一个任务的进度安排,线段的起点和终点对应在横坐标上的时间分别表示该任务的开始时间和结束时间,线段的长度表示完成该任务所持续的时间。当日历中同一时段中存在多个水平条时,表示任务之间的并发。下图所示的Gantt图描述了三个任务的进度安排。该图表示:任务1首先开始,完成它需要12周时间;任务2在2周后开始,完成它需要18周;任务3在12周后开始,完成它需要10周。
               
               Gantt图实例
               Gantt图能清晰地描述每个任务从何时开始,到何时结束,任务的进展情况以及各个任务之间的并行性;但是它不能清晰地反映出各任务之间的依赖关系,难以确定整个项目的关键所在,也不能反映计划中有潜力的部分。
               (2)PERT图。PERT图是一个有向图,其基本符号如下图所示。
               
               PERT图的基本符号
               PERT图中的有向弧表示任务,可以标上完成该任务所需的时间,图中的结点表示流入结点的任务已结束,并开始流出结点的任务,这里把结点称为事件。只有当流入该结点的所有任务都结束时,结点所表示的事件才出现,流出结点的任务才可以开始。事件本身不消耗时间和资源,它仅表示某个时间点。每个事件有一个事件号及出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始;最迟时刻表示从该事件出发的任务必须在此时刻之前开始,否则整个工程就不能如期完成。每个任务还可以有一个松弛时间(slack time),表示在不影响整个工期的前提下,完成该任务有多少机动时间。为了表示任务间的关系,图中还可以加入一些空任务(用虚线有向弧表示),完成空任务的时间为0。
               PERT图的一个实例如下图所示,该图所表示的工程可分为12个任务,事件号1表示工程开始,事件号11表示工程结束(完成所有任务需要23个时间单位)。松弛时间为0的任务构成了完成整个工程的关键任务,其事件流为1→2→3→4→6→8→10→11,也就是说,这些任务不能拖延,否则整个工程就不能在23个时间单位内完成。
               
               PERT图示例
               PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间,还给出了任务之间的关系,即哪些任务完成后才能开始另外一些任务,还可以找出如期完成整个工程的关键任务。任务的松弛时间则反映了完成任务时可以推迟其开始时间或延长其所需完成的时间。PERT图不能反映任务之间的并行关系。
 
       信息安全
        信息安全的5个基本要素为机密性、完整性、可用性、可控性和可审查性。
        (1)机密性。确保信息不暴露给未受权的实体或进程。
        (2)完整性。只有得到允许的人才能修改数据,并能够判别出数据是否已被篡改。
        (3)可用性。得到授权的实体在需要时可访问数据。
        (4)可控性。可以控制授权范围内的信息流向及行为方式。
        (5)可审查性。对出现的安全问题提供调查的依据和手段。
        随着信息交换的激增,安全威胁所造成的危害越来越受到重视,因此对信息保密的需求也从军事、政治和外交等领域迅速扩展到民用和商用领域。所谓安全威胁,是指某个人、物、事件对某一资源的机密性、完整性、可用性或合法性所造成的危害。某种攻击就是威胁的具体实现。安全威胁分为两类:故意(如黑客渗透)和偶然(如信息发往错误的地址)。
        典型的安全威胁举例如下表所示。
        
        典型的安全威胁
   题号导航      2014年下半年 信息系统监理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第4题    在手机中做本题