软件工程复习1

RUP统一过程

可行性分析

可行性研究的任务

定义

研究软件项目是否值得开发、关键技术、难点、能否解决、怎样达到目标

主要任务

社会/法律可行性

技术可行性

经济可行性

结论

可以进行开发

需要等待某些条件

需要对开发目标进行某些修改之后才能开发

不能进行或不必进行开发

主要从哪几个方面分析项目的可行性

(1)社会可行性

也称法律可行性

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

合同

社会影响

其它

市场分析

政策分析

竞争实力分析

时间和资源可行性

(2)技术可行性

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

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

C.相关技术的发展是否支持

D.关键技术、算法、过程等

(3)经济可行性

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

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

系统开发费用

一次性

方法

自顶向下成本估计

由底向上成本估计

算法模型估计

类比估计

专家判断

Parkinson估计和销价取胜法

系统安装、运行和维护费用

人员培训费用

其它

B.效益分析

社会效益

经济效益

货币的时间价值

效益来源

例题

PS:资料补充

货币的时间价值

F=P*（1+i)n

年利率为i，P 元钱存n 年后可得 F 元

P=F/(1+i)n

投资回收期

累计的经济效益等于最初投资所需的时间

n年投资回收率

R=(F1/(1+i)+F2/(1+i)2+…+Fn/(1+i)n )/ P

纯收入

累计的经济效益（折算成当前值）- 投资（开发成本）

效益来源

自动化水平提高，减少了工作人员

减少运行费用

由于自动编辑，减少错误

交易处理速度提高

较少货币管理上的损失

减少不良帐单或信贷损失

更快的收取应收帐款

库存减少与库存过期损失等等

经济可行性分析(根据一个实际案例分析)

效益分析例题：

投资回收期

两年以后可以节省4225.12元，比最初的投资（5000元）还少774.88元，第三年以后将再节省1779.45元。774.88／1779.45＝0.44，因此，投资回收期是2.44年。

5年投资回收率

9011/5000=180%

纯收入

9011.94－5000＝4011.94（元）

需求分析

需求工程的六个阶段

需求获取、需求分析与协商、系统建模、需求规约、需求确认、需求管理

需求获取

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

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

1．需求类型（详细需求类别）

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

2．需求获取的难点

●问题的多面性

●获取中的问题

●领域知识缺乏

●利害关系人与开发人员的交流问题

●不完备性和不一致性

●需求易变性

●需求错误的类型

3．需求获取的方法与策略

●建立顺畅的通信途径

●访谈与调查

●观察用户操作流程

●组成联合小组

●用例

需求分析的任务

4．需求获取分析的原则

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

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

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

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

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

5．有效需求实践

6．阶段结果

为什么说需求分析是一个十分重要的过程？

研究分析：

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

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

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

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

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

需求建模

基础扫盲：

结构模型视图

建立需求模型的典型活动：

●获取领域知识；

●定义系统功能（用例图）；

●确定合适的类；

●建立类的静态模型（类图）；

●描述对象的动态行为（状态图、协作图、时序图、活动图）；

●验证（专家对模型作静态验证）；

●给出基本的用户界面原型（整体结构的原型：主窗口的内容、窗口之间的导航等） 用例图的画法

用例关系

●Include

提取公共步骤，便于复用

●Extend

分离扩展路径

●Generalization

同一业务目的的不同技术实现

角色与用例，用例与用例的关系

角色之间的关系

由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

UML用例图中用例之间的关系：

(1)包含关系:基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。

简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。

(2)泛化关系：代表一般于特殊的关系。UML用例图中泛化关系的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。