项目方法的选择

原型模型适合的项目
项目的需求在项目开始前不明确 需要减少项目需求的不确定性 类似的项目如：

确定显示界面 第一次开发的产品，验证可行性
原型法
原型法的缺点





用户有时误解了原型的角色，例如，他们可能误解 原型应该和真实系统一样可靠 缺少项目标准，进化原型法有点像编码修正（code and fix） 缺少控制，由于用户可能不断提出新要求，因而原 型迭代的周期很难控制 额外的花费：有统计表明，构造原型可能有10% 的额外花费 运行效率可能会受影响 原型法要求开发者与用户密切接触，有时这是不可 能的（如软件外包）
软件概念
需求分析
架构设计
详细设计 编码和调试
系统测试
传统的瀑布模型强调阶段之间最小的重叠，而 生鱼片模型强调大幅度的重叠，即在需求分析 完成之前就可以进行架构设计和部分详细设计。 纯瀑布模型强调在任意两个阶段交接时，文档 从一个团队交给另一个完全隔离的团队，但是 如果一个团队完成各个阶段任务是，可以没有 那么多的文档。 优点：加快进度。 问题：缺点是什么？

因为阶段重叠，因而里程碑不明确，很难有效的进 行过程跟踪和控制。
螺旋模型
以风险为导向的生命期模型 从一个小范围的关键中心地带开始寻找 风险因素，制定风险控制计划，并交付 给下一个步骤，如次迭代，每次迭代将 项目扩展到一个更大的规模。
Spiral Model
螺旋模型沿着螺线旋转，在四个象限上分别 表达了四个方面的活动，即： 制定计划──确定软件目标，需求和选定实 施方案，弄清项目开发的限制条件 风险分析──评估所选方案，考虑如何识别 和消除风险 实施工程──实施软件开发，编码，测试等 客户评估──评价开发工作，提出修正建议， 规划下期任务
过程不确定性：

资源不确定性：

方法选择
考虑用户关于实现的需求

用户可能在合同中限定了有关实现方面的方 法。例如，规定了企业必须具有相应的 CMM等级，或者通过了ISO9000方法。
选择通用的生命期方法

控制系统：一般为实时系统，比如需要 Petri网技术
Too often, software work follows the first law of bicycling: No matter where you’re going, it’s uphill and against the wind.
阶段目标：根据合同和初步需求分析，确定项目的规模，时间计划 和资源的需求 输入：合同文本 过程：项目规划、计划确认 输出：项目计划 阶段目标：确定用户需求 输入：项目计划 过程：需求获取、需求分析、需求控制 输出：需求规格、原型系统 阶段目标：总体系统结构设计 输入：需求规格、原型系统 过程：总体设计 输出：系统设计说明书，数据库结构定义

公司的财务系统 库存管理系统
问题：

缺乏灵活性。 必须在项目开始前说明全部需求，但这恰恰 是非常困难的。
V型模型
项目规化
需求分析 总体设计 详细设计
评审
用户验收 集成测试 系统测试 单元测试
编码和调试
chapter__3 19
V型模型
该方法是对瀑布模型的变种，强调了验 证活动。

扩展了瀑布模型的测试活动 理想的情况下，改正活动只应该返回对应层 次的下层。
可行性？可行性可能在系统实现前几个 月或者几年前执行。
项目的需求在项目开始前很明确 解决方案在项目开始前也很明确 对系统的性能安全很严格的项目 类似的项目如：

航天飞机等 公司的财务系统
瀑布模型变种：生鱼片模型
把阶段重叠起来的瀑布模型 起源于日本硬件开发模型（富士通-施乐）
需求分析阶段
来自百度文库
说明用户会增加新的需求。
对一个管理方式已经比较成熟的学校，要完全 舍弃原有的管理方式，用校务通系统替换全部 管理，这是不实际的。

所以，可以从最基础的做起，逐步的扩充其功能。
项目计划 需求分析 总体设计
增 量 1
增 量 2
增 量 3
增 量 4
增 量 5
增 量 6
集成测试 产品移交
项目规划阶段

可能有、可能没有规范
Code and fix
需 求 了 解
编 码
编 译 、 检 错
修 正
编 写 文 档 测 试
提 交
chapter__3
12
好处：


成本可能很低 只需要很少的专业知识，任何写过程序的人 都可以 对一些非常小，开发完后就会很快丢弃的软 件可以采用
对于规模稍大的项目，采用这种模型是 很危险的。
过程模型的选择
软件过程是将用户的需求转化成有效的 软件解决方案的一系列活动。 开发一个软件需要选择开发策略（包括 过程、方法和工具）以及通用阶段，这 些策略和阶段称为过程模型。 过程模型的选择基于项目和应用的特性， 使用的工具和方法，所需要的控制方法 和交付物。
软件过程的概念
软件过程由相关项目的阶段、状态、方 法、技术和开发、维护软件的人员以及 相关对象（计划、文档、模型、编码、 测试、手册等）组成。 一个过程定义了为达到某个确定的目标， 需要什么人、在什么时间以何种方式做 何种工作。 软件需要一个可用于指导顾客、用户、 开发人员和项目经理等参与者的过程。
第四讲：项目方法的选择
内容
技术选择 考虑风险 方法选择
技术选择
技术选择将影响：


开发人员的训练需要 人员招聘 开发环境——软硬件 系统维护安排 分析项目是目标驱动还是产品驱动 分析项目的其它特征


步骤


面向数据还是面向控制 通用还是专用 是否涉及需要专用工具支持的专门技术（并发处理、专家系统、 GIS） 是否有特殊的安全性（safe）要求 对软硬件有何要求（PC Vs. 大型机 ）
识别项目中的高风险
产品不确定性：

系统需求理解的准确性。用户在开始时有可能对系 统应该什么样都无法确定。在某些环境中，精确而 有效的需求描述可能迅速变得过时。 在项目开始时需要选择方法或过程模型，或者一些 新的工具，任何对原先采用的开发方法的变更都将 引入不确定性。 项目进行中资源的数量可能发生变化。例如公司待 遇、其它项目的影响。
渐进交付
渐进交付是一种跨越了渐进（进化）原型和增 量式交付两种模型的过程模型。 基本过程：开发一个产品的版本，展示给客户， 根据反馈改善产品。 如果计划满足用户的绝大多数需求，渐进交付 与渐进原型差不多。如果计划满足少量的需求， 渐进交付与增量式交付差不多。 渐进原型强调的是系统看得见的样子，再回来 堵漏洞；渐进交付中，最初的重点是系统核心 和底层系统功能。
增量式交付
增量式交付：持续地在确定的阶段向用 户展示软件。 与渐进原型不同，在增量式交付的时候， 你明确地知道下一步要完成什么工作， 增量式交付的特点是不会在项目结束的 时候一下交付出全部软件，而是在项目 的整个开发过程中持续不断的交付阶段 性成果。
增量式交付
增量式交付模型的特点
阶段式提交一个可运行的产品 关键的功能更早出现 早期预警问题，避免软件缺陷不知不觉 的增长 减少报告负担 阶段性完成可以降低估计失误 阶段性完成均衡了弹性与效率
瀑布模型
最早，被广泛使用的过程模型
需求分析 验证 规格说明 验证
变化的需求 验证
瀑布模型适用于什么场合，有何 设计 验证 优缺点？
编码 测试
综合测试 维护
瀑布模型特点
特点：

阶段顺序执行 严格的质量保证 推迟实现
瀑布模型适用条件
当有一个稳定的产品定义和很容易被理解的技 术解决方案时，纯瀑布模型特别合适。 当一个定义很好的版本进行维护或将一个产品 移植到一个新的平台 对于容易理解但很复杂的项目，采用纯瀑布模 型比较合适，因为可以用顺序的方法处理 当开发队伍技术力量比较弱或者缺乏经验时， 瀑布模型更为合适 类似的项目如：
软件开发过程
软件工程的核心是过程。产品、人员、 技术通过过程关联起来。软件开发过程 能够将技术集成在一起从而使软件的开 发能够以一种合理而及时的方式完成。 许多软件组织无法正确定义和控制这一 过程，但这恰恰是组织改进的关键。
有效的软件过程
有效的软件过程可以提高组织的生产能力

保证软件开发基本原则的实现，辅助软件项目管理 者做出明智的决定； 使软件开发活动标准化，提高软件的可重用性和 Team间的协作；

这样，只有等到一个可用的产品出来，通过客户使用这个可 用产品，然后进行评估，评估的结果作为下个增量的开发计 划。下一个增量发布一些新增的功能和特性，直至产生最终 的完善产品。
在校务通系统需求中，要求系统有可扩充性。

若使用增量式模型，可以保证系统的可扩充性。
“系统要求有可扩充性，可以在现有系统的基 础上，通过前台就可以加挂其他功能模块”
面向开发工具的设计
只有现有软件工具直接支持的情况下增 强产品的功能，如果他不支持，就放弃 这些功能。 当时间成为主要约束时，该模型能够比 其他模型能够更完整的实现功能。 该方法的缺点是失去了很多对产品的控 制能力。
商品软件
商品软件也许未必满足你的所有要求。 但自己开发也需要一个周期，到那时候， 商品软件可能已经满足了你的要求。 商品软件可能存在不足，但是，你自己 开发的产品也未必那么完美，当你补充 了商品软件的不足时，也许带了新的问 题。 因而，商品软件始终是一个值得考虑的 方案。
练习：案例研究
某教育部门希望目前的中小学有一个现代化的 信息交流平台，即校务管理系统。为此，他们 提出了需求，希望软件公司能够开发这种软件。 该软件是对学校校务和教学活动进行综合管理 的平台系统。是一个学校和地区教育信息化的 基础信息平台。它要完成学校管理层、教师、 学生、家长等日常工作、学习、管理、咨询等 任务。
增量式交付的优点

项目结束交付全部成果前，分阶段将有用的 功能交付给用户。
主要缺点：如果管理层和技术层面上缺 乏仔细的规划，工作就无法进行。 使用增量式交付的要点：

确保每个阶段的交付对用户是有用的。 确保考虑了不同组成部分的技术依赖关系。
面向进度的设计
类似于增量式交付，但是面向进度的设计生命 周期模型在开始的时候不必知道究竟能达到何 种目标，但是要确保最后期限。 该模型的关键是要按优先级别划分系统特征并 规划开发阶段，保证前面的阶段具有高优先级 的特性，低特性具有低优先级。 是否采用这种方法取决于你是否对系统目标具 有足够的信心。如果有信心，则可以采用增量 式交付。
Spiral Model适合的项目
风险是主要的制约因素 不确定因素和风险限制了项目进度 用户对自己的需求也不是很明确 需要对一些基本的概念进行验证 可能发生一些重大的变更 项目规模很大 项目中采用了新技术
优点：随着迭代的增加，风险程度随之 降低 缺点：比较复杂，需要责任心、专注和 管理方面的知识。
校务通系统的全部功能分为通用功能和日常业务管理 功能两大类。

因此，可以先基于通用功能做出一个最小的使用版本。再逐 步添加其它功能。这样一来，用户可以在先试用最小版本的 同时，提出更多明确的需求，这有助于下一阶段的开发，大 大减少了开发的风险。
用户明确了需求的大部分，但也存在不很详细的地方。 如“关于教师档案，比照所提供的资料设计，现在也 没有一个成型的东西。”资源库系统只提到“应提供 一个标准的资源库系统解决方案”。
原型法
原型是项目系统中一个方面或多个方面 的工作模型


抛弃型原型：用于试验某些概念，实验完系 统将无用处。 进化型原型：原型系统不断地被开发和修正， 最终他将变为一个真正的系统。
原型法
原型的好处




从实践中学习(Learning by doing) 改善的通信 改善的用户参与 使部分已知的需求清晰化 展示描述的一致性和完整性 特征约束（利用工具构造原型可以将某些特性落实 到实处，而非在纸上谈兵那样容易失误） 试验是否能产生预期的结果
有效的软件过程也可以改善软件组织对软件的 维护能力

有效地定义如何管理需求变更，在未来的版本中恰 当分配变更部分，使之平滑过渡； 首先在具体操作和相关支持中定义如何平滑地改造 软件，并且这种具体操作和支持是可实施的；不可 实施的软件过程将很快被束之高阁；
编码修正模型
Code and Fix Code like Hell（鲁莽编码） 从一个大致的想法开始工作，然后经过 非正规的设计、编码、调试和测试方法， 最后完成工作。