华软软件工程期末考试资料(必过)

软件工程概念与过程

?软件的特性

软件是一种逻辑实体，而不是具体的物理实体。它具有抽象性

软件的生产与硬件不同

大多数软件是定制的

在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题 软件的开发和运行常常受到计算机系统的限制对计算机系统有着不同程度的依性 软件开发至今尚未完全摆脱手工艺的开发方式

软件是复杂的

软件成本相当昂贵

相当多的软件工作涉及到社会因素

?软件危机

指在落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致计算机软件的开发和维护过程中所遇到的一系列严重问题。产生于软件发展的第二阶段（软件系统阶段）末期。

产生：

硬件性价比和应用范围、数量增大--》软件的需求和规模增大--》软件开发技术落后、低产量、低质量--》软件危机

软件危机---主要表现

对软件开发成本和进度的估计不准确

用户不满意

软件质量不高、可靠性差

软件常常不可维护、错误难以改正

缺乏适当的文档资料

软件成本占系统总成本的比例逐年上升（1985----90%）

软件开发速度跟不上计算机发展速度

归结为主要为三方面----“时间、成本、质量”

软件危机--原因1

软件规模日渐庞大（数量、功能、成本、质量、时间）

软件开发管理困难。

逻辑部件而不是物理部件。

在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。

开发人员错误的观念、方法和技术

重编程、轻需求。

生产方式落后：个体手工方式。

开发技术落后\开发工具落后

软件危机---原因2

忽视软件开发前期的需求分析

开发过程缺乏统一的、规范化的方法论的指导

文档资料不齐全或不准确

忽视与用户之间、开发组成员之间的交流

忽视测试的重要性

不重视维护或由于上述原因造成维护工作的困难

需求变化预料不足

?ISO/IEC 12207定义的软件过程

按ISO/IEC 12207软件开发生存周期过程，软件设计由两个活动组成

软件体系结构设计-software architectural design

顶层设计（top-level design）

描述系统顶层的结构和组织

标识各个构件

软件详细设计-software detailed design

充分描述每个构件使之可以编码

软件生命周期

?软件生命周期定义

?它是指一个软件从提出开发要求开始到该软件报废为止的整个时期（生存过程）。从时间角度，把整个周期划分为若干个阶段（步骤），每个阶段有明确

的任务，然后再逐步完成每个阶段的任务

?软件从孕育、诞生、成长、成熟、衰亡的生存过程

?软件生存期各阶段

?制定计划（Planning）

?需求分析和定义（Requirement Analysis and Definition）

?软件设计（Software Design）

?程序编写（Coding/Programming）

?软件测试（Testing）

?运行/维护（Running/Maintenance）

?软件生命周期模型

?线性顺序模型

?瀑布模型

?RAD模型

?原型模型

?渐增模型

?螺旋模型

?统一过程

?敏捷软件开发

瀑布模型--特点

?优点：

?提供了软件开发的基本框架，比靠“个人技艺”开发好的多。

?严格活动序列，严格阶段成果评审，有利于大型软件开发过程的人员的组织和管理

?缺点：对用户需求变更的响应较困难。

?初始阶段较长，用户极大的耐心，需求的不确定性；

?后期阶段时，需求错误、设计及实现错误才出现

?适用：需求明确、大型的项目。

RAD模型--特点

优点：开发时间短；快速发布

缺点：多团队开发协调困难；了解需求困难；不注意小细节

原型模型----特点

优点：

成品的用户满意度高。用户参与，需求不断完善

缺点

软件的“临时版本”，未考虑性能需求

进度控制、质量检验较难，技术方案未必最优，会导致开发过程的不可收敛性

系统结构通常较差，连续的变更损坏了系统的结构

适用：

中小规模、生存期短的系统，知识型系统

用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求

开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式

当你的客户有一个合理的需求，但对细节则没有任何线索时，先开发一个原型系统是一个好的选择

演化软件过程模型

渐增模型

以尽早占领市场为目的，逐步发布版本；

可有计划地管理技术风险

螺旋模型

不同版本、不同形式的不断进化；

需要高水平的风险评估技术

并发开发模型

由用户要求、管理决策和评审结果驱动；

每一个软件工程活动触发活动网络的状态变迁

渐增模型-特点

优点：易于预测、管理、控制使用的资源；快速版本发布

缺点：有可能消弱结构和设计

使用：用户需求不明确；设计用户界面

螺旋模型-特点

（spiral model）TRW B.Boehm,1988提出。将过程用螺旋线表示，每个回路表示软件过程的一个阶段。因此，最里面的回路可能与系统可行性有关，下一个回路可能与系统需求定义有关，再下一个回路与系统设计有关。

优点：渐增、使用原型模型减少风险，快速、可在软件的整个生命期间使用

缺点：客户与开发团队需要丰富的风险评估专业知识，演化是否完全可控

并发开发模型优缺点

优点：适用所有类型的软件开发；尤其适用客户端/服务器应用程序；

在实际项目中使用是成功的；将降低整个过程的风险

缺点：对管理要求较高

形式化方法模型1

通过一组指定的活动来产生计算机软件的数学规约。

软件工程师应用一个严格的、数学的符号体系来进行规约、开发和验证基于计算机的系统

特点：完全可以产生无缺陷的软件

缺点：成本高；与客户交流困难

使用在对可靠性要求极高的系统开发中

RUP简介

RUP（Rational Unified Process）Rational统一过程

近30年的发展和实际运用

每一次软件开发过程定义了九个核心规程

六个技术规程

业务建模规程、需求工程、分析和设计规程、实现规程、测试规程、

部署规程

三个管理规程

配置和变更管理规程、项目管理规程、环境规程

开发周期的四个阶段

初始阶段、细化阶段、构造阶段、移交阶段

工作流描述

业务建模（Business Modeling）

理解系统的组织结构及其商业运作，确保所有参与人员对开发系统有共同的认识。

需求分析（Requirements）

定义系统功能及用户界面，明确客户需要的系统的功能，开发人员理解系统的需求，为项目预算及计划提供基础。

分析与设计（Analysis and Design）

把需求分析的结果转化为实现规格。

实现（Implementation）

定义代码的组织结构、实现代码、单元测试、系统集成。

测试（Test）

验证各自子系统的交互与集成。

配置（Deployment）

打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。制定并实施beta测试。

设置和变更管理（Configuration and Change Management）

跟踪并维护系统所有产品的完整性和一致性。

项目管理（Project Management）

为计划、执行和监控软件开发项目提供可行性的指导；为风险管理提供框架。

环境（Environment）

为组织提供过程管理和工具的支持。

RUP的四个阶段

RUP包括以下四个阶段：

起始阶段、细化阶段、构建阶段、交付阶段

每个阶段结束于一个主要的里程碑（Major Milestones）

每个阶段本质上是两个里程碑之间的时间跨度

RUP的四个阶段--初始阶段

进行如下的活动

明确说明项目规模，了解环境以及最重要的需求和约束，以便可以得出最终产品的验收标准。

计划和准备商业理由。评估风险管理、人员配备、项目计划以及成本/进度/收益折衷的被选方案。

综合考虑被选构架，评估构架。

准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。

评估标准如下：

出资人同意系统范围定义以及费用和进度评估。

主要用例是否符合需求。

费用和进度评估、优先级、风险以及开发过程的可信性。

任何已开发的原型的深度和广度。

实际开销与计划开销。

初始阶段的焦点是需求和分析工作流。

RUP的四个阶段-细化阶段

细化阶段的评估标准如下：

标明用例模型中的用户和参与者，并且建立用例的描述文档。用例模型需完

成80％。

创建软件系统开发过程中的软件结构的描述文档。

创建可执行的系统原型。

细化商业案例和风险列表。

创建整个项目的开发计划。

细化阶段的焦点是需求、分析和设计工作流。

RUP的四个阶段--构建阶段

主要目标如下：

优化资源、避免不必要的报废和返工，使开发成本降到最低。

尽快达到质量的要求。

快速完成有用的版本，例如Alpha 版、Beta 版和其他测试发布版。

完成所有功能的分析、开发和测试。

迭代式、递增地开发随时可以发布的产品。

确定准备好软件系统的外部环境。

构建阶段的焦点是实现工作流。

RUP的四个阶段-交付阶段

主要目标如下：

进行Beta版测试，按用户的要求验证新系统。

替换旧的系统。

对用户和维护人员进行培训。

开始调整活动，例如调试、性能或可用性的增强。

与用户达成共识，配置基线与评估标准一致。

交付阶段的焦点是实现和测试工作流。

RUP的迭代开发模型

RUP中的每个阶段可以进一步分解为迭代。

与传统的瀑布模型相比较，迭代过程的优点：

降低了在一个增量上的开发风险。

降低了产品无法按照既定进度进入市场的风险。

加快了整个开发工作的进度。

核心工作流介绍-需求捕获工作流

需求捕获通过对应问题的理解和分析，确立问题涉及的信息、功能和系统行为，将用户需求精确化、完全化。

需求的焦点主要在初始和精化阶段，在精化阶段后期，需求捕获的工作量大幅下降。

主要的UML制品：

分析模型、分析类、用例实现（分析）、分析包、构架模型 参与的工作人员：

构架设计师、用例工程师、构件工程师

主要包括四种活动：

构架分析、分析用例、分析类、分析包

敏捷软件开发

敏捷软件开发（轻量级方法）

XP方法，SCRUM方法，DSDM方法

敏捷软件开发联盟（Agile联盟）的4个价值观和12条原则

1.个人和交互高于过程和工具

2.可运行软件高于详尽的文档

3.与客户协作高于合同（契约）谈判

4.对变更及时做出反映高于遵循计划

敏捷软件开发联盟（Agile联盟）开发遵循的12条原则

1.最优先的是通过尽早地和不断提交有价值的软件来使客户满意

2.欢迎变化的需求，即使该变化出现在开发的后期，为了提高客户的

竞争优势，敏捷过程利用变化作为动力

3.以几周到几个月为周期，尽快、不断地交付可运行的软件

4.在整个项目过程中，业务人员和开发人员必须天天一起工作

5.以积极向上的员工为中心建立项目组，给与他们所需要的环境和支

持，对他们的工作给与充分的信任

6.项目组内效率最高、最有效的信息传递方式是面对面交流

7.测量项目进展的首要依据是可运行的软件

8.敏捷过程提倡可持续的开发，项目发起人、开发者和用户应能长期

保持恒定的速度

9.应该时刻关注技术上的精益求精和好的设计，以增强敏捷性

10.简单化是必不可少的，这是尽可能减少不必要工作的艺术

11.最好的架构、需求和设计出自于自我组织的团队

12.团队要定期反思怎样才能更加有效，并据此调整自己的行为

XP方法

四个价值观：交流；简单；反馈；勇气

12个核心实践

完整的团队、计划对策、系统比喻、小发布、测试、简单设计

结对编程、设计改进、持续集成、代码全体共有、编码标准、可持续步调

其它敏捷方法

自适应软件开发

思考、协作、学习

动态系统开发方法

可行性研究、业务研究、功能模型迭代、设计和构建迭代、实现 Scrum

Crystal

特征驱动开发

敏捷建模

系统工程与可行性分析

系统工程

基于计算机的系统

系统工程的任务

可行性分析

可行性研究的任务

可行性研究的步骤

可行性研究的文档

?系统工程

系统工程的主要任务是根据总体协调的需要，把自然科学和社会科学中的基础思想、理论、策略和方法等从横的方面联系起来，应用现代数学和电子计算机等工具，对系统的构成要素、组织结构、信息交换和自动控制等功能进行分析研究，借以达到最优化设计，最优控制和最优管理的目标。

业务过程工程:业务能够有效地使用信息的体系结构

业务目标语境中分析和设计

数据体系结构

?为业务和业务功能的信息需要提供框架。

?体系结构的个体构造是被业务所使用的数据对象

应用体系结构

?为了某些业务目的而在数据体系结构变换数据对象的系统元素，一

般为程序（软件）系统

技术基础设施

?为数据和应用体系结构提供基础，支持的硬件和软件，包括计算机

和计算机网络、通信链路、存储技术和实现这些技术的体系结构（如

客户/服务器）

系统工程的任务

识别用户的要求

系统建模和模拟

硬件系统模型、软件系统模型、人机接口模型、数据模型 成本估算及进度安排

可行性分析

生成系统规格说明

产品工程：对一组应定义的能力影射为可工作的产品

?四种不同的系统构件：软件；硬件；数据（和数据库）；人员

?基于计算机的系统的元素

软件；硬件；人员；数据库；文档；规程

可行性分析

?可行性研究的任务

定义：研究软件项目是否值得开发、关键技术、难点、能否解决、怎样达到目标 主要任务

社会/法律可行性

技术可行性

经济可行性

结论：可以进行开发；需要等待某些条件；

需要对开发目标进行某些修改之后才能开发；不能进行或不必进行开发?主要从哪几个方面分析项目的可行性

社会可行性

也称法律可行性

待开发系统，是否存在侵权、妨碍、责任等问题

合同

社会影响

其它：市场分析；政策分析；竞争实力分析；时间和资源可行性

技术可行性

技术风险，给出限制范围内能否实现功能、性能

资源有效性，已有的，可得到的硬件、软件、人员等

相关技术的发展是否支持

关键技术、算法、过程等

经济可行性

对开发成本进行估算，预期经济效益，确定是否值得投资开发

在测算成本和效益时注意项目相关方不同的考虑点

成本估计

效益分析

成本估计

购置并安装软件、硬件及有关设备的费用

系统开发费用

一次性

方法：自顶向下成本估计；由底向上成本估计；算法模型估计；

类比估计；专家判断；Parkinson估计和销价取胜法 系统安装、运行和维护费用

人员培训费用

其它

效益分析

社会效益

经济效益：货币的时间价值；效益来源；例题

效益来源

自动化水平提高，减少了工作人员；减少运行费用

由于自动编辑，减少错误；交易处理速度提高

较少货币管理上的损失；减少不良帐单或信贷损失

更快的收取应收帐款；库存减少与库存过期损失etc。。。

?经济可行性分析(根据一个实际案例从成本和效益进行分析)

可行性研究的步骤

系统定义：目标、性质、范围、规模、约束和限制

对现行系统进行分析研究（高层系统流程图、确定系统功能） 导出新系统逻辑模型

设计方案（不同角度、多个方案）

推荐可行的方案（技术可行性、经济可行性）

编写可行性研究报告

编写目的是：说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论证所选定的方案。

面向对象与业务过程建模

?UML定义:一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示定义：

是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize）、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件（artifacts，又译制品）

由UML表示法指南、UML语义、OCL规范和用户定义的UML扩展组成

UML是

是一种语言：用来获取关于某一主题的知识和表达关于该主题的知识，以便于进行交流

基于面向对象范型

应用于建模和系统

用于对系统进行描述、可视化、构造和文档化

是一种通用的、广泛适应的、得到工具支持和工业标准化的革命性的建模语言 统一了信息系统和技术工程的最佳工程实践的成果

应用于大量不同类型的系统、领域和方法或过程

UML的目标

成为一种易用、表达能力强的可视化建模语言，并且是简单的和可扩展的

具备扩展和特化机制

独立于实现（程序设计语言）

独立于过程（开发）

促进面向对象工具市场的成长

支持高级概念（协作、框架、模式和组件）

通过使用组建技术、可视化程序设计、模式和框架，解决反复出现的体系结构复杂性问题

可升级、广泛适用

融合了最佳的工程实践

使用UML

UML给出了面向对象建模的符号表示和规则，但未给出使用的过程和方法，因此，需要有使用UML的过程。

过程描述做什么、怎么做、何时做及为什么做，即描述一组特定次序的活动

使用UML过程的基本特征是：用例驱动，以体系结构为中心，反复，渐增式。

用例包含了功能描述，它们将影响后面所有阶段及视图。

以体系结构为中心

在开发的早期建立基础的体系结构（原型）是十分重要的，进一步对原型进行精化，建立一个易于修改、易理解和允许复用的系统。

主要是在逻辑上将系统划分为若干个子系统（UML包）

反复

UML的建模型过程要经过若干次的反复

渐增式

渐增式开发是在多次反复迭代的过程中，每次增加一些功能（或用例）的开发，每次迭代都包含了分析、设计、实现和测试。

MDA开发的三个阶段

CIM(Computation Independent Model)

聚焦于系统环境及需求,不涉及系统内部的结构与运作细节 PIM(Platform Independent Model)

聚焦于系统内部细节,不涉及实现系统的具体平台

PSM(Platform Specific Model)

聚焦于系统落实于特定具体平台的细节.如Sping、EJB3、.NET都是一种具体平台

?活动图的画法

Rational Rose工具简介

Rose的基本功能

面向对象建模；用例分析支持UML、COM、OMT和Booch’93；语义检查；

支持可控的迭代开发；双向工程；支持多用户并行开发；可以与数据建模工具集成；OLE链接、自动化；多平台可用性

Rational Rose的特点

保证模型和代码高度一致、支持多种语言

为团队开发提供强有力的支持、支持模型的Internet发布

生成使用简单且定制灵活的文档、支持关系型数据库的建模

Rational Rose中的视图

Use Case View（用例视图）：包、Actor、Use Case、对象、消息和关系

Logical View（逻辑视图）：包、类、状态和关系

Component View（组件视图）：包、组件和依附关系

Deployment View（部署视图）：节点和关系

活动图（Activity Diagram）定义

活动图能够表达顺序流程控制和并发流程控制，并发活动可以同时执行也可以顺序执行。如果排除了这一点，活动图很像一个传统的流程图

表示过程机理、业务过程以及工作流的技术，描述活动的顺序，展现从一个活动到一个活动的控制流。

它是一种变种的状态图，通过动作来组织，主要用于描述某一方法、机制或用例的内部行为

它依据对象状态的变化来捕获动作与动作的结果。

活动图中的基本原素

活动的起点、活动的终点：用于表示活动图中所有活动的起点和终点。

活动：用于表示活动图所描述的过程（或算法）的某一步。一般该步骤应为原子的，即不可再细分。

活动图中的基本原素-组合活动

用于表示活动图所描述的过程（或算法）的某一步。该步骤可再细分成多个活动的组合。

状态机中进行的非原子的执行单元。活动的执行最终延伸为一些独立动作的执行，每个动作将导致系统状态的改变或消息的传递

通过动作来组织，主要用于描述某一方法、机制或用例的内部行为

活动的属性定义

名称：该活动的名字。也用于简要描述该活动的内容，显示在该活动图元之中。

描述：关于该活动内容的详细描述。可采用正文形式，也可以用某种编程（或描述流程的）语言来描述。

对象：与其它图中的对象意义相同。在活动图中有两种用法：

与信号流相连，表示与活动图所刻画对象进行交互（接收或发送信号）的其它对象；

与数据流相连，表示某些活动的输入（产品）或输出（产品）。

对象属性

名称：该对象的名字。用于标识，并显示在图元中。

描述：关于该对象的详细描述。

State：表示该对象所处的状态。显示在图元中名称之后。

注意：作为活动输入或输出的各个对象，完全可能是同一对象，只是由于经过活动处理，其状态不同而已，所以要标明其状态；而与活动流程进行交互（发送或接收信号）的对象，一般不用注明状态。

信息流与数据流

信息流

用于连接各活动、组合活动及各特殊活动，表示各活动间的转移。

数据流

用于连接一个活动与一个对象，表示该对象是该活动的输入或输出。

信号流

用于连接一个信号发送或信号接收与一个对象，表示向该对象发送或从该对象接收一个信号。与之相连的对象是外部的，而不是作为活动的输入或输出，所以也不用注明状态。

注：信号流与数据流在图符形式上是一样的，略有粗细不同。

信息流属性

名称：

该信息流的内部名称。作为系统内部记录之用，不显示。

描述：

关于该信息流的文字描述，不显示。

重复：

活动图提供的一种简化机制，用于表示多条并行或重复的信息流。当多个活动内容相同或相似，且连接关系也相同或相似时，就可以使用这种机制，使

布图简洁、清晰。它用信息流附近的“*”号表示。

入口条件：

该信息流的入口条件。它是信息流被触发的前提之一。

注意：信息流表示活动图中各活动间的转移。

它的触发条件有四种：

前一活动的完成；

某个活动的输入对象可用

某个输入信号的到来；

入口条件得以满足。

其中，1）必须满足。在此基础上，若有其它条件，则其它条件必须同时满足，信息流才被触发。

当从某个活动引出多条信息流时，一般要为这些信息流标明不同（严格的说，应该"互斥"）的入口条件，这样就实现了活动流程的分支。

信息流中的事件信息

活动图中表示与外界对象的信息交互（发送或接受信号）有两种表示法

使用信号接收和信号发送；

使用信息流上的事件信息和发送信息。

这两种表示法是完全等效的。其中，信号接收与事件信息等效，信号发送与发送信息等效

发送信息能表示多个输出信号，而信号发送则只能表示一个。

事件信息：事件即输入信号。其信息包含如下三项：

发送信号对象：发送该输入信号的对象

输入信号：输入信号名称。一般为某个消息。

参数表：输入信号的参数表。

判断及两种表示方式：特殊活动的一种，活动图—分支

用于表示活动流程中的判断、决策。

同步条

特殊活动的一种，用于表示活动之间的同步。一般有一个或多个信息流向它引入，有一个或多个信息流从它引出，表示引入的信息流同时到达，引出的信息流被同时触发。

属性定义

名称：该同步条的名字。用于标识，不显示。

描述：关于该同步条的详细描述，不显示。

同步条件：表示该同步条所要遵循的条件，亦即各引出信息流被同时触发的条件。一般是针对各引入信息流的。显示在同步条图元旁边。

活动图—泳道

活动的合法连接

活动图元素

活动图-推荐的使用场合

理解牵涉多个用例的工作流：在难于区分不同用例而对整个系统的工作过程又十分清楚时，可以先构造活动图，然后用切片技术派生用例图

分析用例：能直观清晰地分析用例，了解应当采取哪些动作以及这些动作之间的依赖关系

处理多线程应用：采用“分层抽象，逐步细化”的原则描述多线程

使用活动图建模

可以附加到任何建模元素中描述其行为，包括用例、类、接口、节点、协作、操作和方法

对工作流建模步骤

1.识别要对工作流描述的类或对象，找出负责工作流实现的业务对象，可以是领域实

体，也可是一种抽象的概念或事物，建立泳道

2.确定工作流的初始状态和终止状态，明确工作流的边界细化

3.对动作状态或活动状态建模

4.对动作流建模：先处理顺序动作，在处理分支与合并等条件行为，再处理分叉与汇

合等并发行为

5.对对象流建模：找出与工作流相关的重要对象，连到相应的动作状态或活动状态

6.对建立的模型进行精化或细化

?什么是需求工程

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待

开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。软件需求分析

需求工程

1.需求获取

2.需求分析与协商

3.系统建模

4.需求规约

5.需求确认

6.需求管理

需求定义

IEEE软件工程标准词汇表(1997年)中定义需求为：

用户解决问题或达到目标所需的条件或能力（Capability）。

系统必须满足或具有的条件或能力，以满足合同、标准、规格说明或其它形式上强制的文档

准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。

用<需求规格说明书> 规范的形式准确地表达用户的需求。

它把可行性分析及初步计划期间建立的软件需求描述求精和细化。

需求分析从多角度、多层次把软件功能和性能等的总体概念描述为具体的规格说明，以做为开发软件的基础，它是质量和成败的关键

准确需求的重要性

研究分析：

项目失败最重要的8个原因中的5个与需求有关

需求阶段产生的错误将扩散到其他阶段

以需求为基础的设计与编码阶段对错误的检测与发现很困难

后期发现的需求错误的修正费用很高(图示)

软件项目的成本与时间超支，大多是需求分析不准确造成

5个有关需求

不完整的的需求；没有用户的介入

不实际的客户期望；需求和规范的变更；提供不再需要的能力

需求工程中包含的步骤

需求获取。需求分析。需求精化。需求讨论。

需求规格说明书。需求建模。需求验证。需求管理

?需求如何获取和确认

获取原则

将复杂问题分解、逐层细化；能够表达和理解问题的数据域和功能域；建立模型

需求获取

需求类型

领域需求：反映了应用领域的基本问题

功能性需求：定义了系统做什么

非功能性需求：定义了系统工作时的特性

详细需求类别

功能、性能、环境、界面、易用、文档、数据、资源、安全、成本、交付、质量

八项黄金贵规则

尽量保持一致、为熟练用户提供快捷键、提供有效反馈、设计完整的对话过程

提供简单的错误处理机制、允许撤销动作、提供控制的内部轨迹、较少短期记忆负担

软件需求各组成部分之间的关系

需求获取的难点、需求获取的方法与策略、需求获取的原则

有效需求实践、阶段结果

?怎样进行有效需求分析？

分析的原则

1.问题的信息域必须被表示和理解

2.软件将完成的功能必须被定义

3.软件的行为必须被表示

4.描述信息、功能和行为的模型必须被划分，可以分层次地揭示细节

5.分析过程应该从要素信息移向实现细节

?需求分析的重要性

?软件需求分析特别重要。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中的一个简单步骤，但在过去十多年中越来越多的人认识到它是整个过程中最关键的一个过程。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。许多大型应用系统的失败，最后均归结到需求分析的失败：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。

?需求分析的艰难性

问题的多面性、获取中的问题

领域知识缺乏、利害关系人与开发人员的交流问题

不完备性和不一致性、需求易变性、需求错误的类型

?软件需求规格说明书(SRS)

参考GB856T—88 软件需求说明书

需求规格说明1979 Balzer and Goldman提出了作出良好规格说明的8条原则需求规格说明

1.功能与实现分离，既描述“做什么”而不是：“怎样实现”

2.要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统出现什

么样的功能性反应，以此来定义一个行为模型，从而得到“做什么”的规格说明

3.如果目标软件是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描

述之内，描述该目标软件与系统的其他元素的交互的方式。

4.规格说明必须包括系统运行的环境。

5.规格说明必须是可操作的，充分完全和形式的。

6.规格说明是一个认识的模型，而不是一个设计实现的模型。

7.规格说明必须容许不完备性和扩充

8.规格说明内必须局部化和具有松散的耦合，当信息被修改时，只要修改某个单独的

段落，并可以容易增加或删除一些段落。

用例分析与用例图

使用UML过程的基本特征是：用例驱动，以体系结构为中心，反复，渐增式。

用例包含了功能描述，它们将影响后面所有阶段及视图。

需求建模

用例图作用：获取需求、指导测试、对过程中的其他工作流起指导作用

用例图的画法：

用例图是显示一组用例、参与者以及它们之间关系的图。

用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为。

用例图常用来对需求建模，用例图是至关重要的，它的正确与否直接影响到客户对最终产品的满意度。

用例图的内容：参与者、用例、泛化、扩展和包含关系

参与者( Actor) 是系统外部的一个人或物，它以某种方式参与了系统的执行过程。

参与者对系统而言总是外部的

参与者在系统的不同组成部分可能扮演不同的角色

参与者用一个人形的图案表示

识别参与者

定义：用例

用例表示系统的一项外部功能，它从用户的角度分析所得的需求。为完成一个相对完整的一种功能，系统执行的一系列动作的集合

用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。

用例用实线的椭圆表示