系统分析师笔记-案例综合题-系统分析

案例综合题-系统分析

问卷调查不足：

1，缺乏灵活性。

2，双方未见面。

3，用户不重视。

3，不利于对问题的展开问答。

4，回答的数量往往比预期少。

用例建模描述各种参与者和系统之间的主要交互。

组件建模确定系统的子系统、模块和组件结构。为子系统或模块分配需求和职责。

服务建模提供了通用的应用程序，并将应用程序定义成一组服务接口。

性能建模是对系统的性能进行度量，为没个组件确定性能指标。

 

通过研究PIECES框架中类别或子类中的内容，可以发现企业中存在的各种问题。PIECES框架的内容如表所示。

类别	内容描述
性能	吞吐量：表示单位时间内处理的工作量 响应时间：完成一项业务或请求所耗费的平均时间
信息和数据	输出：缺乏任何信息 缺乏必要的信息 缺乏有关的信息 信息过多，即信息过载 提供信息的格式不符合要求 信息是不准确的 信息是很难产生的 信息的产生不是实时的，太慢了 输入： 数据是无法捕捉的 数据是无法及时捕捉的 捕捉到的数据是不准确的，包含了错误 数据的捕捉是非常困难的 捕捉到的数据是冗余的，即某些数据多次捕捉 捕捉到的数据太多了 捕捉到的数据是非法的，即不是通过合法途径捕捉到了数据 已存储的数据： 一个数据在多个文件或数据库中存储 己存储的数据是不准确的 已存储的数据是不安全的，容易遭到无意或恶意的破坏 已存储的数据的组织方式是不合适的 已存储的数据是不灵活的，即这些已存储的数据不容易满足新的信息的需要 己存储的数据是不可访问的
经济	成本： 成本是未知数 成本是不可跟踪的 成本过高 收益： 新的市场需求已经形成 当前的市场营销方式已经改进了 订单数量提高了
控制和安全	安全性机制或控制手段太少： 输入的数据是不完整的 数据很容易受到攻击 数据或信息可以轻而易举地被末授权的人使用，道德防线很容易突破 存储在不同的文件或数据库中的冗余数据之间是不一致的 无法保护数据隐私 出现了错误的处理方式（由人、机器、软件等） 出现了决策错误 安全控制手段太多： 复杂的官僚体制降低了系统处理的速度 控制客户或雇员访问系统的方法很不方便 过多的控制引起了处理速度的迟缓
效率	人或计算机浪费时间： 数据被重复输入或复制 数据被重复处理 信息被重复生成 人、机器或计算机浪费了物料 为了完成任务所付出的努力是多余的 为了完成任务所需要的物料是多余的
服务	当前系统生成的结果是不准确的 当前系统生成的结果数据是不一致的 当前系统生成的结果是不可靠的 学习当前系统是非常困难的 使用当前系统是非常困难的 当前系统的使用方式是笨拙的 对于新情况，当前系统无法处理 修改当前系统是困难的 当前系统与其他系统是不兼容的 当前系统与其他系统是不协调的

 

如果用底层系统处理处理子系统间的通讯：

1，异类系统间的交互性，如：不同操作系统的字节顺序、数据长度、数据表示方式。

2，通讯的可靠性。

3，通讯的安全性。

4，接口的可用性、易用性。

Linux和Windows相比，主要优缺点如下：

1，优点：系统性能高、网络应用能力强、价格便宜、可靠性高。

2，缺点：用户界面不友好、安装维护困难、售后和培训保障较差、配套应用程序少、第三方支持贫乏。

用例获取的基本步骤：

1，定义该应用系统的边界。

2，识别出改应用系统所有的角色。

3，对识别的每一个角色，分别确定：

a,改角色所参与的每一种业务活动。

b,各种业务活动的完整的事件序列。

c,激发上述每一个事件序列的角色。

4，对3中确定的事件序列进行分析，除掉其中重复的序列。

5，用结构化的自然语言描述4中确定的每一个事件序列，得到初步确定的每一个用例。

6，对5中确定的每一 个用例进行分析和重组，采用包含、扩展、慨括的关系表示用例直接的关系。

金融安全性需求有哪些？

1，验证 2，签名 3，授权 4，完整性 5，机密性 6，审查 7，不可否认性 8，威胁预防