sys03-系统开发方法-v2015

1、系统分析与设计,大连理工大学 软件学院,SYS-03：信息系统开发方法,软件生命周期模型 原型化方法 快速应用程序开发 敏捷建模,大连理工大学 软件学院,2,1. 软件生命周期模型,3,4,5,开发生命期 (SDLC),瀑布模型（Waterfall Model）,6,迭代式模型（Rational Unified Process）,7,快速应用程序开发（RAD）与SDLC,8,识别目标和信息需求,与用户共同合作设计系统,构建系统,介绍系统,用户反馈,使用来自客户的建议,RAD,需求规划，分析阶段,设计，开发，编制文档阶段,SDLC,快速原型（Rapid Prototype）模型,9,大连理工大学

2、 软件学院,10,螺旋模型,11,V字模型,12,2. 原型化方法,13,14,原型,1. 原型化方法,在提交信息系统原型是，观察用户和管理层对原型的反应。 明确地知道他们使用原型时的反应？ 他们的需求与系统的原型化特征的吻合程度？ 通过“观察”，“面谈”，反馈表（调查表）收集上述反应。,15,1.1 原型的种类,大连理工大学 软件学院,16,输入,处理,输出,拼凑原型,非操作原型,系列首发原型,精选特征原型,设备1,设备2,设备3,特征1,特征3,特征5,1.1 原型的种类,拼凑原型 构建一个可以运行的，经过修补或拼凑出来的系统。 工程上称：实验电路板 创建一个拼凑起来的，集成电路工作模型。

3、 具有所有必要特征，低效的工作模型。 用户熟悉系统提供的界面，输出类型。 信息的恢复，存储可能是低效的。,大连理工大学 软件学院,17,1.1 原型的种类,非操作原型 为了试验设计方案的某些方面而建立的一个非工作比例模型。 风动试验的汽车实物模型 尺寸，形状是精确的 却不能行驶 只包括风洞测试必须的汽车特性 编码工作对原型来说过于昂贵，只要对输入输出进行原型化设计。 减少必要的成本和时间 不处理过程进行原型设计,大连理工大学 软件学院,18,1.1 原型的种类,系列首发原型 创建一个实物模型，通常称为试验模型。 一系列飞机的首架飞机进行原型化设计： 完全可以操作的 设计者对拥有相同特征的一系列

4、飞机的期望实现。 计划多次安装同一个信息系统，这种原型化方法就很有用。 重视用户体验，新系统的真实交互。,大连理工大学 软件学院,19,1.1 原型的种类,精选特征原型 一个包括最终系统的部分特征，而不是全部特征的可工作模型。 新的大型购物中心在所有商店全部竣工前就开张了。 例：菜单中应包括： 增加记录，更新记录，删除记录，案关键词查询，显示记录或扫描记录 只实现：增加记录，删除记录，显示记录 这种原型实现了，系统的模块化就实现了。 如果原型特征经评估成功，就可以将它们合并到最终的大型系统中。,大连理工大学 软件学院,20,1.2 SDLC的一种代替方案,应该把原型化方法看作SDLC的一种替代

5、方案。,大连理工大学 软件学院,21,开发生命期 (SDLC),1.2 SDLC的一种代替方案,SDLC过程中： 贯彻开发生命期所需漫长的时间。 投入时间的增加，提交系统的成本也称比例地上升。 用户需求随时间而变化。 需求和交付完成的系统漫长时间间隔内，用户需求不断演进。 由于漫长的开发周期，最终系统可能因为没有充分满足用户需求，受到指责。,大连理工大学 软件学院,22,1.2 SDLC的一种代替方案,用户只有在看到了切实内容，才知道他们确实需要什么，不需要什么。 SDLC中，系统一旦交付使用，要修改系统缺点会为时已晚。 用原型化方法取代SDLC： 有效地缩短确定信息需求与交付可工作系统之间的

6、时间。 克服精确地识别用户信息需求。 完全了解决的问题或机会之前，过早地形成了一个系统。 会导致别一部分用户群接受，却不能够充分满足总体系统需要。,大连理工大学 软件学院,23,大连理工大学 软件学院,24,鱼与熊掌不可兼得？,把原型化方法作为SDLC的一部分,2. 原型的开发,原型化方法是 一种获取有关建议的系统 系统如何迅速满足用户需求的反馈信息 方便信息系统融入组织的更大系统方面，原型化方法是一种好方法。,大连理工大学 软件学院,25,2.1 开发原型的准则,把开发原型方法集成到SDLC的需求确定阶段是，就必须遵循4条主要准则： 引进便于管理的模块 快速建立原型 用连续迭代来修改原型 强

7、调用户界面,大连理工大学 软件学院,26,2.1 开发原型的准则,1. 引进便于管理的模块 原型化方法的一个明显优点： 没有必要为了原型的目的，而建立一个完全可工作的系统。 一个可管理的模块： 可以脱离系统的其他模块，独立创建。 允许用户与系统的关键特征进行交互。 初始原型中可以有意地省去不太重要的模块特征。,大连理工大学 软件学院,27,2.1 开发原型的准则,2. 快速建立原型 速度对于成功地建立信息系统的原型是必不可少的。 SDLC方法： 开发时间过长，不能有效地处理不断变更的用户需求。 Step 1：使用信息获取技术查明重要的需求； Step 2：使用原型化方法缩短时间间隔； Step

8、 3：迅速地做出构建一个工作模型的决策。,大连理工大学 软件学院,28,2.1 开发原型的准则,3. 用连续迭代来修改原型 原型的构造必须支持修改： 意味着不必用高度依赖的模块来建造原型。 原型需要修改时就会遇到较少的阻力。 原型要经过多次修改，多次迭代： 使系统更加贴近用户认为是重要的东西。 每一次修改都需要用户进行再次评估。 原型并不是一个完成的系统： 带着原型需要修改的观点，进入原型化阶段是一种很有益的态度。,大连理工大学 软件学院,29,2.1 开发原型的准则,4. 强调用户界面 用户界面是非常重要的： 建立原型的目的：促使用户所出他们的信息需求。 用户必须能够与系统原型轻松交互。 能

9、够看到原型是怎样使他们完成任务的。 对很多用户来说，界面就是系统。 使用户能够快速地掌握系统，并且不厌恶系统。,大连理工大学 软件学院,30,2.2 原型化方法的缺点,很难像大型系统中的一个项目那样管理原型。 当原型实际上还不充分，或绝不可能成为最终系统时： 用户和分析员可能把原型当做最终系统。 必须确保清楚地向用户说明： 他们与原型交互，改善原型的时间表。 权衡： 是否原型化？ 什么时候原型化？ 系统的多少部分要原型化？,大连理工大学 软件学院,31,2.3 原型化方法的优点,原型化方法并非是每一个系统项目所必须的。 原型化方法并不适合么一个系统项目。 原型化方法3个优点： 可以在系统开发早

10、期改变系统。 可以中止一个不能工作的系统开发。 可以开发出更贴近用户需求和期望的系统。 成功的原型化方法依赖于及早，频繁的用户反馈。 可以帮助修改系统，是系统能够反映实际需求。 项目开发中，早期做出改变比晚期做出改变花费要少得多。,大连理工大学 软件学院,32,2.4 使用COTS软件进行原型化,构建原型的最快方法： 通过COTS软件的模块化安装。 诸如：Microsoft Office产品 一些COTS软件是精心开发的，而且比较昂贵，但是非常有用。 COTS（Commercial Off-The-Shelf）： 商业可利用技术 将商品化的产品，或技术拿来直接使用。 在军事装备设计生产过程中提

11、出来的,并逐渐引深扩大到整个商业技术领域。 COTS技术的核心 将现有的技术或产品直接应用到正在开发的产品中。,大连理工大学 软件学院,33,3. 用户在原型化方法中的角色,与原型交互： 体验原型 与纯粹的系统特征相比，原型允许用户真实体验与系统的交互。 把原型放在交互式Web站点上是一种推动交互的方法。 对原型做出坦率的反应 是用户能够做出坦率的反应，是团队努力建立分析员和用户间关系的一部分。 建议增加，或删减原型的功能 观察用户和系统的交互。 与用户举行简短的体验面谈。 根据需要把它转换成可以的变化。,大连理工大学 软件学院,34,大连理工大学 软件学院,35,3. 快速应用程序开发,36

12、,大连理工大学 软件学院,快速应用程序开发,快速应用程序开发 Rapid Application Development, RAD 一种面向对象的系统开发方法。 包括：开发方法，软件工具 RAD与原型化方法在概念上接近： 都是尽量更好地满足迅速变化的商业需求。 可以认为RAD是原型化方法的一种特殊实现。,大连理工大学 软件学院,37,1. RAD阶段,大连理工大学 软件学院,38,需求规划,RAD设计研讨会,实现,1. RAD阶段,阶段1： 需求规划 用户和分析员共同确定应用程序或系统的目标。 这些目标引起的信息需求。 要求组织内部不同层次的用户参与。 主要方式：解决业务问题。 核心：始终保持

13、在实现业务目标上。 如果在需求规划阶段，仍忙于确定信息需求： 特别旨在促进组织的战略目标的电子商务应用程序 可以与CIO（Chief Information Officer，首席信息官），战略规划者合作。,大连理工大学 软件学院,39,1. RAD阶段,阶段2：RAD设计研讨会 一个设计和改良阶段。 研讨会：参与者应该是主动，而不是被动的。 在RAD设计研讨会期间： 用户对实际的工作原型做出反应； 分析员根据用户的反应，改良实际的模型。 有经验的用户和分析员参与，这种创造性的努力能够加快开发进程。,大连理工大学 软件学院,40,1. RAD阶段,阶段3：实现 分析员与用户达成了一致的意见，建立

14、和优化系统之后； 对新系统，或系统一部分进行测试； 然后再把他们介绍给组织。 RAD设计研讨会： 已经产生了用户所有权 并且接受了新的应用程序。 相较于几乎没有用户参与交付的系统： 以这种方式造成的变更更容易让人理解。,大连理工大学 软件学院,41,1. RAD阶段,RAD软件工具： 它们通常是新颖的，面性对象的工具。 熟悉的程序： Microsoft Access，Visual Basic, C+, .NET等 工具软件间的差别： 支持客户/服务器应用程序能力。（Access不支持） 使用的难易程度 所需要掌握的程序技术等。 RAD的真正能力应该用于需要跨平台运行的客户/服务器应用程序 目前

15、，多数RAD还停留在小型PC方面。,大连理工大学 软件学院,42,2. RAD与SDLC的比较,大连理工大学 软件学院,43,识别目标和信息需求,与用户共同合作设计系统,构建系统,介绍系统,用户反馈,使用来自客户的建议,RAD,需求规划，分析阶段,设计，开发，编制文档阶段,SDLC,2. RAD与SDLC的比较,何时使用RAD？ 团队中有用过RAD的程序员和分析员； 由于商业压力，要求加快应用程序中部分的开发； 从事一项全新的电子商务应用程序 该应用程序第一个，第一批出现在Web上，企业作为一个创新者取得竞争优势。 用户富有经验，并对公司的组织目标高度负责。,大连理工大学 软件学院,44,2.

16、 RAD与SDLC的比较,RAD的缺点： RAD的困难是由系统分析员急于完成项目而引起的。 基于SDLC的木匠： 列出每一件工具，院子里的家具清单，确定储藏库的尺寸，设计储藏库的蓝图 为每一根木材，五金器制定规格 如果有人想建造另一个储藏库？ 基于RAD的木匠： 立即投入到工程中去 估计储藏库的尺寸 与业主讨论已作出调整。 储藏库建好了，但是没有蓝图？,大连理工大学 软件学院,45,4. 敏捷建模,46,大连理工大学 软件学院,47,敏捷开发,4个控制要素，4个活动,48,敏捷开发,4个核心实践： 简短发布（short release） 必须快速发布产品 软件中不能实现所有特征 每周工作40小

17、时（40-hour work week） 软件开发硅谷（Silicon Valley）模式鼓励程序员一办公室为家，昼夜不停工作。 敏捷开发有目的地辞职一种文化核心时间，每周40小时工作，有松有驰。,49,敏捷开发,4个核心实践： 现场客户（onsite customer） 客户对系统的成功十分重要。 在整个系统开发过程中，企业的一名专家应在现场办公。 结对编程（pair programming） 两个选择一起编程的程序员都进行编程，执行测试 互相探讨能够快速开发的方法。 结束时间，减少疏忽，激发创造力,50,敏捷开发,51,敏捷开发,鱼骨图可以用来标识开发一个系统中可能出错的所有事情,52,1

18、. 敏捷建模的价值观,大连理工大学 软件学院,53,1. 敏捷建模的价值观,沟通 建模能够促进你团队内部的开发人员之间沟通 简化 着手解决我们能做的最简单的事情。 画一两张图表来代替几十甚至几百行的代码 通过这种方法，建模成为简化软件和软件（开发）过程的关键。 反馈 “乐观是编程的职业病，反馈则是其处方。” 通过图表来交流你的想法 可以快速获得反馈，并能够按照建议行事。,大连理工大学 软件学院,54,1. 敏捷建模的价值观,勇气 有勇气重新开始。 你就需要做出重大的决策，放弃或重构（refactor）系统，修正方向。 谦逊 最优秀的开发人员都拥有谦逊的美德， 总能认识到自己并不是无所不知的。

19、无论是开发人员还是客户都有自己的专业领域，都能够为项目做出贡献。 一个有效的做法 假设参与项目的每一个人都有相同的价值，都应该被尊重。,大连理工大学 软件学院,55,2. 敏捷建模的原则,大连理工大学 软件学院,56,2. 敏捷建模的原则,主张简单 主张最简单的解决方案就是最好的解决方案。 不要过分构建（overbuild）系统 如果你现在并不需要这项额外功能，那就不要在模型中增加它。 要有这样的勇气： 现在不必要对这个系统进行过分的建模（over-model） 只要基于现有的需求进行建模 日后需求有变更时，再来重构这个系统 尽可能的保持模型的简单,大连理工大学 软件学院,57,2. 敏捷建模

20、的原则,拥抱变化 需求时刻在变，用户对于需求的理解也时刻在变。 项目进行中，目标和信息需求也有可能发生变化。 这就意味着随着项目的进行，项目环境也在不停的变化，因此开发方法必须要能够反映这种现实。 可持续性 即便一个能够运转的系统交付给用户，项目也还可能是失败的。 其中包括系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展。,大连理工大学 软件学院,58,2. 敏捷建模的原则,递增的变化 和建模相关的一个重要概念是不用在一开始就准备好一切。 实际上，就算想这么做也不太可能。 而且，你不用在模型中包容所有的细节，只要足够的细节就够了。 没有必要试图在一开始就建立一个囊括一切的模型，

21、只要开发一个小的模型，或是概要模型 打下一个基础，然后慢慢的改进模型; 或是在不在需要的时候丢弃这个模型。 这就是递增的思想。,大连理工大学 软件学院,59,2. 敏捷建模的原则,高质量的工作 要尽情享受工作，良好的团队合作，良好的项目运作。 做这项工作的人不喜欢，是因为没有成就感； 日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新； 最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。,大连理工大学 软件学院,60,2. 敏捷建模的原则,快速反馈 从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。 和用户共同开发模型，目标与需求可以立刻获得反馈 和

22、客户紧密工作，获得快速反馈的机会。 去了解客户的的需求 去分析这些需求 去开发满足客户需求的用户界面,大连理工大学 软件学院,61,2. 敏捷建模的原则,其他重要概念： 毫无畏惧地，诚恳地进行自由交流的思想。 发挥人的自然趋势： 成功的需要，与他人交流，被信任，等 承担一个任务的责任。 局部适应从敏捷开发中学到的方法。 其他： 有目的地建模 软件是主要目标 轻松旅游（表示文档越少越好）,大连理工大学 软件学院,62,2. 敏捷建模的原则,极限编程 Extreme Programming，XP 由KentBeck在1996年提出 XP是一种近螺旋式的开发方法 它将复杂的开发过程分解为一个个相对比

23、较简单的小周期； 通过积极的交流、反馈以及其它一系列的方法， 开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等， 并根据实际情况及时地调整开发过程。 XP强调把它列出的每个方法和思想做到极限、做到最好；其它不提倡的，则一概忽略。 能够做到一周40小时工作制而不拖延项目进度,大连理工大学 软件学院,63,3. 敏捷建模的实践,基本活动1： 需求 每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面实现了相应的计划中的所有需求。 而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发完成后才能开始使用。,大连理工大学 软件学院,64,

24、3. 敏捷建模的实践,基本活动2：设计 提倡对于简单的设计（Simple Design） 就是用最简单的方式，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。 强调抛弃那种一揽子详细设计方式（Big Design Up Front） 因为这种设计中有很多内容是现在或最近都根本不需要的。 提倡设计复核（Review）、代码复核以及重整和优化（Refectory） 在这些过程中不断运行单元测试和功能测试 可以保证经过重整和优化后的系统仍然符合所有需求。,大连理工大学 软件学院,65,3. 敏捷建模的实践,基本活动3：编程 提倡两个人一起写同一段程序（Pair Programming）

25、代码所有权是归于整个开发队伍（Collective Code Ownership） 程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。 任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。 结对编程的好处: 一个人编写代码时另一个人在思考。 如果编码者遇到障碍，他们就交换位置。 如果两个人都遇到障碍，他们的讨论可能被在这个区域工作的其他人听到，可能给出帮助。,大连理工大学 软件学院,66,3. 敏捷建模的实践,基本活动4：测试 在开始写程序之前先写单元测试。 每次整合后都要运行单元测试； 做任何的代码复核和修改，都要运行单元测试； 发现了BUG，就要增加相应的测试。 开发人员应该经常把开发好的模块整合到一起（Continuous Integration） 整合测试，功能测试、负荷测试和系统测试等。 所有这些测试，是开发过程中最重要的文档之一，也是最终交付给用户的内容之一。,大连理工大学 软件学院,67,3. 敏捷建模的实践,核心实践1：简单设计(Simple Design) 尽可能的使模型（需求、分析、架构、设计）保持简单。 除非有充分的理由，不应该随便