|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（5）可追溯性。可追溯性评价指标及测量，如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）由信息技术支持工程师提供。召集有经验的信息技术支持工程师，要求他们提供知识库的内容，知识库的建立并不是某个人智慧的积累，毕竟一个人的知识和经验有限，我们需要在企业中营造这样一种乐意共享自身知识的氛围，能够提供有效知识条目的工程师能够获得奖励。发布一系列奖惩和鼓励措施。
|
|
|
|
（2）从过往的事件和问题的处理日志中提炼。事件与问题的处理过程需要详细记录，能为下一次处理相同事件提供指导和参考。知识库内容可以从这些处理日志中提炼后获得，事件处理步骤的详细记录对于知识库内容的建立有着重要的帮助。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
UML中有4种事物：结构事物、行为事物、分组事物和注释事物。
|
|
|
|
（1）结构事物（structural thing）。
|
|
|
|
结构事物是UML模型中的名词。它们通常是模型的静态部分，描述概念或物理元素。UML有7种结构事物：类（class）、接口（interface）、协作（collaboration）、用例（use case）、主动类（active class）、构件（component）和节点（node）。结构事物的图形表示如下图所示。
|
|
|
|
|
|
|
|
类是描述具有相同属性、方法、关系和语义对象的集合，一个类实现一个或多个接口。接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外可见的动作。协作定义了交互的操作，使一些角色和其他事物一起工作，提供一些合作的动作。用例是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。主动类的对象有一个或多个进程或线程。构件是物理上或可替换的部分，它实现了一个接口的集合。节点是一个元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
|
|
|
|
|
|
行为事物是UML模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为。共有两类主要的行为事物：交互（interaction）和状态机（state machine）。
|
|
|
|
交互由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）。在图形上，把一个消息表示为一条有向直线，通常在表示消息的线段上标注操作名，如下图（a）所示。
|
|
|
|
|
|
|
|
状态机描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。在图形上，把状态表示为一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态，如上图（b）所示。
|
|
|
|
|
|
分组事物是UML模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包（package）。包是把元素组织成组的机制，这种机制具有多种用图。结构事物、行为事物甚至其他分组事物都可以放进包内。包与构件（仅在运行时存在）不同，它纯粹是概念上的（即它仅在开发时存在）。包的图形化表示如下图所示。
|
|
|
|
|
|
|
|
（4）注释事物（annotational thing）。
|
|
|
|
注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。注解（note）是一种主要的注释事物。注解是一个依附于一个元素或者一组元素之上，对它进行约束或解释的简单符号。注解的图形化表示如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
完整性（Integrity）是指网络信息或系统未经授权不能进行更改的特性。例如，电子邮件在存储或传输过程中保持不被删除、修改、伪造、插入等。完整性也被称为网络信息系统CIA三性之一，其中I代表Integrity。完整性对于金融信息系统、工业控制系统非常重要，可谓“失之毫厘，差之千里”。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
除了要明确地知道我们需要什么方面的信息，还要知道它们可以从哪里获得。而通常情况下，这些你需要的信息会藏于客户、原有系统、原有系统用户、新系统的潜在用户、原有产品、竞争对手的产品、领域专家、技术法规与标准里。
|
|
|
|
面对这么许多种可能，在具体实践中该从何下手呢？其实也很简单，首先从人的角度来说，应该首先对项目干系人进行分类，然后从每一类项目干系人中找到1或2名代表；而对于文档、产品而言，则更容易有选择地查阅。
|
|
|
|
在制定需求获取计划的时候，我们可以列出一个表格，第1列是我们想了解的信息，第2列是信息可能的来源，这样就能够建立起一一对应的关系，使得需求获取工作更加有的放矢，也更加高效。
|
|
|
|
|
|
|
|
|
|
|
|
|
