|
|
知识路径： > 嵌入式系统的项目开发与维护知识 > 系统运行和维护知识 > 系统维护 >
|
被考次数：1次
被考频率：低频率
总体答错率：42%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：4个
|
|
|
|
|
系统维护主要是指在系统已经交付使用之后，为了改正错误或根据需求变化或硬件环境的变化对已交付并投入运行的系统进行部分或全部的修改，即系统在交付使用后对所做的一切改动。
|
|
|
|
|
|
系统的可维护性可以定性的定义为：维护人员理解、改正、改动和改进这个软件的难易程度。提高可维护性是开发软件系统所有步骤的关键目的，系统是否能被很好地维护，可用系统的可维护性这一指标来衡量。提高可维护性的方法包括建立明确的软件质量目标、利用先进的软件开发技术和工具、建立明确的质量保证工作、选择可维护的程序设计语言、改进程序文档。
|
|
|
|
|
|
（1）可理解性。指别人能理解系统的结构、界面、功能和内部过程的难易程度。模块化、详细设计文档、结构化设计和良好的高级程序设计语言等，都有助于提高可理解性。
|
|
|
|
（2）可测试性。诊断和测试的容易程度取决于易理解的程度。好的文档资料有利于诊断和测试，同时，程序的结构、高性能的测试工具以及周密计划的测试工序也是至关重要的。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在系统维护时，应该充分利用在系统测试阶段保存下来的测试用例。
|
|
|
|
（3）可修改性。诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模块的耦合、内聚、作用范围与控制范围的关系等，都对可修改性有影响。
|
|
|
|
|
|
文档是软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档显得非常重要。
|
|
|
|
软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。
|
|
|
|
可维护性是所有软件都应具有的基本特点，必须在开发阶段保证软件具有可维护的特点。在软件工程的每一个阶段都应考虑并提高软件的可维护性，在每个阶段结束前的技术审查和管理复查中，应该着重对可维护性进行复审。
|
|
|
|
在系统分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注解并指明，并且指出软件的可移植性问题以及可能影响软件维护的系统界面；在系统设计阶段的复审期间，应该从容易修改、模块化和功能独立的目的出发，评价软件的结构和过程；在系统实施阶段的复审期间，代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。在完成了每项维护工作之后，都应该对软件维护本身进行认真的复审。
|
|
|
|
|
|
维护应该针对整个软件配置，不应该只修改源程序代码。如果对源程序代码的修改没有反映在设计文档或用户手册中，可能会产生严重的后果。每当对数据、软件结构、模块过程或任何其他有关的软件特点作了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。在以后的维护工作中很可能因文档不完全符合实际而不能正确理解软件，从而在维护中引入过多的错误。
|
|
|
|
|
|
系统维护主要包括硬件设备的维护、应用软件的维护和数据的维护。
|
|
|
|
|
|
硬件的维护应由专职的硬件维护人员来负责，主要有两种类型的维护活动，一种是定期的设备保养性维护，保养周期可以是一周或一个月不等，维护的主要内容是进行例行的设备检查与保养，易耗品的更换与安装等；另一种是突发性的故障维护，即当设备出现突发性故障时，由专职的维修人员或请厂方的技术人员来排除故障，这种维修活动所花时间不能过长，以免影响系统的正常运行。
|
|
|
|
|
|
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改。修改时应充分利用源程序，修改后要填写程序修改登记表，并在程序变更通知书上写明新老程序的不同之处。
|
|
|
|
|
|
（1）正确性维护。是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。这方面的维护工作量要占整个维护工作量的17%～21%。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随时进行；而有的错误非常重要，甚至影响整个系统的正常运行，其维护工作必须制订计划，进行修改，并且要进行复查和控制。
|
|
|
|
（2）适应性维护。是指使应用软件适应信息技术变化和管理需求变化而进行的修改。这方面的维护工作量占整个维护工作量的18%～25%。由于目前计算机硬件价格不断下降，各类系统软件层出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求；企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。
|
|
|
|
（3）完善性维护。这是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，还包括对处理效率和编写程序的改进，这方面的维护占整个维护工作的50%～60%，比重较大，也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外，还要注意将相关的文档资料加入到前面产生的相应文档中去。
|
|
|
|
（4）预防性维护。为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新功能，以使应用系统适应各类变化而不被淘汰。这方面的维护工作量占整个维护工作量的4%左右。
|
|
|
|
|
|
（1）程序维护。为了改正错误或改进效率而改写一部分或全部程序，通常充分利用源程序。
|
|
|
|
（2）数据维护。对文件或数据中的记录进行增加、修改和删除等操作，通常采用专用的程序模块。
|
|
|
|
（3）代码维护。为了适应用户环境的变化，对代码进行变更，包括修订、新设计、添加和删除等内容。
|
|
|
|
（4）硬件设备维护。为了保证系统正常运行，应保持计算机及外部设备的良好运行状态。如建立相应的规章制度、定期检查设备、保养和杀病毒。
|
|
|
|
|
|
要强调的是，系统的修改往往会“牵一发而动全身”。程序、文件、代码的局部修改都可能影响系统的其他部分。因此，系统的维护工作应有计划有步骤的统筹安排，按照维护任务的工作范围、严重程度等诸多因素确定优先顺序，制定出合理的维护计划，然后通过一定的批准手续实施对系统的修改和维护。
|
|
|
|
|
|
（1）提出维护或修改要求。操作人员或业务领导用书面形式向系统维护工作的主管人员提出对某项工作的修改要求。这种修改要求一般不能直接向程序员提出。
|
|
|
|
（2）领导审查并做出答复，如同意修改则列入维护计划。系统主管人员进行一定的调查后，根据系统的情况和工组人员的情况，考虑这种修改是否必要、是否可行，做出是否修改、何时修改的答复。如果需要修改，则根据优先程度的不同列入系统维护计划。计划的内容应包括维护工作的范围、所需资源、确认的需求、维护费用、维护进度安排以及验收标准等。
|
|
|
|
（3）领导分配任务，维护人员执行修改。系统主管人员按照计划向有关的维护人员下达任务，说明修改的内容、要求、期限。维护人员在仔细了解原系统的设计和开发思路的情况下对系统进行修改。
|
|
|
|
（4）验收维护成果并登记修改信息。系统主管人员组织技术人员对修改部分进行测试和验收。验收通过后，将修改的部分嵌入系统，取代旧的部分。维护人员登记所做的修改，更新相关的文档，并将新系统作为新的版本通报用户和操作人员，指明新的功能和修改的地方。
|
|
|
|
维护的目的是为了延长系统的寿命并让其创造更多的价值。但每修改一次，潜伏的错误就可能增加一次。这种因修改而造成的错误或其他不希望出现的情况称为维护的副作用。维护的副作用有编码副作用、数据副作用和文档副作用。
|
|
|
|
（1）编码副作用。在使用程序设计语言修改源代码时可能引入错误。例如，删除或修改一个子程序；修改文件的打开或关闭；把设计上的改变翻译成代码上的改变等。为了避免这类错误，要在修改工作完成后进行测试，直至确认和复查无错为止。
|
|
|
|
（2）数据副作用。数据副作用是修改软件信息结构导致的结果。例如，重新定义局部或全局的常量；增加或减少一个数组；重新初始化控制标志或指针等。为了避免这类错误，一是要有严格的数据描述文件，即数据字典系统；二是要严格记录这些修改并进行修改后的测试工作。
|
|
|
|
（3）文档副作用。对数据流、软件结构、模块逻辑或任何其他有关特性进行修改时，必须对相关的技术文档进行相应修改。如果对可执行软件的修改没有反映在文档中，就会产生文档副作用。例如，修改交互输入的顺序或格式没有正确地记入文档中；过时的文档内容、索引和文本可能造成冲突等。为了避免这类错误，要在系统交付之前对整个系统配置进行评审。
|
|
|
|
总之，系统维护工作是信息系统运行阶段的重要工作内容，必须予以充分的重视。维护工作做得越好，信息系统的作用才能够得以充分发挥，信息系统的寿命也就越长。
|
|
|
|
|
|
系统维护的技术可以分为两大类：面向维护的技术和维护支援的技术。面向维护的技术是在软件开发阶段用来减少错误、提高软件可维护性的技术，它涉及软件开发的所有阶段。维护支援的技术是在软件维护阶段用来提高维护的效率和质量的技术。
|
|
|
