原型法适用于用户没有确定其需求的明确内容的时候。他先是根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型（在声明周期法中，需求分析一般不再多修改）。在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型趋于完善。在各个过程中，用户的参与和决策加强了，最终的结果更适合用户的要求。这种原型技术有分为三类：抛弃式、演化式和递增式。原型法成败的关键及效率的高低关键在于模型的建立和建模的速度。 原型法的优点是：可以解决在产品开发早期需求不确定的问题（不确定性、二义性、不完整性、含糊性等），可以明确并完善需求、探索设计选择方案、发展为最终产品。 原型法的缺点也是显而易见的，需要在正式的代码开发之前进行必要的原型开发，在某种程度上增加了工作量，尤其采用抛弃型原型，更是如此。

正确的有 1 2 3 5 6 7 9 10

我们应当怎样做需求确认：快速原型法

常常听到许多朋友跟我埋怨，需求分析之难，就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的，一到软件上线的时候就不是那么回事了，这可没法整。但我们只要坐下来仔细分析就会发现，在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。但是，用户不是傻子，当你软件上线时，他拿到了实物了，知道软件做成啥样了，一旦不满意他就开始提变更了。所以，需求分析的症结就在与这个实物。既然症结在此，毫无疑问，我们就应当在需求分析阶段拿出实物，用实物与用户确认需求，这就是快速原型法的基本思想。快速原型法，简称原型法（Prototyping），是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再提出一些新的需求以后，再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。原型开发的快速与模拟到什么程度，是一对矛盾，我们要去把握。要快速开发，必然不可能和最终交付的软件系统一模一样，许多复杂问题被简化，非关键性流程被忽略，这就是所谓的模拟。因此，模拟到什么程度是关键，既能说明问题，又不耽误时间。根据我的经验，一般能拿出界面，并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能。当用户拿到原型可以自己操作时，需求研讨的气氛立即变得不太一样了。当用户享受原型给他们带来体验的快感时，需求被源源不断地被提出来。这时候的需求，就不再是枯燥无味的文字游戏，而是生动形象的图形界面。日后，如果项目采用迭代开发，让用户看着软件一点儿一点儿地成长，这又是多么美妙的体验啊。与此同时，你与用户的信任也在一步一步建立起来，软件风险在降低，项目将朝着正确方向前进。快速原型法是美妙的，它给你与用户带来了从未有过的体验。但美妙的同时，也会带来一些的尴尬，不必要的误会，我们一定要注意。最常见的误会就是让用户将原型误以为最终交付的系统。开发一个系统需要持续数月，但你倒好，几天就搞定了，为什么还要在这个系统上投入大量资金呢？如果对方领导开始有这样的想法时，双方就开发费用进行的谈判就有一些不妙了。所以在给用户看到原型前，一定要跟用户解释清楚。既然是原型，必要的校验、非正常操作的处理通通都被忽略。因此，当演示原型出错时，用户你可千万不要较真哟！这丑话可得说在前头，否则用户跟你较起真来，你在用户心目中的形象可就要大打折扣了。我们应当怎样做需求分析我们应当怎样做需求调研：初识我们应当怎样做需求调研：拜访我们应当怎样做需求调研：研讨会我们应当怎样做需求调研：需求研讨我们应当怎样做需求调研：迭代我们应当怎样做需求调研：需求捕获（上）我们应当怎样做需求调研：需求捕获（下）我们应当怎样做需求分析：功能角色分析与用例图我们应当怎样做需求分析：业务流程分析（上）我们应当怎样做需求分析：业务流程分析（下）我们应当怎样做需求分析：用例说明我们应当怎样做需求分析：查询报表分析我们应当怎样做需求分析：子用例与扩展用例我们应当怎样做需求分析：行动图和状态图我们应当怎样做需求分析：业务领域分析我们应当怎样做需求分析：原文分析法我们应当怎样做需求分析：领域驱动设计我们应当怎样做需求分析：非功能需求我们应当怎样做需求确认：需求列表我们应当怎样做需求确认：一个需求列表的实例我们应当怎样做需求确认：需求规格说明书我们应当怎样做需求确认：评审与签字确认会（续）

原型法的主要步骤有哪些？原型法最适用于哪一类信息系统的开发？

原型法的工作步骤：利用原型法进行信息系统的设计过程中，分四步进行：首先快速分析，弄清用户/设计者的基本信息需求；然后构造原型，开发初始原型系统；之后，用户和系统开发人员使用并评价原型；最后系统开发人员修改和完善原型系统

实用于：用户需求较难定义的、规模较小的系统来自：求助得到的回答

软件开发模式有哪些？

软件开发模式有哪些?

快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）

快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能

（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）

优点：

克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险

缺点：

A、 所选用的开发技术和工具不一定符合主流的发展

B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下

增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）

与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代

与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）

优点：

1、 人员分配灵活，一开始不需要投入大量人力资源

2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）

3、 增量能够有计划的管理技术风险

缺点：

1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析

注：

这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程

原型模型：（样品模型，采用逐步求精的方法完善原型）

主要思想：

先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，

采用方法：

原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应

优点：　　

(1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。

（2）缩短了开发周期，加快了工程进度。

（3）降低成本。

　缺点：

1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。

　 2、不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致：

喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）

它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性

相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分

无间隙:它在各项活动之间没有明显边界（如分析和设计活动之间<由于对象概念的应用，表达分析，设计，实现等活动只用对象类和关系>）

优点：

1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程

不便之处：

1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。

2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况

螺旋模型：（适合用于需求经常变化的项目<适合于大型复杂的系统>）

它主要是风险分析与评估，沿着螺线进行若干次迭代，

过程：

1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件

2、 风险分析：分析评估所选方案，考虑如何识别和消除风险

3、 实施工程：实施软件开发和验证；

4、 客户评估：评价开发工作，提出修正建议，制定下一步计划。

优点：

1、 它由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发中

缺点：

1、 难以让用户确信这种烟花方法的结果是可以控制的

2、 建设周期长（而软件技术发展比较快，所以经常会出现软件开发完毕后，和当前的技术水平有很大的差距，无法满足当前用户的需求）

3、 除非软件开发人员擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险

瀑布模型：（从本质来讲，瀑布模型是一个软件开发架构,重复应用）

（核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开，依照软件生命周期自上而下，相互衔接的次序<如同瀑布流水逐级下落>）

缺点：

1、 在项目各个阶段之间极少有反馈，各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量

2、 用户只有在项目生命周期的后期才能看到结果，增加了开发的风险

3、 需要过多的强制完成日期和里程碑来跟踪各个项目的阶段

4、 在每个阶段都会产生循环反馈

（如果有信息未被覆盖或是发现问题了，必须返回到上一个阶段<甚至更前面的活动>并进行适当的修改,只有当上一阶段都被确认后才进行下一阶段）

5、 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果

优点：

1、 为项目提供了按阶段分的检查点

2、 当完成一个阶段后，只需要去关注后续阶段

3、 可在迭代模型中应用瀑布模型

按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试

注：由于每个阶段都会产生循环反馈，对于经常变化的项目而言，瀑布模型毫无价值，这种模型的线性过程太理想化，已不适合现代的软件开发模式

名词解释：什么叫软件原型?

1，原型是指模拟要开发的系统的原始模型。在软件过程中，原型是软件早期一个可运行的版本，它反映最终系统的部分重要特性，如界面、功能或者性能等等。

2，原型（prototype）即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。

3，软件原型在软件设计阶段，交互设计师或者产品经理等常常需要使用一些工具（比如Visio、Axure RP、Flash或者OmniGraffle等）制作出静态稿或者原型来表达设计思想。

需求获取的常用方法有哪些？25.说明软件测试和调试的目的有何区别

需求获取的常用方法有哪些

1）用户访谈

用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组合议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照——定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列以一个粗糙的想法，根据访谈的民体情况来进行发挥。

2）用户调查

在进行用户防谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈。因此，就需要借助用户调杏的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求倍息，这样就可以克服上述的问题。

用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。

3）现场观摩

俗话说，百闻石如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之合效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随用户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记；建造软件系统不仅仅只是为了模拟客户的手下操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作为软件设计的目标。

4）文档考古

文档考古是指对历史存在的—些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。

5）建立联合分析小组

在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。

用广提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获地。

6）原型法

原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷。建造这样一个系统的目的是为了看，考察某一方面的可行性。如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于文物的有效沟通，从而帮助人们尽早解决软件开发个存在的各种不确定性。

7）模型驱动

前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通道一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。

8）基于上下文的方法

软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在—定环境下表现出来的行为，通过分析用户的行为得到信息。

说明软件测试和调试的目的有何区别

1、目的不同

软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地排除错误.它们的出发点不一样。前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是一种排除过程，是编码活动的一部分.

2、任务不同

既然软件测试属于质量保证活动，因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样。它是比较有规律的活动，有系统的方法、原则作指导。

而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如:解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有一些启发式的方法，它是一种比较依赖开发人员经验的活动。

3、指导原则和方法不同

软件侧试是一种有规律的活动，有一系列软件软件测试的原则.其中主要是制订侧试计划，然后严格执行.其次是一种挑剔性行为，因此它不但要侧试软件应该做的，还需要侧试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则，是一个推理过程。例如使用归纳法、演绎法、回溯法等。

软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。

4、操作者

因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员.

转载请注明出处51数据库 » 软件需求原型 软件工程原型模型