全国计算机四级考试复习纲要-第五章
全国计算机等级考试考试采用全国统一命题，统一考试的形式。每年安排三次考试。一般安排在3月、9月和12月考试，其中3月份和9月份考试开考全部级别全部科目，12月份考试开考一、二级的全部科目。下面小编给大家到来了全国计算机四级考试第五章考试要点，希望能帮到大家!
全国计算机四级考试第五章考试要点
自从1968年首次提出软件工程一词以来，软件工程已成为计算机软件的一个重要分支和研究方向。软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。其目的是提高软件生产率、提高软件质量、降低软件成本。
一、软件工程基本概念
早期的软件主要指程序。程序的开发采用个体工作方式，开发工作主要依赖于开发人员的个人技能和程序设计技巧。当时的软件通常缺少与程序有关的文档，软件开发的实际成本和进度往往与预计的相差甚远，软件的质量得不到保证，开发出来的软件常常不能使用户满意。随着计算机应用的需求不断增长，软件的规模也越来越大，然而软件开发的生产率远远跟不上计算机应用的迅速增长。此外，由于软件开发时缺少好的方法指导和工具辅助，同时又缺少有关的文档，使得大量已有的软件难以维护。上述这些问题严重地阻碍了软件的发展，20世纪60年代中期，人们把上述软件开发和维护中的各种问题称为“软件危机”。1968年在德国召开的NATO会议上，首次提出了“软件工程”一词，希望用工程化的原则和方法来克服软件危机。在此以后，人们开展了软件开发模型、开发方法、工具与环境的研究，提出了瀑布模型、演化模型、螺旋模型、喷泉模型等开发模型，出现了面向数据流方法、面向数据结构的方法、面向对象方法等开发方法，以及一批CASE(computer aided software engineering)工具和环境。
(一) 软件生存周期
如同人的一生要经历婴儿期、少年期、老年期直至死亡这样一个全过程一样，任何一个软件产品或软件系统也都要经历软件定义、软件开发、软件维护直至被淘汰这样一个全过程，我们把软件的这一全过程称为软件生存周期。软件定义、软件开发、软件维护等阶段还可分为若干个阶段，每个阶段相对独立又彼此有联系，上一阶段的工作结果是下一阶段工作的依据，下一阶段是上一阶段的进化，它更接近于问题的解。
1.软件定义
软件定义阶段主要解决的问题是待开发的软件要“做什么”，也就是要确定软件的处理对象，软件与外界的接口，软件的功能和性能，界面以及有关的约束和限制。软件定义阶段通常可分成系统分析、软件项目计划、需求分析等阶段。
(1)系统分析这里讲的系统是指计算机系统，包括计算机硬件、软件和使用计算机的人。系统分析的任务是确定待开发软件的总体要求和适用范围，以及与之有关的硬件、支撑软件的要求。系统分析阶段的参加人员有用户、项目负责人、系统分析员。该阶段产生的文档可合并在软件项目计划阶段的文档(项目计划书)中。
(2)软件项目计划软件项目计划的任务是确定待开发软件的目标，对其进行可行性分析，并对资源分配、进度安排等做出合理的计划。软件项目计划阶段的参加人员有用户、项目负责人、系统分析员。该阶段所产生的文档有可行性分析报告、项目计划书。
(3)需求分析需求分析的任务是确定待开发软件的功能、性能、数据、界面等要求，从而确定系统的逻辑模型。需求分析阶段的参加人员有用户、项目负责人系统分析员。该阶段产生的文档有需求规约(requirements specification)，习惯上称它为需求规格说明书。
2.软件开发
软件开发阶段主要解决的问题是该软件“怎么做”，包括数据结构和软件结构的设计，算法设计，编写程序，测试，最后得到可交付使用的软件。软件开发阶段通常可分成软件设计、编码、软件测试等阶段。
(1)软件设计软件设计通常还可分成概要设计和详细设计。概要设计的任务是模块分解，确定软件的结构，模块的功能和模块间的接口，以及全局数据结构的设计。详细设计的任务是设计每个模块的实现细节和局部数据结构的设计。概要设计阶段的参加人员有系统分析员和高级程序员，详细设计阶段的参加人员有高级程序员和程序员。设计阶段产生的文档有设计规约(design specification)，也称为设计说明书，它也可分为概要设计说明书和详细设计说明书。根据需要还可产生数据说明书和模块开发卷宗。
(2)编码编码的任务是用某种程序语言为每个模块编写程序。编码阶段的参加人员有高级程序员和程序员，产生的文档有程序清单。
(3)软件测试软件测试的任务是发现软件中的错误，并加以纠正。软件测试阶段的参加人员通常由另一部门(或单位)的高级程序员或系统分析员承担，该阶段产生的文档有软件测试计划和软件测试报告。
3.软件维护
软件开发阶段结束后，软件即可交付使用。软件的使用通常要持续几年甚至几十年，在整个使用期间，都可能因为某种原因而修改软件，这便是软件维护。引起修改软件的原因主要有三种:一是在软件运行过程中发现了软件中隐藏的错误而修改软件;二是为了适应变化了的环境而修改软件;三是为修改或扩充原有软件的功能而修改软件。因此软件维护的任务就是为使软件适应外界环境的变化、实现功能的扩充和质量的改善而修改软件。软件维护阶段的参加人员是维护人员，该阶段产生的文档有维护计划和维护报告。目前，软件生存周期各阶段的划分尚不统一，有的分得粗些，有的分得细些。许多场合软件开发阶段都是从需求分析阶段开始的。本书中，我们也将需求分析看作为软件开发的开始阶段。
(二) 软件开发模型
为了指导软件的开发，用不同的方式将软件生存周期中的所有开发活动组织起来，形成不同的软件开发模型。常见的软件开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。瀑布模型如下图所示，它是1970年由W.Royce提出的。该模型给出了软件生存周期各阶段的固定顺序，上一阶段完成后才能进入到下一阶段，整个过程就像流水下泻，故称之为瀑布模型。图中的虚线部分表示在某一阶段发现错误时，其错误可能是由上一阶段造成的，因此开发过程可能要反馈到上一阶段。在瀑布模型中，各阶段结束后，都要进行严格的评审。
(三) 软件开发方法
软件开发过程模型规定软件开发活动的组合应用方式，要保证开发活动的高质量，还需要有相应的软件开发方法作为技术支持。近10年来，软件工作者研制出了许多工程化的软件开发方法，例如70年代初提出的用于编写程序的结构化程序设计方法，确实起到了提高效率，减少错误的效果。但是70年代中期，软件工作者认识到编写程序仅仅是软件开发的一个环节，而合理地建立系统结构比编定程序更为重要。所以研究的重点前移到设计阶段，出现了设计阶段的结构化设计(SD)方法和JACKSON等方法，到了70年代后期，人们又发现事先对用户的要求进行分析更为重要，故又把重点前移到分析阶段。出现了用于分析阶段的结构化分析(SA)方法、结构化分析与设计技术(SADT)等。随着计算机技术的迅速发展，在80年代初期的实时、并发和网络等软件的开发过程中，特别是在第五代计算机研究工作中，又提出了面向对象的设计方法。现在流行的方法有多种，它们的适用范围也各不相同。有的适用于一般的数据处理系统，如SA、SD(两者统称为结构化分析与设计方法，即Yourdon方法)、JACKSON方法;有的适用于大型的复杂系统，如SADT技术;有的适用于实时事务处理系统，如FSM方法;有的适用于并发软件系统，如PETRI网方法;作为90年代代表作的面向对象方法，其应用已几乎遍布各个领域。这些方法除了适用范围不同外，方法形成的基础、处理规则和对所开发软件风格的要求等都各有侧重。用什么方法来说明用户的要求、用什么方法来设计软件以及用什么方法对软件进行测试和维护，直接影响所开发软件的质量。
(四) 软件开发工具
早期的软件开发除了一般的程序设计语言外尚缺少工具的支持，致使编程工作量大，质量和进度却难以保证，导致人们将很多的精力和时间花费在程序的编制和调试上;相比之下，在更重要的软件的需求和设计上反而得不到必要的精力和时间投入。软件开发工具的发展促进了软件开发的高速度和高质量。工具的发展是从单项工具的开发逐步走向集成的工具发展的。同时，软件开发方法的有效应用也必须得到相应工具的支持，否则方法将难以有效的实施。工具的完善和发展将促进软件开发的进步和完善。原型化方法的实施基础就是得到了开发工具的支持。快速原型化之所以能够实现的基础就是原型化人员在快速建模时得到了工具的支持，否则原型化方法是无法实施的。
(五) 软件开发环境
软件工程环境或称软件开发环境是全面支持软件开发全过程的软件工具集合。这些软件工具按照一定的方法或模式组合起来，并能支持软件开发生命周期的各个阶段和各项任务的完成。CASE，即计算机辅助软件工程环境是当前软件开发环境中富于特色的研究工作和发展方向，它的成功将最大限度地降低软件工程的技术难度并使软件开发的质量得到保证。
二、结构化生命周期方法
结构化分析与设计方法在软件工程中应用已很普遍，并且越来越成熟。有许多大、中型项目都采用了这种方法进行开发并取得了显著的成果。按B.W.Boehm的描述，瀑布模型的的软件生命周期可划分七个阶段:系统需求分析、软件需求分析、概要分析、详细设计、编码、测试和运行维护。
(一) 系统需求
“系统需求”包括:问题定义、可行性研究及软件计划。
1.问题定义
软件开发的第一步就是进行问题定义。问题定义阶段必须回答的关键问题:“软件要解决的问题是什么?”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最常被忽视的一个步骤。这里所说的问题，就是指用户的基本要求。说得通俗些，问题定义实际上就是了解用户到底要建立什么系统，并确定分析员下一步应该做什么。因此，问题定义的来源是用户。通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。这一阶段的分析员应尽可能站在较高的角度去抽象、概括所要干的事情，不要拘泥于问题实现的细节。尽管用户可能总是习惯于这样做，但分析员在这一阶段必须超脱出来，居高临下鸟瞰系统的全貌。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。当用户的要求不是很多并且不太复杂时，一两个分析员用上一两天就可以完成这一工作了。但当系统比较大，且复杂时，恐怕就要组织一个问题定义小组，花上一两个星期，甚至数月来定义用户的问题。如果分析员和用户及使用部门的负责人对所要解决的问题取得完全一致的看法，而且使用部门的负责人同意开发工程继续进行下去，那么开发工程将转入生命周期的下一个阶段———可行性研究。
2.可行性研究
并不是所有问题都有简单明显的解决办法，事实上，许多问题不能在预定的系统规模之内解决。如果问题没有可行的解，那么花费在这项开发工程上的任何时间、资源、人力和经费和都是无谓的浪费。可行性研究的目的在于用最小的代价确定在问题定义阶段所确定的系统的目标和规模是否现实，所确定的问题是否可以解决，系统方案在经济上、技术上和操作上是否可以接受。可行性研究着重对如下具体方案考虑:
(1)经济可行性。估计开发费用以及新系统可能带来的收益，将两者进行权衡，看结果是否可以接受。
(2)技术可行性。对要求的功能、性能以及限制条件进行分析，是否能够做成一个可接受的系统。所考虑的因素通常还应包括开发的风险，是否能够得到需要的软件和硬件资源和一个熟练的有能力的开发队伍，与系统开发有关的技术是否足以支持系统的研制。技术可行性的估计，需要有经验的人员去完成。
(3)操作可行性。判断系统的操作方式在该用户组织内是否可行。分析、设计人员应以新系统的目标和作用范围为依据提出一种以上的设计方案，从技术可行性、经济可行性、操作可行性等方面进行比较，并选择出综合最优的方案。根据可行性研究结果要做出的决定是:是否继续按预定目标进行这项开发工程，可行性分析人员必须清楚地表明他对这个关键性决定的建议。如果认为值得继续进行这项开发工程，则应提供选择一种最好的解法并说明理由。可行性分析是在问题的目标和约束之间的一种权衡，还可能有的结果则是修改目标或放宽约束。
3.软件计划
分析人员应该为推荐的系统草拟一份软件计划，其中描述的是为了成功地进行一个软件项目，其所需要做的工作、需要的资源、需要的工作量和费用以及应遵循的进度安排。软件计划由两项任务组成:分析和估算。分析是对系统内各软件功能的界限的划定。估算是指根据已有的定性数据和已往的经验对系统开发的资源、费用和进度进行定量的估计。软件开发项目的进度安排可以从两种观点来考虑:一是项目的交付日期已定，负责开发工作的软件机构被限制在一个规定的时间范围内分配其工作量。二是项目最后的交付日期由软件机构自已确定，可以从最佳的利用各种资源的角度出发来分配工作量，项目最后的交付日期经过对软件各部分仔细分析后才确定。在多数项目中，遇到的往往是第一种情况。软件计划的阅读者可以包括软件主管部门、用户和技术人员。所确定的成本与进度可供主管部门复审。它同时也给出了整个软件生命周期的基本成本预算的进度安排。
(二) 软件需求分析
软件需求分析工作是软件生存期中重要的一步，也是决定性的一步。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。软件需求分析工作也是一个不断认识和逐步细化的过程。该过程将软件设计阶段所确定的软件范围(工作域)逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决方法。制定软件的需求规格说明不只是软件开发人员的事，用户也起着至关重要的作用。用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而软件分析人员则要认真了解用户的要求，细致地进行调查分析，把用户“做什么”的要求最终转换成一个完全的、精细的软件逻辑模型并写出软件的需求规格说明，准确地表达用户的要求。
1.软件需求分析任务
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节。定义软件的其他有效性需求。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示。在软件完成后，制定的软件需求规格说明还要为评价软件质量提供依据。需求分析阶段研究的对象是软件项目的用户要求。需要注意的是，必须理解用户的各项要求，但又不能全盘接受所有的要求。因为并非所有用户要求都是合理的。对其中模糊的要求还需要澄清，然后才能决定是否可以采纳。对于那些无法实现的要求应向用户做充分的解释，以求得谅解。准确地表达所接受的用户要求，是需求分析的另一个重要方面。只有经过确切描述的软件需求才能成为软件设计基础。通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中。它是软件实现的基础。但是目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。与物理模型不同，逻辑模型忽视实现机制与细节，只描述系统要完成的功能和要处理的数据。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
(1)获得当前系统的物理模型。当前系统可能是需要改进的某个已在计算机运行的数据处理系统，也可能是一个人工的数据处理过程。在这一步首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。
(2)抽象出当前系统的逻辑模型。在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质，从而从当前系统的物理模型抽象出当前系统的逻辑模型。在物理模型中有许多物理因素，随着分析工作的深入，有些非本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素即可获得反映系统本质的逻辑模型。
(3)建立目标系统的逻辑模型。分析目标系统与当前系统逻辑上的差别，明确目标系统统到底要“做什么”，从当前系统的逻辑模型导出目标系统的逻辑模型。(4)为了对目标系统做完整的描述，还需要对得到的逻辑模型做一些补充。①说明目标系统的用户界面。根据目标系统所处的应用环境及它与外界环境的相互关系，研究所有可能与它发生联系和作用的部分，从而决定人机界面。②说明至今尚未详细考虑的细节。这些细节包括系统的启动和结束、出错处理、系统的输入输出和系统性能方面的需求。③其他。例如系统的其他必须满足的性能和限制等等。
2.需求分析的过程
需求分析阶段的工作，可以分成以下4个方面:对问题的识别、分析与综合、制定规格说明和评审。
(1)问题识别首先系统分析人员要研究计划阶段产生的可行性分析报告(如果有的话)和软件项目实施计划。主要是从系统的角度来理解软件并评审用于产生计划估算的软件范围是否恰当。确定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。也就是要求所开发软件做什么，做到什么程度。这些需求包括:
功能需求:列举出所开发软件在职能上应做什么。这是最主要的需求。
性能需求:给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。
环境需求:这是对软件系统运行时所处环境的要求。例如在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。在软件方面，采用什么支持系统运行的系统软件(指操作系统、网络软件、数据库管理系统等)。在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等。
可靠性需求:各种软件在运行时，失效的影响各不相同。在需求分析时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求，对于那些重要的软件，或是运行失效会造成严重后果的软件，应当提出较高的可靠性要求，以期在开发的过程中采取必要的措施，使软件能够高度可靠地稳定运行，避免因运行事故而带来的损失。
安全保密要求:工作在不同环境的软件对其安全，保密的要求显然是不同的。应当把这方面的需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全方面的性能得到必要的保证。
用户界面需求:软件与用户界面的友好性是用户能够方便、有效、愉快地使用该软件的关键之一。从市场角度来看，具有友好用户界面的软件有很强的竞争力。因此，必须在需求分析时，为用户界面细致地规定达到的要求。
资源使用需求:这是指所开发软件运行时所需的数据、软件、内存空间等各项资源外，软件开发时所需的人力、支撑软件、开发设备等则属于软件开发的资源，需要在需求分析时加以确定。
软件成本消耗与开发进度需求:在软件项目立项后，要根据合同规定，对软件开发的进度和步骤的费用提出要求，作为开发管理的依据。
预先估计以后系统可能达到的目标。这样，在开发过程中，可对系统将来可能扩驻与修改做准备。一旦需要时，就比较容易进行补充和修改。
功能性需求是人们普遍关注的，但常常忽视对非功能性需求的分析。其实非功能性需求并不是无关紧要的，它们涉及到的方面多而广，因而容易被忽略。如果在进行需求分析之前没有做过可行性分析，那么补充完成这部分工作往往是必要的。从问题定义和调查研究入手，与用户密切联系，详细了解问题提出的背景，弄清要解决什么问题。然后从软件系统特性和用户目标出发，做市场调查和现场考察。仔细收集信息之后进行数据分析和功能分析，建立系统的高层逻辑模型，再进一步做成本/效益分析。最后提交一份可行性分析报告，从技术、经济、社会效应等方面论证可行性，以确认软件开发的目标是否可行。问题识别的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责人在此过程中起协调人的作用。分析员通过这种通信途径与各方商讨，以便能满足用户的要求。
(2)分析与综合需求分析的第二步工作是问题分析和方案的综合。分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。依据功能需求、性能需求、运行特性和设计上的限制分析它们是否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其不合理的部分，增加其需要的部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。在这个步骤中，分析和综合工作反复地进行。在对现行问题和期望的信息(输入和输出)进行分析的基础上，分析员开始综合出一个或几个解决方案，然后检查这些方案是否符合软件计划中规定的范围等等，再进行修改。总之，对问题进行分析和综合的过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的规格说明为止。常用的分析方法有面向数据流的结构化分析方法(简称SA)、面向数据结构的Jackson方法(简称JSD)、面向对象的分析方法(简称OOA)等，以及用于建立动态、模型的状态迁移图或Petri网等。这些方法都采用图文结合的方式，可以直观地描述软件的逻辑模型。
(3)编制需求分析的文档已经确定的需求应当得到清晰准确的描述。通常把描述需求的文档叫做软件需求规格说明书。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册，着重反映被开发软件的用户界面和用户使用的具体要求。此外，依据在需求分析阶段对系统的进一步分析，从目标系统的精细模型出发，可以更确切地估计所开发项目的成本与进度，从而修改、完善与确定软件开发的实施计划。
(4)需求分析评审作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审的主要内容是:
系统定义的目标是否与用户的要求一致;
系统需求分析阶段提供的文档资料是否齐全;
文档中的所有描述是否完整、清晰、准确所反映用户要求;
与所在其他系统成分的重要接口是否都已经描述;
所开发项目的数据流与数据结构是否足够，确定;
所有图表是否清楚，在不补充说明时能否理解;
主要功能是否已包括在规定的软件范围之内，是否都已充分说明;
