第四讲 项目方法选择 1.

Presentation on theme: "第四讲 项目方法选择 1."— Presentation transcript:

1 第四讲 项目方法选择 1

2 内容 技术选择 考虑风险 方法选择：过程模型 2

3 技术选择 技术选择将影响： 步骤： 3 开发人员的训练需要 人员招聘 开发环境——硬件和软件 系统维护安排
分析项目是目标驱动的还是产品驱动的 分析项目其他特征 面向数据还是面向控制 通用还是专用 是否涉及需要专用工具支持的专门技术 是否有特殊的安全性要求 对软硬件有何要求 3

4 练习 对下列系统进行分类 4 工资支付系统 饮料灌装企业的控制系统 供水企业管理对企业供水计划的系统 支持项目管理的软件
供律师查询法律条文的系统 面向数据或特定领域的应用系统 包含嵌入式软件的过程控制或者工业系统 使用图形的信息系统 通用信息系统软件包 信息收集的通用软件包 4

5 识别项目中的高风险 产品不确定性：系统需求理解的准确性。用户在开始时有可能对系统应该什么样都无法确定。在某些环境中，精确而有效的需求描述可能迅速变得过时。 过程不确定性：在项目开始时需要选择方法或过程模型，或者一种新的工具，任何对原先采用的开发方法的变化都将引入不确定性 资源不确定性：项目进行中资源的数量可能发生变化 5

6 练习 识别学院工资系统中的风险 金融和职员之间的矛盾 职员对系统不接受 缺少运行该系统的经验 缺少管理系统的计算机专业人员 需求变化 6

7 选择方法 考虑用户关于实现的需求 选择通用的生命周期方法
用户可能在合同中限定了有关实现方面的方法。例如，规定了企业必须具有相应的CMM等级，或者通过了ISO9000方法 选择通用的生命周期方法 控制系统：一般为实时系统，比如需要Petri网技术 信息系统： …… 7

8 Too often, software work follows the first law of bicycling: No matter where you’re going, it’s uphill and against the wind

9 过程模型的选择 开发一个软件需要选择开发策略（包括过程，方法和工具）以及通用阶段，这些策略和阶段被称为过程模型 “过程”：相关联的活动
过程模型的选择基于项目和应用的特性，使用的工具和方法，所需要的控制方法和交付物。 9

10 软件过程的概念 软件过程由关于项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关对象（计划、文档、模型、编码、测试、手册等）组成。
一个过程定义了为达到某个确定的目标，需要什么人在什么时间以何种方式做何种工作 软件需要一个可用于指导顾客、用户、开发人员和项目经理等参与者的过程 10

11 软件开发过程 软件工程的核心是过程。产品、人员、技术通过过程关联起来。软件开发过程能够将技术集成在一起从而使软件的开发能够以一种合理而及时的方式完成。 过程 技术 人员 产品 客户 特性 业务 条件 开发 环境 11

12 有效的软件过程 有效的软件过程可以提高组织的生产能力 有效的软件过程也可以改善软件组织对软件的维护能力 12
保证软件开发的基本原则的实现，辅助软件项目管理者作出明智的决定； 使软件开发活动标准化，提高软件的可重用性和Team间的协作； 有效的软件过程也可以改善软件组织对软件的维护能力 通过有效地定义如何管理需求变更，使得变更部分能够在未来的版本中恰当分配，实现平滑过渡； 在具体操作和相关支持中定义如何平滑地改造软件，并且这种具体操作和支持是可实施的；不可实施的软件过程被剔除。 12

13 问题求解的一般过程 问题求解的一般过程 实际问题并不能简单划为四个阶段，各个阶段会在问题的不同层次上同时并存
软件开发实际上是一个“混沌”（chaos）过程（Raccoon） 问题定义 现状 技术开发 方案集成 13

14 编码修正模型 Code and Fix Code like Hell(鲁莽编码)
从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作 发布（可能） 可能有可能没有的规范 14

15 编码修正模型 好处： 对于规模稍大的项目，采用这种模型是很危险的 成本可能很低 只需要很少的专业知识，任何写过程序的人都可以
对于一些非常小的、开发完后就会很快丢弃的软件可以采用 对于规模稍大的项目，采用这种模型是很危险的 15

16 瀑布模型（Waterfall Model)
所有过程模型的祖宗 项目从开始到结束按照一定的顺序执行 瀑布模型是文档驱动的，各个阶段不连续也不交叉 16

17 瀑布模型 发 瀑布模型适应于什么场合？有何优缺点？ 17

18 瀑布模型 当有一个稳定的产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适
当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，瀑布模型也特别合适。 纯瀑布模型能够降低管理费用，因为你可以预先完成所有计划。 对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。 在质量需求高于成本需求和进度需求的时候，它尤为出色。 当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。 18

19 瀑布模型 纯瀑布模型的缺点是在项目开始的时候，在设计工作完成前和代码写出来前，很难充分描述需求。
瀑布模型最主要的问题是缺乏灵活性。必须在项目开始前说明全部需求。但这恰恰是非常困难的。 19

20 瀑布模型变种：V型模型 该方法是对瀑布模型的修正，强调了验证活动 20

21 瀑布模型变种：生鱼片模型 把阶段重叠起来的瀑布模型 起源于日本硬件开发模型（富士通—施乐） 软件概念 需求分析 架构设计 详细设计
编码和调试 系统测试 21

22 瀑布模型变种：生鱼片模型 传统的瀑布模型强调阶段之间最小的重叠，而生鱼片模型强调大幅度的重叠，即在需求分析完成之前就可以进行架构设计和部分详细设计 纯瀑布模型强调在任意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是如果一个团队完成各个阶段任务时，可以没有那么多文档。 问题：缺点是什么？ 生鱼片模型因为阶段重叠，因而里程碑不明确，很难有效地进行过程跟踪和控制。 22

23 瀑布模型变种：具有子项目的瀑布模型 纯瀑布模型的一个问题是必须完成全部的架构设计后才能进行详细设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为为子项目。 问题：该模型有何问题？ 这种方法的主要风险是相关性无法预料。 23

24 纯瀑布模型要求在开始架构设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。
瀑布模型变种：能够降低风险的瀑布模型 纯瀑布模型要求在开始架构设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。 可降低风险的瀑布模型是在顶端，即需求分析和架构设计阶段引入螺旋以便降低风险。 在该螺旋中，先开发一个用户界面原型，采用系统情节串联图版（system storyboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。 24

25 螺旋模型 Spiral 模型（Boehm提出） 以风险为导向的生命期模型
从一个小范围的关键中心地带开始寻找风险因素，制定风险控制计划，并交付给下一步骤，如此迭代，每次迭代将项目扩展到一个更大的规模 25

26 问题：有何优缺点？ The spiral model 26 Cumulative cost Progress through steps
Evaluate alternatives, identify, resolve risks Determine objectives, alternatives, constrains Risk analysis Risk analysis Risk analysis Risk analy-sis Prototype 1 Operational prototype 问题：有何优缺点？ Prototype 2 Prototype 3 Review Commitment Partition Requirements plan, life-cycle plan Simulations, models, benchmarks Concept of operation Detailed design Software requirements Software product design Develop-ment plan Requirements validation Code Unit test Integration and test plan Design validation and verification Integration and test Acceptance test Plan next phases Implementation Develop, verify next-level product The spiral model 26

27 螺旋模型 优势：随着迭代的增加（成本的增加），风险程度随之降低 缺陷：比较复杂，需要责任心，专注和管理方面的知识。 27

28 WINWIN螺旋模型 在螺旋模型中，通过与客户的通信获取客户的需求，实际上，客户的需求与最终确定的需求是不一致的，客户与开发者之间需要进行协商，最终达到双赢的局面。 Boehm提出的WINWIN螺旋模型中，客户与开发者之间需要 识别系统或子系统的关键涉及者（stakeholders） 确定涉及者的“win conditions” 对这些条件进行协商获得互赢条件 28

29 WINWIN螺旋模型 WINWIN螺旋模型还引入了三个过程的里程碑，被称为定位点（Anchor points）
生命周期目标（life cycle objectives）定义了每个主要活动的目标 生命周期体系结构（life cycle architecture）定义了系统和软件的体系结构目标 初步操作能力（initial operational capability）定义了软件安装，发布的目标。 29

30 并行开发模型 并行开发模型（concurrent development model）又被称为并行工程（concurrent engineering）（By Davis and Sitaram） 软件开发中的所有活动可能同时并存，但是都处于不同的状态中 并行开发模型定义了活动从一个状态转化为另一个状态的事件 30

31 并行开发模型 Analysis activity 31 None Under development Awaiting changes
Under review Under revision Baselined Done 31

32 并行开发模型 并行过程模型经常被用于开发C/S系统。该系统的活动可以被分为系统维和部件维。系统维包含了设计，装配和使用三个活动，而部件维包含了设计和实现两个活动。并发性表现在两个方面： 系统和部件的活动同时发生 各个部件可以并行设计和开发 32

33 原型法 原型法 原型是项目系统中的一个方面或者多个方面的工作模型。 抛弃型原型：用于试验某些概念，试验完系统将无用处
进化型原型：原型系统不断被开发和被修正，最终它变为一个真正的系统。 33

34 原型法 原型的好处 从实践中学习(Learning by doing) 改善的通信 改善的用户参与 使部分已知的需求清晰化
展示描述的一致性和完整性 可能可以减少文档 减少了维护成本 特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误） 试验是否能产生期待的结果 34

35 原型法 原型法的缺点 用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠 缺少项目标准，进化原型法有点像编码修正
缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制 额外的花费：研究结果表明构造一个原型可能需要10%额外花费 运行效率可能会受影响 原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。 35

36 从另外的角度看待原型 从中学到什么？ 原型起作用的程度 学生经常会做一些软件作业，这些作业也被称为原型
问题：这些原型和软件系统原型是否相同？ 作为一个原型必须：描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容。 在不同的阶段，原型具有不同的作用。 原型起作用的程度 实物模型（Mock-ups） 仿真交互 部分模型：水平，垂直（某些特性构造详细的原型） 36

37 构造原型的对象 人机接口 系统的功能 37

38 练习：何时引入原型系统 保险公司的经理需要通过个人计算机上的一个系统来访问管理信息。该系统价格必须合适。很多人怀疑是否经理真需要使用该系统。
可行性研究阶段，采用实物模型的方法 支持客户销售人员通过电话回答有关客户询问汽车保险价格的系统 设计用户对话界面时 保险公司考虑实施一个基于MS Access的电话销售系统，他们不知道Access是否能够开发出相应界面的系统并具备足够快的相应时间。 方案设计阶段 38

39 阶段交付 阶段交付持续地在确定的阶段向用户展示软件。
和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。 39

40 阶段交付 软件概念 需求分析 构架设计 阶段1：详细设计，编码，调试，…… 阶段2：详细设计，编码，调试，…… 40

41 阶段交付 阶段交付的优点是项目结束交付全部成果前，分阶段将有用的功能交付给用户。
阶段交付的主要缺点是，如果管理层面和技术层面上缺乏仔细的规划，工作就无法进行。 使用阶段交付的注意点是： 必须确定每一阶段的交付是对用户有用的 必须确保考虑了不同产品组成部分的技术依赖关系 41

42 面向进度的设计 类似于阶段交付，但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何目标，但是要确保最后的期限。
该模型的关键是要按优先级别划分系统特性并规划开发阶段，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。 是否采用这种方法决定于你是否对系统目标具有足够的信心，如果有信心，则没必要采用这种方法。 42

43 渐进交付 渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。 基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。
如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。 渐进原型，强调的是系统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底层系统功能。 43

44 渐进交付 软件概念 需求分析 交付最终版本 构架和内核设计 开发一个版本 并入用户反馈 交付该版本 开发一个版本 44

45 确定渐进交付目标的一种方法 价值成本比 45

46 面向开发工具的设计 只在现有软件工具直接支持的情况下增强产品的功能，如果它不支持，就放弃这些功能。
当时间成为主要约束时，采用该模型能够比其他模型能够更完整地实现功能。 该方法的缺点是你失去了很多对产品的控制能力。 46

47 商品软件 商品软件也许未必满足你所有的要求，但是自己开发也需要一个周期，到那个时候，商品软件可能已经满足了你的要求。
商品软件可能存在不足，但是，你自己开发的产品也未必那么完美，当你补充了商品软件的不足时，也许带来了新的问题。 因而，商品软件始终是一个值得考虑的方案。 47

48 案例研究// 某教育部门希望目前的中小学有一个现代化的信息交流平台，即校务管理系统，为此他们提出了需求，希望软件公司能够开发此软件。
该软件是对学校校务和教学活动进行综合管理的平台系统，是一个学校和地区教育信息化的基础信息平台，它要完成学校管理层、教师，学生，家长等日常工作，学习，管理，咨询等任务。 48

49 49

50 50

51 51

52 52

53 53

54 54

55 欢迎光临过程模型选择咖啡厅，希望您好胃口
过程模型咖啡厅 晚餐菜单 欢迎光临过程模型选择咖啡厅，希望您好胃口 正餐 螺旋模型 手制烤鸡，外配风险减少调味料 15.95美元 渐进交付模型 用水拌成的阶段交付及渐进原型 55

56 阶段交付模型 五门课程酒席，详情请问服务员 14.95美元 面向进度的设计 各种方法学，特别适合于快速运作 11.95美元 纯瀑布模型 按经典的原有菜谱制作 56

57 色拉 面向工具的设计 填鸭内填各种豆角 时价 商用软件 名厨手艺，每日变动 4.95美元 编码及查错 大碗面 整日供应 5.95美元 57

58 The End