信息系统分析与设计(第二版)-第十章 型法的概念与方法
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
10.1.1原型法的提出背景
这种严谨的需求定义方法是在一定假设的前提 下形成的,它们是: • 所有的需求能被预先定义 • 项目参加者之间能够清晰而准确地通信 • 静态描述/图形模型对应用系统的反映是充 分的 上面假设的共同特点是:它们都是被动的通信 工具和静止的通信工具,不能表演,因而要求用户 根据一些静态的信息和静止的画面来认可系统则似 乎近于苛求。
第十章 原型法的概念பைடு நூலகம்方法
本章内容
10.1 原型法的提出
10.2 原型法的基本思想 10.3 原型法的工作步骤 10.4 原型法的关键成功因素 10.5 原型法与生命周期法的比较 小结
10.1 原型法的提出
10.1.1 原型法的提出背景
20世纪60年代末至70年代初,出现了“软件危 机”,为了对软件开发项目进行有效管理,信息系 统开发生命周期法诞生了。由于开发过程规范、层 次清晰,系统开发生命周期法得到广泛应用。但这 种方法的应用前提是需要在早期就确定用户的需求, 而不允许修改,这对于很多应用系统(如商业信息 系统)来说是不现实的。用户需求定义方面的错误 是信息系统开发中出现的后果最严重的错误。在此 背景下,提出了原型法。
10.1.1 原型法的提出背景 那么如何解决“软件危机”呢?人们越来 越重视软件开发方法的研究,通过多年的研 究和努力,软件开发方法走向两个方面: 一方面是着重研究与机器本身相关的软件开 发工具,即高级语言及软件开发环境; 另一方面,着重研究软件设计和规格说明等。
10.1.1 原型法的提出背景
本章内容
10.1 原型法的提出
10.2 原型法的基本思想
10.3 原型法的工作步骤 10.4 原型法的关键成功因素 10.5 原型法与生命周期法的比较 小结
10. 2 原型法的基本思想
• 原型法是确定需求策略,是对用户需求进行抽取、 描述和求精。它快速地、选代地建立最终系统工 作模型,对问题定义采用启发的方式,由用户作 出响应。实际上是一种动态定义技术。 • 原型法被认为,对于大多数企业的业务处理来说, 需求定义几乎总能通过建立目标系统的工作模型 来很好地完成,而且这种方法和严格定义方法比 较起来,成功可能性更大。
10.1.2 原型法(prototyping)
3. 原型分类 可以分为三类: (1)淘汰式(disposable): (2)演化式(evolutionary): (3)增量式(incremental):
10.1.2 原型法(prototyping)
4. 部分原型 在信息系统设计的过程中,常用的各种不同形式的部分 原型有: (1)对话原型 (2)数据输入原型 (3)报表系统原型 (4)数据系统原型 (5)计算和逻辑原型 (6)应用程序包原型 (7)概念原型
10.1.2 原型法(prototyping)
2.原型(prototype) • 原型(prototype)即样品、模型的意思。把系统主 要功能和接口通过快速开发制作为“软件样机”, 以可视化的形式展现给用户,及时征求用户意见, 从而明确无误地确定用户需求。同时,原型也可 用于征求内部意见,作为分析和设计的接口之一, 可方便于沟通。 • 对原型的基本要求包括:体现主要的功能;提供 基本的界面风格;展示比较模糊的部分以便于确 认或进一步明确;原型最好是可运行的,至少在 各主要功能模块之间能够建立相互连接。
10.1 原型法的提出
10.1.1 原型法的提出背景
产生“软件危机”的原因在于:用户需求不明 确,缺乏正确的理论指导,软件规模越来越大且复 杂度也越来越高。另一方面是需求与技术差异较大 引起的。
管理需求(现实世界) 现在 编程 70年代编程 4GL 高级语言/关系数据库系统 汇编语言 操作系统
10.1 原型法的提出
10.2.1 原型定义方法
• 原型法为预先定义技术提供了一种很好的 选择和补充。人们对物理模型的理解要比 对逻辑模型的理解来得准确。 • 原型法就是在人们这种天性的基础上建立 起来的,它考虑到用户有时也难免有判断 错误,不可能在系统开发过程中,提出更 多、更好的要求。原型法以一种与预先定 义完全不同的观点来看待定义问题。
10.1.2 原型法(prototyping)
1. 原型法定义 • 原型法是指在获取一组基本的需求定义后,利用 高级软件工具可视化的开发环境,快速地建立一 个目标系统的最初版本,并把它交给用户试用、 补充和修改,再进行新的版本开发。反复进行这 个过程,直到得出系统的“精确解”,即用户满 意为止。经过这样一个反复补充和修改过程,应 用系统 “最初版本”就逐步演变为系统 “最终版 本”。 • 原型法就是不断地运行系统“原型”来进行启发、 揭示、判断、修改和完善的系统开发方法。
10.2.1 原型定义方法
10.1.1原型法的提出背景
• 严格需求定义的合理性在许多情况下并不满足,特别 是在管理领域,管理需求不断变化、管理需求难以获 取,因此建立在脆弱基础上的开发策略在实施中一旦 导致系统的失败就绝非意外之事。为了更好地处理由 于缺乏支持严格方法的假设而给项目带来的风险,需 要探求一种变通的方法。 • 解决需求定义不断变化问题一种思路是在获得一组基 本的需求后,快速地加以“实现”。随着用户或开发 人员对系统理解的加深而不断地对这些需求进行补充 和细化。系统的定义是在逐步发展的过程中进行的, 而不是一开始就预见一切,这就是原型法。
• 这时系统开发生命周期应运而生。生命周期法具 有明显的优点。它采用系统观点和系统工程方法, 自顶向下进行分析与设计并自下而上进行实施。 开发过程阶段清楚,任务明确,并有标准的图、 表、说明等组成各阶段的文档资料。生命周期法 引入了用户观点,适用于大型信息系统的开发, 将逻辑设计与物理设计分开 。 • 但是,生命周期法的应用前提是严格的需求定义 方法和策略。需求定义方法是一种严格的、预先 定义的方法。从理论上讲,一个负责分析设计的 项目小组应完全彻底地预先指出对应用来说是合 理的业务需求,并期待用户进行审查、评价和认 可,并在此基础上顺利开展工作。