从哪些方面验证软件需求的正确性 需求分析阶段的工作结果是开发软件系统的重要基础,大量统计数字表明,软件系统中 一5% 的错误起源于错误的需求。为了提高软件质量,确保软件开发成功,降低软件开发成本,一旦对目标系统提出一组要求之后,必须严格验证这些需求的正确性。一般说来,应该从下述 四 个方面进行验证: (一) 一致性 所有需求必须是一致的,任何一条需求不能和其他需求互相矛盾。 (二) 完整性 需求必须是完整的,规格说明书应该包括用户需要的每一个功能或性能。 (三) 现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测,对软件技术的进步则很难做出预测,只能从现有技术水平出发判断需求的现实性。 (四) 有效性 必须证明需求是正确有效的,确实能解决用户面对的问题。 验证软件需求的方法 一. 验证需求的一致性 当需求分析的结果是用自然语言书写的时候,除了靠人工技术审查验证软件系统规格说明书的正确性之外,目前还 没有其他更好的 “ 测试 ” 方法。但是,这种非形式化的规格说明书是难于验证的,特别在目标系统规模庞大、规格说 明书篇幅很长的时候,人工审查的效果是没有保证的,冗余、遗漏和不一致等问题可能没被发现而继续保留下来,以致软件开发工作不能在正确的基础上顺利进行。 为了克服上述困难,人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求 陈述语言书写的时候,可以用软件工具验证需求的一致性,从而能有效地保证软件需求的一致性。 二. 验证需求的现实性 为了验证需求的现实性,分析员应该参照以往开发类似系统的经验,分析用现有的软、硬件技术实现目标 系统的可能性。必要的时候应该采用仿真或性能模拟技术,辅助分析软件需求规格说明书的现实性。 三. 验证需求的完整性和有效性 只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此,检验需 求的完整性,特别是证明系统确实满足用户的实际需要 (即,需求的有效性 ) ,只有在用户的密切合作下才能 完成。然而许多用户并不能清楚地认识到他们的需要 ( 特别在要开发的系统是全新的,以前没有使用类似系统的经验时,情况更是如此 ) ,不能有效地比较陈述需 求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时,才能完整确切 地提出他们的需要。 理想的做法是先根据需求分析的结果开发出一个软件系统,请用户试用一段时间以便能认识到他们的实际需要是什么,在此基础上再写出正式的 “ 正确的 ” 规格说明书。但是,这种做法将使软件成本增加一倍,因此实际上几乎不可 能采用这种方法。使用原型系统是一个比较现实的替代方法,开发原型系统所需要的成本和时间可以大大少于开发 实际系统所需要的。用户通过试用原型系统,也能获得许多宝贵的经验,从而可以提出更符合实际的要求
ui一致性原则有哪些
一、设计目标一致
软件中往往存在多个组成部分(组件、元素等)。不同组成部分之间的交互设计目标需要一致。
例如:如果以电脑操作初级用户作为目标用户,以简化界面逻辑为设计目标,那么该目标需要贯彻软件(软件包)整体,而不是局部。
二、元素外观一致
交互元素的外观往往影响用户的交互效果。同一个(类)软件采用一致风格的外观,对于保持用户焦点,改进交互效果会有很大帮助的。遗憾的是如何确认元素外观一致没有特别统一的衡量方法。因此需要对目标用户进行调查取得反馈。
三、交互行为一致
在交互模型中,不同类型的元素用户触发其对应的行为事件后,其交互行为需要一致。
例如:所有需要用户确认操作的对话框都至少包含确定和取消两个按钮。
对于交互行为一致性原则比较极端的理念是相同类型的交互元素所引起的行为事件相同。但是我们可以看到这个理念虽然在大部分情况下正确,但是的确有相反的例子证明不按照这个理念设计,会更加简化用户操作流程。
关于杀毒软件的一致性问题
不一定的
但是最好一致
数据库系统中 数据的一致性指的是什么?
数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定,则可以得到系统所承诺的访问结果
常用的一致性模型有:
a、严格一致性(linearizability, strict/atomic Consistency):读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能,在分布式网络环境不可能实现。
b、顺序一致性(sequential consistency):所有使用者以同样的顺序看到对同一数据的操作,但是该顺序不一定是实时的。
c、因果一致性(causal consistency):只有存在因果关系的写操作才要求所有使用者以相同的次序看到,对于无因果关系的写入则并行进行,无次序保证。因果一致性可以看做对顺序一致性性能的一种优化,但在实现时必须建立与维护因果依赖图,是相当困难的。
d、管道一致性(PRAM/FIFO consistency):在因果一致性模型上的进一步弱化,要求由某一个使用者完成的写操作可以被其他所有的使用者按照顺序的感知到,而从不同使用者中来的写操作则无需保证顺序,就像一个一个的管道一样。 相对来说比较容易实现。
e、弱一致性(weak consistency):只要求对共享数据结构的访问保证顺序一致性。对于同步变量的操作具有顺序一致性,是全局可见的,且只有当没有写操作等待处理时才可进行,以保证对于临界区域的访问顺序进行。在同步时点,所有使用者可以看到相同的数据。
f、 释放一致性(release consistency):弱一致性无法区分使用者是要进入临界区还是要出临界区, 释放一致性使用两个不同的操作语句进行了区分。需要写入时使用者acquire该对象,写完后release,acquire-release之间形成了一个临界区,提供 释放一致性也就意味着当release操作发生后,所有使用者应该可以看到该操作。
g、最终一致性(eventual consistency):当没有新更新的情况下,更新最终会通过网络传播到所有副本点,所有副本点最终会一致,也就是说使用者在最终某个时间点前的中间过程中无法保证看到的是新写入的数据。可以采用最终一致性模型有一个关键要求:读出陈旧数据是可以接受的。
h、delta consistency:系统会在delta时间内达到一致。这段时间内会存在一个不一致的窗口,该窗口可能是因为log shipping的过程导致。
转载请注明出处51数据库 » 软件可一致性 如何正确保证软件需求的正确性