软件工程-理论与实践课件.pptx

1、第 一 部 分 软 件 工 程 概 述 第1章 软件与软件工程1.1 软件 1.1.1 软件的概念及特点概念：计算机软件是由专业人员开发并长期维护的软件产品。完整的软件产品包括了在各种不同容量和体系结构计算机上的可执行的程序，运行过程中产生的各种结果，以及以硬复制和电子表格等多种方式存在的软件文档1.1 软件 特点：1）具有抽象性2）无明显的制造过程3）存在退化问题4）对计算机系统有着不同程度的依赖性5）尚未完全摆脱人工的开发方式6）软件本身是复杂的7）成本相当昂贵8）相当多的软件工作涉及社会因素1.1 软件 1.1.2 软件的分类1.2 软件危机 1.2.1 软件危机的表现与原因 在软件开发

2、的过程中，会经常出现一些不能按时完成任务、产品质量得不到保证、工作效率低下和开发经费严重超支等现象。计算机软件的开发、维护和应用过程中普遍出现的这一些严重的问题便是软件危机 人们对软件产品认识的不足以及对软件开发的内在规律理解的偏差是软件危机出现的本质原因。1.2 软件危机 1.2.2 软件危机的启示 软件危机给我们的最大启示，是使我们更加深刻的认识到软件的特性以及软件产品开发的内在规律。l 软件产品是复杂的人造系统，具有复杂性、不可见性和易变性，难以处理。l 个人或小组在开发小型软件时使用到的非常有效的编程技术和过程，在开发大型、复杂系统时难以发挥同样的作用。l 从本质上讲，软件开发的创造性

3、成分很大、发挥的余地也很大，很接近于艺术。它介于艺术与工程之间的某一点，并逐步向工程一段漂移，但很难发展到完全的工程。1.2 软件危机 l 计算机和软件技术的快速发展，提高了用户对软件的期望，促进了软件产品的演化，为软件产品提出了新的、更多的需求，难以在可接受的开发进度内保证软件的质量。l 几乎所有的软件项目都是新的，而且是不断变化的。项目需求在开发过程中会发生变化，而且很多原来预想不到的问题会出现，对设计和实现手段进行适当的调整是不可避免的。l“人月神化”现象生产力与人数并不成正比。1.3 软件工程 1.3.1 软件工程的概念 IEEE对软件工程的定义为：1）将系统化、严格约束的、可量化的方

4、法应用于软件的开发、运行和维护，即将工程化应用于软件 2）对1）中所述方法的研究 具体说来，软件工程是以借鉴传统工程的原则、方法，以提高质量，降低成本为目的指导计算机软件开发和维护的工程学科。它是一种层次化的技术1.3 软件工程 软件工程层次图1.3 软件工程 1.3.2 软件工程研究的内容 软件工程研究的内容主要包括以下两个部分：软件开发技术。主要研究软件开发方法、软件开发过程、软件开发工具和环境。软件开发过程管理。主要研究软件工程经济学和软件管理学。1.3 软件工程 1.3.3 软件工程目标和原则 软件工程要达到的基本目标包括：达到要求的软件功能 取得较好的软件性能 开发出高质量的软件 付

5、出较低的开发成本 需要较低的维护费用 能按时完成开发工作，及时交付使用1.3 软件工程 软件工程的7条基本原则 用分阶段的生没周期计划进行严格的管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 软件工程结果应能清楚地审查 开发小组的人员应该少而精 承认不断改进软件工程实践的必要性1.3 软件工程 1.3.4 软件工程知识体系 IEEE在2014年发布的软件工程知识体系指南中将软件工程知识体系划分为以下15个知识领域。1软件需求2软件设计3软件构建4软件测试5软件维护6软件配置管理7软件工程管理8软件工程过程9软件工程模型和方法10软件质量11软件工程职业实践12软件工程经济学1

6、3计算基础14数学基础15工程基础1.4 软件开发方法 1.4软件开发方法 软件开发方法是一种使用定义好的技术集及符号表示组织软件生产的过程，它的目标是在规定的时间和成本内，开发出符合用户需求的高质量的软件。常见的软件开发方法包括：1)结构化方法2)面向数据结构方法3)面向对象方法4)形式化方法 此外，软件开发方法还有问题分析法、可视化开发方法等。1.5 软件工程工具 软件工程的工具对软件工程中的过程和方法提供自动的或半自动的支持。可以帮助软件开发人员方便、简捷、高效地进行软件的分析、设计、开发、测试、维护和管理等工作。有效地利用工具软件可以提高软件开发的质量，减少成本，缩短工期，方便软件项目

7、的管理。软件工程工具通常有3种分类标准：1.按照功能划分2.按照支持的过程划分3.按照支持的范围划分1.5 软件工程工具 按照功能划分：功能是对软件进行分类的最常用的标准，按照功能划分，软件工程工具可分为可视化建模工具、程序开发工具、自动化测试工具、文档编辑工具、配置管理工具、项目管理工具等。按照支持的过程划分：根据支持的过程，软件工程工具可分为设计工具、编程工具、维护工具等。1.5 软件工程工具 按照支持的范围划分：根据支持的范围，软件工程工具可以分为窄支持、较宽支持和一般支持工具。窄支持工具支持软件工程过程中的特定任务，一般将其称之为工具；较宽支持支持特定的过程阶段，一般由多个工具集合而成

8、，称之为工作台；一般支持支持覆盖软件过程的全部或大部分阶段，包含多个不同的工作台，称之为环境。谢谢！第2章 软件过程2.1 软件过程概述 软件的诞生和生命周期是一个过程，我们总体上称这个过程为软件过程。软件过程是为了开发出软件产品，或者是为了完成软件工程项目而需要完成的有关软件工程的活动，每一项活动又可以分为一系列的工程任务。任何一个软件开发组织，都可以规定自己的软件过程，所有这些过程共同构成了软件过程过程定义了运用方法的顺序，应该交付的文档资料，为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。通常，使用生命周期模型简洁地描述软件过程。生命周期模型规定了

9、把生命周期划分为哪些阶段及各个阶段的执行顺序，因此也称为过程模型2.2 软件生命周期 2.2.1软件生命周期的概念 软件产品的生命周期是指从设计该产品的构想开始，到软件需求的确定、软件设计、软件实现、产品测试与验收、投入使用以及产品版本的不断更新，到最终该产品被市场淘汰的全过程。软件生命周期这个概念从时间的角度将软件的开发和维护的复杂过程分解为了若干个阶段，每个阶段都完成特定的相对独立的任务。2.2 软件生命周期 2.2.2传统软件生命周期的各个阶段 在传统的软件工程中，软件产品的生命周期一般可以划分为6个阶段，如图所示。传统的软件生命周期2.3 软件过程模型 在软件工程中，人们通过建立抽象的

10、软件开发模型，把软件生命周期中的各个活动或步骤安排到一个框架中，将软件开发的全过程清晰且直观地表达出来。常见的软件开发模型有很多种，这里主要介绍瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、基于组件的开发模型、统一软件开发过程模型以及敏捷模型与极限编程。2.3 软件过程模型 2.3.1 瀑布模型瀑布模型是一种线性的开发模型，具有不可回溯性。开发人员必须等前一阶段的任务完成后，才能开始进行后一阶段的工作，并且前一阶段的输出往往就是后一阶段的输入。由于其不可回溯性，如果在软件生命周期的后期发现并要改正前期的错误，那么需要付出很高的代价。传统的瀑布模型是文档驱动的。如图所示。2.3 软件过程

11、模型 2.3.1 瀑布模型瀑布模型的优点是过程模型简单，执行容易；缺点是无法适应变更。瀑布模型适应于具有以下特征的软件开发项目。在软件开发的过程中，需求不发生或发生很少变化，并且开发人员可以一次性获取到全部需求。否则，由于瀑布模型较差的可回溯性，在后续阶段中需求经常性的变更需要付出高昂的代价。软件开发人员具有丰富的经验，对软件应用领域很熟悉。软件项目的风险较低。瀑布模型不具有完善的风险控制机制2.3 软件过程模型 2.3.2 快速原型模型快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意

12、见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用反反复复地改进，直到原型系统满足用户的要求。2.3 软件过程模型 2.3.2 快速原型模型快速原型模型适用于具有以下特征的软件开发项目。1.已有产品或产品的原型（样品），只需客户化的工程项目2.简单而熟悉的行业或领域3.有快速原型开发工具4.进行产品移植或升级2.3 软件过程模型 2.3.3 增量模型增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提

13、交给用户，而是可以分批次进行提交。2.3 软件过程模型 增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点，增量模型具有以下优点。将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。开发顺序灵活。开发人员可以对构件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。增量模型的缺点是要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。2.3 软件过程模型 增

14、量模型适用于具有以下特征的软件开发项目。软件产品可以分批次地进行交付 待开发的软件系统能够被模块化 软件开发人员对应用领域不熟悉，难以一次性地进行系统开发 项目管理人员把握全局的水平较高2.3 软件过程模型 2.3.4 螺旋模型 螺旋模型是一种用于风险较大的大型软件项目开发的过程模型。该模型将瀑布模型与快速原型模型结合起来，并且加入了这两种模型忽略了的风险分析。它把开发过程分为制定计划、风险分析、实施工程和客户评估4种活动。螺旋模型适应于风险较大的大型软件项目的开发。它的优点是将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。但是这种模型的控制和管理较为复杂，可操作性不强，对项目管理人员

15、的要求较高。2.3 软件过程模型 2.3 软件过程模型 2.3.5 喷泉模型喷泉模型是一种过程模型，同时也支持面向对象开发。在面向对象的方法中，分析模型和设计模型采用相同的符号标示体系，各阶段之间没有明显的界限，而且常常重复、迭代地进行。“喷泉”一词体现了面向对象方法的迭代和无间隙性。迭代是指各阶段需要多次重复，例如，分析和设计阶段常常需要多次、重复进行，以更好的实现需求。无间隙性是指各个阶段之间没有明显的界限，并常常在时间上互相交叉，并行进行。喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。2.3 软件过程模型 2.3.6 基于组

16、件的开发模型基于组件的开发模型使用现有的组件以及系统框架进行产品开发。在确定需求之后，开发人员开始从现有的组件库中筛选合适的组件，并对组件功能进行分析。在对组件分析之后，开发人员可能适当修改需求来适应现有组件，也可能修改组件或寻找新的组件。组件筛选完成之后，开发人员需要根据需求设计或使用现有的成熟开发框架复用这些组件，一些无法利用现有组件的地方，则需要进行单独的开发，新开发的组件在经历时间考验之后也会加入到组件库中。最后将所有组件集成在一起，进行系统测试。基于组件的开发模型充分的体现了软件复用的思想，降低了开发成本和风险，并加快了产品开发。2.3 软件过程模型 2.3.7 统一软件开发过程模型

17、统一软件开发过程（Rational Unified Process，RUP）模型是基于UML（统一建模语言）的一种面向对象软件开发模型。它解决了螺旋模型的可操作性问题，采用迭代和增量递进的开发策略，并以用例驱动为特点，集中了多个软件开发模型的优点。RUP模型是迭代模型的一种。RUP模型的示意图如图所示。2.3 软件过程模型 图1中的纵轴以工作的内容为组织方式，表现了软件开发的工作流程。工作流程可以分为核心工作流程和核心支持工作流程。图1中的横轴以时间为组织方式，表现了软件开发的4个阶段：先启、细化、构建和产品化，每个阶段中都可能包含若干次迭代。这4个阶段按照顺序依次进行，每个阶段结束时都有一个

18、主要里程碑。阶段与里程碑的关系如图2所示。图1 统一软件开发过程模型图2 阶段与里程碑的关系2.3 软件过程模型 统一软件开发过程模型是基于迭代思想的软件开发模型。采用迭代的软件工程思想可以多次执行各个工作流程，有利于更好地理解需求、设计出合理的系统架构，并最终交付一系列渐趋完善的成果。可以说，迭代是一次完整地经过所有工作流程的过程基于统一软件开发过程模型所构造的软件系统，是由软件构件建造而成的。这些软件构件定义了明确的接口，相互连接成整个系统。在构造软件系统时，RUP采用架构优先的策略。软件架构概念包含了系统中最重要的静态结构和动态特征，架构体现了系统的总体设计。架构优先开发的原则是RUP开

19、发过程中至关重要的主题。统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。2.3 软件过程模型 2.3.8 敏捷过程与极限编程1.敏捷过程概述随着计算机技术的迅猛发展和全球化进程的加快，软件需求常常发生变化，强烈的市场竞争要求更快速的开发软件，同时软件也能够以更快的速度更新。传统的方法在开发时效上时常面临挑战，因此，强调快捷、小文档、轻量级的敏捷开发方法开始流行。敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程方法，它更强调软件开发过程中各种变化的必然性，通过团队成员之间充分的交流与沟通以及合理的机制来有效地响应变化。2.3 软件过程模型 敏捷开发开始于“敏捷软件开

20、发宣言”。在2001年2月，17位软件开发方法学家在美国犹他州召开了长达两天的会议，制订并签署了“敏捷软件开发宣言”，该宣言给出了4个价值观。(1)个体与交互高于过程和工具(2)可运行软件高于详尽的文档(3)与客户协作高于合同（契约）谈判(4)对变更及时响应高于遵循计划“敏捷联盟”为了帮助希望使用敏捷方法来进行软件开发的人们定义了12条原则。2.3 软件过程模型 2.极限编程敏捷模型包括多种实践方法，比如极限编程（eXtreme Programming，XP）自适应软件开发（Adaptive Software Development，ASD）动态系统开发方法（Dynamic System De

21、velopment Method，DSDM）、ScrumCyrstal特征驱动开发（Feature Driven Development，FDD）等下面介绍极限编程的相关内容2.3 软件过程模型 极限编程是一种实践性较强的规范化的软件开发方法，它强调用户需求和团队工作。利用极限编程方法进行软件开发实践的工程师，即使在开发周期的末期，也可以很快地响应用户需求。在团队工作中，项目经理、用户以及开发人员都有责任为提高软件产品的质量而努力。XP特别适用于软件需求模糊且容易改变、开发团队人数少于10人、开发地点集中（比如一个办公室）的场合。极限编程包含了一组相互作用和相互影响的规则和实践。在项目计划阶段

22、，需要建立合理和简洁的用户故事。在设计系统的体系架构时，可以采用CRC（Class，Responsibility，Collaboration）卡促使团队成员共同努力。代码的质量在极限编程项目中非常重要。为了保证代码的质量，可以采用结对编程以及在编码之前构造测试用例等措施。在测试方面，开发人员有责任向用户证明代码的正确性，而不是由用户来查找代码的缺陷。合理的测试用例及较高的测试覆盖率是极限编程项目测试所追求的目标。2.3 软件过程模型 2.3.9 几种模型之间的关系1瀑布模型与RUP模型之间的关系在宏观上，瀑布模型是静态模型，RUP模型是动态模型。RUP模型的每一次迭代，实际上都需要执行一次瀑布

23、模型，都要经历先启、细化、构建、产品化这4个阶段，完成瀑布模型的整个过程。在微观上，瀑布模型与RUP模型都是动态模型。瀑布模型与RUP模型在每一个开发阶段（先启、细化、构建、产品化）的内部，都需要有一个小小的迭代过程，只有进行这样的迭代，开发阶段才能做得更好。瀑布模型中有RUP模型，反过来，RUP模型中也有瀑布模型。2.3 软件过程模型 2瀑布模型与增量模型之间的关系 增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，一个模块接着一个模块地进行开发，直到开发完所有的模块。在开发每个模块时，通常都是采用瀑布模型，从分析、设计、编码和测试这几个阶段进行开发。所以，增量模型中有瀑布模型

24、，即宏观上是增量模型，微观上是瀑布模型。增量模型也体现了迭代思想，每增加一个模块，就进行一次迭代，执行一次瀑布模型，所以，增量模型本质上是迭代的。2.3 软件过程模型 3瀑布模型与快速原型模型之间的关系 快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统，在此基础上之后的每一次迭代，都可能会用到瀑布模型。快速原型模型中不但包含了迭代模型的思想，而且包含了瀑布模型的思想。2.3 软件过程模型 4瀑布模型与螺旋模型之间的关系 螺旋模型是瀑布模型和快速原型模型的结合，快速原型模型是原型模型的简化，原型模型又是迭代模型和瀑布模型的组合，这些模型之间是相互依存的、彼此有关的。螺旋模型每一次顺时

25、针方向旋转，相当于顺时针方向迭代一次，都是走完一次瀑布模型，这就是瀑布模型与螺旋模型之间的关系。实际上，瀑布模型与喷泉模型也有关系。2.3 软件过程模型 2.3.10选择软件过程模型 各种软件过程模型反映了软件生命周期表现形式的多样性。在生命周期的不同阶段也可采用不同的软件过程模型。在具体的软件开发过程中，可以选择某种软件过程模型，按照某种开发方法，使用相应的工具进行软件开发。在选择软件过程模型时需要考虑以下几点。1.符合软件自身的特性，如规模、成本和复杂性等2.满足软件开发进度的要求3.对软件开发的风险进行预防和控制4.具有计算机辅助工具的支持5.与用户和软件开发人员的知识和技能相匹配6.有

26、利于软件开发的管理和控制2.3 软件过程模型 一般来说，结构化方法和面向数据结构方法可采用瀑布模型或增量模型进行软件开发；而面向对象方法可采用快速原型模型、喷泉模型或RUP模型进行软件开发。在实际的软件开发过程中，选择软件过程模型并非是一成不变的，有时还需要针对具体的目标要求进行裁剪、修改等，从而构成完全适合开发目标要求的软件过程模型。现实中的软件系统有各种各样，软件开发方式也千差万别。对同一个问题，不同的开发组织可能选择不同的开发模型（过程模型）去解决，开发出的软件系统也不可能完全一样，但是其基本目标都是一致的，即应该满足用户的基本功能需求，否则，再好的软件系统也是没有意义的。谢谢！第二部分

27、 可行性研究与项目开发计划 第3章 可行性研究与项目开发计划3.1项目立项概述 任何一个完整的软件工程项目都是从项目立项开始的。项目立项包括项目发起、项目论证、项目审核和项目立项四个过程。在发起一个项目时，项目发起人或单位为寻求他人的支持，要以书面材料的形式递交给项目的支持者和领导，使其明白项目的必要性和可行性。项目论证过程，也就是可行性研究过程。可行性研究就是指在项目进行开发之前，根据项目发起文件和实际情况，对该项目是否能在特定的资源、时间等制约条件下完成做出评估，并且确定它是否值得去开发。项目经过可行性研究并且认为可行后，还需要报告主管领导或单位，以获得项目的进一步审核，并得到他们的支持。

28、项目通过可行性研究和主管部门的批准后，将其列入项目计划的过程，叫做项目立项。经过项目发起、项目论证、项目审核和项目立项四个过程后，一个软件工程项目就正式启动了。3.2可行性研究的任务 可行性研究需要从多个方面进行评估，主要包括：战略可行性 操作可行性 计划可行性 技术可行性 社会可行性 市场可行性 经济可行性 风险可行性3.3 技术可行性 技术可行性主要研究待开发的系统的功能、性能和限制条件，确定现有技术能否实现有关的解决方案，在现有的资源条件下实现新系统的技术风险有多大。这里的资源条件是指已有的或可以得到的软硬件资源，现有的开发项目的人员的技术水平和已有的工作基础。在评估技术可行性时，需要考

29、虑以下情况：了解当前最先进的技术，分析相关技术的发展是否支持新系统；确定资源的有效性，如新系统的软硬件资源是否具备，开发项目的人员在技术和时间上是否可行等；分析项目的开发的 技术风险，即能在给定的资源和时间等条件下，设计并实现系统的功能和性能等。3.4 操作可行性 操作可行性是对开发系统在一个给定的工作环境中能否运行或运行好坏程度的衡量。操作可行性研究决定在当前的政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等环境下，系统的操作是否可行。操作可行性往往最容易被忽视或被低估，或者认为它一定是可行的。3.5 经济可行性 成本-效益分析是可行性研究的重要内容，它用于评估基于项

30、目的经济合理性，给出项目开发的成本论证，并将估算的成本与预期的利润进行对比。一般说来，基于项目的成本由4个部分组成：购置并安装软硬件及有关设备的费用；项目开发费用；软硬件系统安装、运行和维护费用；人员的培训费用。在项目的分析和设计阶段只能得到上述费用的预算，即估算成本。在项目开发完毕并将系统交付用户运行后，上述费用的统计结果就是实际成本。3.6可行性研究的步骤 进行可行性研究的步骤不是固化的，而是根据项目的性质、特点以及开发团队的能力有所区别。一个典型的可行性研究的步骤可以归结为以下几步，其示意图如图所示。3.7 制定项目开发计划 项目开发计划的主要内容如下：(1)项目概述：说明项目的各项主要

31、工作；说明软件的功能和性能；为完成项目应具备 的条件；甲方和乙方应承担的工作、完成期限和其他限制条件；应交付的软件名称，所 使用的开发语言及存储形式；应交付的文档等。(2)实施计划：说明任务的划分，各项任务的责任人；说明项目开发进度，按阶段应完 成的任务，用图表说明每项任务的开始时间和完成时间；说明项目的预算，各阶段的费用 支出预算等。(3)人员组织及分工：说明开发该项目所需人员的类型、组成结构和数量等。(4)交付期限：说明项目应交付的日期等。谢谢！第 三 部 分 结 构 化 分 析 与 设 计 第4章 结构化分析4.1需求分析 4.1.1 需求分析的任务 为什么需要需求分析 为了开发出真正满

32、足用户需要的软件产品，明确地了解用户需求是关键。虽然在可行性研究中，已经对用户需求有了初步的了解，但是很多细节还没有考虑到。可行性研究的目的是评估系统是否值得去开发，问题是否能够解决，而不是对需求进行定义。如果说可行性分析是要决定“做还是不做”，那么需求分析就是要回答“系统必须做什么”这个问题。需求分析是一个非常重要的过程，它完成的好坏直接影响了后续软件开发的质量。4.1需求分析 1.确定系统的运行环境要求 系统运行时的硬件环境要求，如对计算机的CPU、内存、存储器、输入/输出方式、通信接口和外围设备等的要求；软件环境要求，如操作系统、数据库管理系统和编程语言等的要求。4.1需求分析 2.确定

33、系统的功能性需求和非功能性需求 需求可以分为两大类，功能性需求和非功能性需求，前者定义了系统做什么，后者定义了系统工作时的特性。功能需求是软件系统的最基本的需求表述，包括对系统应该提供的服务，如何对输入做出反应，以及系统在特定条件下的行为描述。在某些情况下，功能需求还必须明确系统不应该做什么，这取决于开发的软件类型、软件未来的用户、以及开发的系统类型。所以，功能性的系统需求，需要详细地描述系统功能特征、输入和输出接口、异常处理方法等。非功能性需求包括对系统提出的性能需求、可靠性和可用性需求、系统安全以及系统对开发过程、时间、资源等方面的约束和标准等。性能需求指定系统必须满足的定时约束或容量约束

34、，一般包括速度（响应时间）、信息量速率（吞吐量、处理时间）和存储容量等方面的需求。4.1需求分析 3.进行有效的需求分析 一般情况下，用户并不熟悉计算机的相关知识，而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。所以，开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要。有效的需求分析通常都具有一定的难度，这一方面是由于交流障碍所引起的，另一方面是由于用户通常对需求的陈述不完备、不准确和不全面，并且还可能在不断的变化。所以开发人员不仅需要在用户的帮助下抽象现有的需求，还需要挖掘隐藏的需求。此外，把各项需求抽

35、象为目标系统的高层逻辑模型对日后的开发工作也至关重要。合理的高层逻辑模型是系统设计的前提。4.1需求分析 4.在需求分析的过程中应该遵守一些原则 首先，需求分析是一个过程，它应该贯穿于系统的整个生命周期中，而不是仅仅属于软件生命周期早期的一项工作。其次，需求分析应该是一个迭代的过程。由于市场环境的易变性以及用户本身对于新系统要求的模糊性，需求往往很难一步到位。通常情况下，需求是随着项目的深入而不断变化的。所以需求分析的过程还应该是一个迭代的过程。此外，为了方便评审和后续的设计，需求的表述应该具体、清晰，并且是可测量的、可实现的。最好能够对需求进行适当的量化。比如：系统的响应时间应该低于0.5秒

36、；系统在同一时刻最多能支持30000个用户。4.1需求分析 5.需求分析的两个任务。首先，是需求分析的建模阶段，即在充分了解需求的基础上，要建立起系统的分析模型。其次，是需求分析的描述阶段，就是把需求文档化，用软件需求规格说明书的方式把需求表达出来。4.1需求分析 6.软件需求规格说明书 软件需求规格说明书是需求分析阶段的输出，它全面、清晰地描述了用户需求，因此是开发人员进行后续软件设计的重要依据。软件需求规格说明书应该具有清晰性、无二义性、一致性和准确性等特点。同时，它还需通过严格的需求验证、反复修改的过程才能最终确定。4.1需求分析 4.1.2需求分析的步骤为了准确获取需求，需求分析必须遵

37、循一系列的步骤。只有采取了合理的需求分析的步骤，开发人员才能更有效地获取需求。一般来说，需求分析分为需求获取、分析建模、需求描述和需求验证4步。以下将分步进行介绍。4.1需求分析 1)需求获取 需求获取就是收集并明确用户需求的过程。系统开发方人员通过调查研究，要理解当前系统的工作模型、用户对新系统的设想与要求。在需求获取的初期，用户提出的需求一般模糊而且凌乱，这就需要开发人员能够选取较好的需求分析的方法，提炼出逻辑性强的需求。而且不同用户的需求有可能发生冲突，对于发生冲突的需求必须仔细考虑并做出选择。获取需求的方法有多种，比如问卷调查、访谈、实地操作、建立原型等。4.1需求分析 2)分析建模

38、获取到需求后，下一步就应该对开发的系统建立分析模型了。模型就是为了理解事物而对事物做出的一种抽象，通常由一组符号和组织这些符号的规则组成。对待开发系统建立各种角度的模型有助于人们更好地理解问题。通常，从不同角度描述或理解软件系统，就需要不同的模型。常用的建模方法有数据流图、实体关系图、状态转换图、控制流图、用例图、类图、对象图等。4.1需求分析 3)需求描述 需求描述就是指编制需求分析阶段的文档。一般情况下，对于复杂的软件系统，需求阶段会产生3个文档:系统定义文档（用户需求报告）、系统需求文档（系统需求规格说明书）、软件需求文档（软件需求规格说明书）。而对于简单的软件系统而言，需求阶段只需要输

39、出软件需求文档就可以了。软件需求规格说明书主要描述软件部分的需求，简称SRS（Software Requirement Specification），它站在开发者的角度，对开发系统的业务模型、功能模型、数据模型、行为模型等内容进行描述。经过严格的评审后，它将作为概要设计和详细设计的基线。4.1需求分析 文档与软件规模的对应关系4.1需求分析 4)需求验证 需求分析的第四步是验证以上需求分析的成果。需求分析阶段的工作成果是后续软件开发的重要基础，为了提高软件开发的质量，降低软件开发的成本，必须对需求的正确性进行严格的验证，确保需求的一致性、完整性、现实性、有效性。确保设计与实现过程中的需求可回溯

40、性，并进行需求变更管理。4.1需求分析 4.1.3 需求管理 为了更好的进行需求分析并记录需求结果，需要进行需求管理。需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。可用于：获取、组织和记录系统需求 使客户和项目团队在系统变更需求上达成并保持一致 有效需求管理的关键在于维护需求的明确阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工件之间的可追踪性。4.1需求分析 4.1.4 需求分析的常用方法 需求分析的方法有多种，下面只简单介绍功能分解方法、结构化分析方法、信息建模方法和面向对象的分析方法。（1）功能分解方法 功能分解方法是将一个系统看成是由若干功能模块组成的，每

41、个功能又可分解为若干子功能及接口，子功能再继续分解，即功能、子功能和功能接口成为了功能分解方法的3个要素。功能分解方法采用的是自顶向下、逐步求精的理念。4.1需求分析（2）结构化分析方法 结构化分析方法是一种从问题空间到某种表示的映射方法，其逻辑模型由数据流图和数据词典构成并表示。它是一种面向数据流的需求分析方法。它主要适用于数据处理领域问题。第4章将详细介绍这种方法。4.1需求分析（3）信息建模方法 模型是用某种媒介对相同媒介或其他媒介里的一些事物的表现形式。从一个建模角度出发，模型就是要抓住事物的最重要方面而简化或忽略其他方面。简而言之，模型就是对现实的简化。建立模型的过程，称为建模。建模

42、可以帮助理解正在开发的系统，这是需要建模的一个基本理由。并且，人对复杂问题的理解能力是有限的。建模可以帮助开发者缩小问题的范围，每次着重研究一个方面，进而对整个系统产生更加深刻的理解。可以明确地说，越大、越复杂的系统，建模的重要性也越大。信息建模方法常用的基本工具是E-R图，其基本要素由实体、属性和关系构成。它的核心概念是实体和关系，它的基本策略是从现实中找出实体，然后再用属性对其进行描述。4.1需求分析（4）面向对象的分析方法面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立3类模型，它们分别是:描述系统静态结构的对象模型 描述系统控制结构的动态模型 描述系统计算结构的

43、功能模型其中，对象模型是最基本、最核心、最重要的。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征（即属性）和行为特征（即服务）。4.2 结构化分析概述 一种考虑数据和处理的需求分析方法被称作结构化分析方法（Structured Analysis，简称SA 法），是70年代由Yourdon Constaintine 及DeMarco 等人提出和发展，并得到广泛的应用。它基于“分解”和“抽象”的基本思想，逐步建立目标系统的逻辑模型，进而描绘出满足用户要求的软件系统。“分解”是指对于一个复杂的系

44、统，为了将复杂性降低到可以掌握的程度，可以把大问题分解为若干个小问题，然后再分别解决。4.2 结构化分析概述 最顶层描述了整个目标系统X中间层将目标系统划分为若干个模块，每个模块完成一定的功能最底层是对每个模块实现方法的细节性描述4.2 结构化分析概述 结构化分析方法是一种面向数据流的需求分析方法，其中数据作为独立实体转换，数据建模定义了数据的属性和关系，操作数据的处理建模表明当数据在系统流动时处理如何转换数据。结构化分析的具体步骤为：1)建立当前系统的“具体模型”：系统的“具体模型”就是现实环境的忠实写照，这样的表达与当前系统完全对应，因此用户容易理解。2)抽象出当前系统的逻辑模型：分析系统

45、的“具体模型”，抽象出其本质的因素，排除次要因素，获得当前系统的“逻辑模型”。3)建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，从而进一步明确目标系统“做什么”，建立目标系统的“逻辑模型”。4)为了对目标系统进行完整的描述，还需要考虑人机界面和其他一些问题。4.3 结构化分析方法 结构化分析实质上是一种创建模型的活动，它建立的分析模型如图所示。此模型的核心是“数据字典”，它描述软件使用或产生的所有数据对象。围绕着这个核心有3种不同的图：l“数据流图”指出当数据在软件系统中移动时怎样被变换，以及描绘变换数据流的功能和子功能，用于功能建模l“实体-关系图”（E-R图）描绘数据对象之间

46、的关系，用于数据建模l“状态转换图”指明了作为外部事件结果的系统行为，用于行为建模4.2 结构化分析方法 4.3.1 功能建模功能建模的思想就是用抽象模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解，直到找到满足功能要求的可实现的软件为止。功能模型用数据流图来描述。数据流图（简称DFD图）就是采用图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。4.3 结构化分析方法 1.数据流图的表示符号在数据流图中，存在4种表示符号。外部实体：表示数据的源点或终点，它是系统之外的实体，可以是人、物或者其他

47、系统 数据流：表示数据流的流动方向。数据流可以从加工流向加工，从加工流向文件，从文件流向加工 数据变换：表示对数据进行加工或处理，比如对数据的算法分析和科学计算 数据存储：表示输入或输出文件。这些文件可以是计算机系统中的外部或者内部文件，也可以是表、账单等4.3 结构化分析方法 2.环境图环境图（如图所示）也称为系统顶层数据流图（或0层数据流图），它仅包括一个数据处理过程，也就是要开发的目标系统。环境图的作用是确定系统在其环境中的位置，通过确定系统的输人和输出与外部实体的关系确定其边界。4.3 结构化分析方法 根据结构化需求分析采用的“自顶向下，由外到内，逐层分解”的思想，开发人员要先画出系统

48、顶层的数据流图，然后再逐层画出低层的数据流图。顶层的数据流图要定义系统范围，并描述系统与外界的数据联系，它是对系统架构的高度概括和抽象。底层的数据流图是对系统某个部分的精细描述。4.3 结构化分析方法 4.3.2 数据建模 数据建模的思想是在较高的抽象层次（概念层）上对数据库结构进行建模。数据模型用实体关系图来描述。实体-关系图（简称E-R图）可以明确描述待开发系统的概念结构数据模型。对于较复杂的系统，通常要先构造出各部分的E-R图，然后将各分E-R图集合成总的E-R图，并对E-R图进行优化，以得到整个系统的概念结构模型。4.3 结构化分析方法 在建模的过程中，E-R图以实体、关系和属性3个基

49、本概念概括数据的基本结构。l 实体就是现实世界中的事物，多用矩形框来表示，框内含有相应的实体名称。l 属性多用椭圆形表示，并用无向边与相应的实体联系起来，表示该属性归某实体所有。可以说，实体是由若干个属性组成的，每个属性都代表了实体的某些特征。例如，在某教务系统中，“学生”实体的属性如图所示。4.3 结构化分析方法 关系用菱形表示，并用无向边分别与有关实体连接起来，以此描述实体之间的关系。实体之间存在着3种关系类型，分别是一对一、一对多、多对多，它们分别反映了实体间不同的对应关系。如图所示，“人员”与“车位”之间是一对一的关系，即一个人员只能分配一个车位，且一个车位只能属于一个人员。“订单”与

50、“订单行”之间是一对多的关系，即一个订单包含若干个订单行，而一个订单行只属于一个订单。“学生”与“课程”之间是多对多的关系，即一个学生能登记若干门课程，且一门课程能被多个学生登记。4.3 结构化分析方法 4.3.3 行为建模 状态转换图是一种描述系统对内部或外部事件响应的行为模型。它描述系统状态和事件，事件引发系统在状态间的转换，而不是描述系统中数据的流动。这种模型尤其适合用来描述实时系统，因为这类系统多是由外部环境的激励而驱动的。4.3 结构化分析方法 1.状态 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做