项目方法的选择ppt课件.ppt

第四讲 项目方法的选择 1 内容 技术选择考虑风险方法选择 2 技术选择 技术选择将影响 开发人员的训练需要人员招聘开发环境 软硬件系统维护安排步骤分析项目是目标驱动还是产品驱动分析项目的其它特征面向数据还是面向控制通用还是专用是否涉及需要专用工具支持的专门技术 并发处理 专家系统 GIS 是否有特殊的安全性 safe 要求对软硬件有何要求 PCVs 大型机 3 识别项目中的高风险 产品不确定性 系统需求理解的准确性 用户在开始时有可能对系统应该什么样都无法确定 在某些环境中 精确而有效的需求描述可能迅速变得过时 过程不确定性 在项目开始时需要选择方法或过程模型 或者一些新的工具 任何对原先采用的开发方法的变更都将引入不确定性 资源不确定性 项目进行中资源的数量可能发生变化 例如公司待遇 其它项目的影响 4 方法选择 考虑用户关于实现的需求用户可能在合同中限定了有关实现方面的方法 例如 规定了企业必须具有相应的CMM等级 或者通过了ISO9000方法 选择通用的生命期方法控制系统 一般为实时系统 比如需要Petri网技术 5 Toooften softwareworkfollowsthefirstlawofbicycling Nomatterwhereyou regoing it suphillandagainstthewind 6 过程模型的选择 软件过程是将用户的需求转化成有效的软件解决方案的一系列活动 开发一个软件需要选择开发策略 包括过程 方法和工具 以及通用阶段 这些策略和阶段称为过程模型 过程模型的选择基于项目和应用的特性 使用的工具和方法 所需要的控制方法和交付物 7 软件过程的概念 软件过程由相关项目的阶段 状态 方法 技术和开发 维护软件的人员以及相关对象 计划 文档 模型 编码 测试 手册等 组成 一个过程定义了为达到某个确定的目标 需要什么人 在什么时间以何种方式做何种工作 软件需要一个可用于指导顾客 用户 开发人员和项目经理等参与者的过程 8 软件开发过程 软件工程的核心是过程 产品 人员 技术通过过程关联起来 软件开发过程能够将技术集成在一起从而使软件的开发能够以一种合理而及时的方式完成 许多软件组织无法正确定义和控制这一过程 但这恰恰是组织改进的关键 9 有效的软件过程 有效的软件过程可以提高组织的生产能力保证软件开发基本原则的实现 辅助软件项目管理者做出明智的决定 使软件开发活动标准化 提高软件的可重用性和Team间的协作 有效的软件过程也可以改善软件组织对软件的维护能力有效地定义如何管理需求变更 在未来的版本中恰当分配变更部分 使之平滑过渡 首先在具体操作和相关支持中定义如何平滑地改造软件 并且这种具体操作和支持是可实施的 不可实施的软件过程将很快被束之高阁 10 编码修正模型 CodeandFixCodelikeHell 鲁莽编码 从一个大致的想法开始工作 然后经过非正规的设计 编码 调试和测试方法 最后完成工作 可能有 可能没有规范 11 chapter 3 12 Codeandfix 需求了解 编码 编译 检错 修正 编写文档 提交 修正 测试 12 好处 成本可能很低只需要很少的专业知识 任何写过程序的人都可以对一些非常小 开发完后就会很快丢弃的软件可以采用对于规模稍大的项目 采用这种模型是很危险的 13 瀑布模型 最早 被广泛使用的过程模型 14 瀑布模型适用于什么场合 有何优缺点 15 瀑布模型特点 特点 阶段顺序执行严格的质量保证推迟实现 16 瀑布模型适用条件 当有一个稳定的产品定义和很容易被理解的技术解决方案时 纯瀑布模型特别合适 当一个定义很好的版本进行维护或将一个产品移植到一个新的平台对于容易理解但很复杂的项目 采用纯瀑布模型比较合适 因为可以用顺序的方法处理当开发队伍技术力量比较弱或者缺乏经验时 瀑布模型更为合适类似的项目如 公司的财务系统库存管理系统 17 问题 缺乏灵活性 必须在项目开始前说明全部需求 但这恰恰是非常困难的 18 chapter 3 19 V型模型 评审 集成测试 用户验收 项目规化 需求分析 总体设计 详细设计 编码和调试 系统测试 单元测试 19 V型模型 该方法是对瀑布模型的变种 强调了验证活动 扩展了瀑布模型的测试活动理想的情况下 改正活动只应该返回对应层次的下层 可行性 可行性可能在系统实现前几个月或者几年前执行 20 项目的需求在项目开始前很明确解决方案在项目开始前也很明确对系统的性能安全很严格的项目类似的项目如 航天飞机等公司的财务系统 21 瀑布模型变种 生鱼片模型 把阶段重叠起来的瀑布模型起源于日本硬件开发模型 富士通 施乐 22 传统的瀑布模型强调阶段之间最小的重叠 而生鱼片模型强调大幅度的重叠 即在需求分析完成之前就可以进行架构设计和部分详细设计 纯瀑布模型强调在任意两个阶段交接时 文档从一个团队交给另一个完全隔离的团队 但是如果一个团队完成各个阶段任务是 可以没有那么多的文档 优点 加快进度 问题 缺点是什么 因为阶段重叠 因而里程碑不明确 很难有效的进行过程跟踪和控制 23 螺旋模型 以风险为导向的生命期模型从一个小范围的关键中心地带开始寻找风险因素 制定风险控制计划 并交付给下一个步骤 如次迭代 每次迭代将项目扩展到一个更大的规模 24 25 SpiralModel 螺旋模型沿着螺线旋转 在四个象限上分别表达了四个方面的活动 即 制定计划 确定软件目标 需求和选定实施方案 弄清项目开发的限制条件风险分析 评估所选方案 考虑如何识别和消除风险实施工程 实施软件开发 编码 测试等客户评估 评价开发工作 提出修正建议 规划下期任务 26 SpiralModel适合的项目 风险是主要的制约因素不确定因素和风险限制了项目进度用户对自己的需求也不是很明确需要对一些基本的概念进行验证可能发生一些重大的变更项目规模很大项目中采用了新技术 27 优点 随着迭代的增加 风险程度随之降低缺点 比较复杂 需要责任心 专注和管理方面的知识 28 原型法 原型是项目系统中一个方面或多个方面的工作模型抛弃型原型 用于试验某些概念 实验完系统将无用处 进化型原型 原型系统不断地被开发和修正 最终他将变为一个真正的系统 29 原型法 原型的好处从实践中学习 Learningbydoing 改善的通信改善的用户参与使部分已知的需求清晰化展示描述的一致性和完整性特征约束 利用工具构造原型可以将某些特性落实到实处 而非在纸上谈兵那样容易失误 试验是否能产生预期的结果 30 原型模型适合的项目 项目的需求在项目开始前不明确需要减少项目需求的不确定性类似的项目如 确定显示界面第一次开发的产品 验证可行性 31 原型法 原型法的缺点用户有时误解了原型的角色 例如 他们可能误解原型应该和真实系统一样可靠缺少项目标准 进化原型法有点像编码修正 codeandfix 缺少控制 由于用户可能不断提出新要求 因而原型迭代的周期很难控制额外的花费 有统计表明 构造原型可能有10 的额外花费运行效率可能会受影响原型法要求开发者与用户密切接触 有时这是不可能的 如软件外包 32 增量式交付 增量式交付 持续地在确定的阶段向用户展示软件 与渐进原型不同 在增量式交付的时候 你明确地知道下一步要完成什么工作 增量式交付的特点是不会在项目结束的时候一下交付出全部软件 而是在项目的整个开发过程中持续不断的交付阶段性成果 33 增量式交付 34 增量式交付模型的特点 阶段式提交一个可运行的产品关键的功能更早出现早期预警问题 避免软件缺陷不知不觉的增长减少报告负担阶段性完成可以降低估计失误阶段性完成均衡了弹性与效率 35 增量式交付的优点项目结束交付全部成果前 分阶段将有用的功能交付给用户 主要缺点 如果管理层和技术层面上缺乏仔细的规划 工作就无法进行 使用增量式交付的要点 确保每个阶段的交付对用户是有用的 确保考虑了不同组成部分的技术依赖关系 36 面向进度的设计 类似于增量式交付 但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何种目标 但是要确保最后期限 该模型的关键是要按优先级别划分系统特征并规划开发阶段 保证前面的阶段具有高优先级的特性 低特性具有低优先级 是否采用这种方法取决于你是否对系统目标具有足够的信心 如果有信心 则可以采用增量式交付 37 渐进交付 渐进交付是一种跨越了渐进 进化 原型和增量式交付两种模型的过程模型 基本过程 开发一个产品的版本 展示给客户 根据反馈改善产品 如果计划满足用户的绝大多数需求 渐进交付与渐进原型差不多 如果计划满足少量的需求 渐进交付与增量式交付差不多 渐进原型强调的是系统看得见的样子 再回来堵漏洞 渐进交付中 最初的重点是系统核心和底层系统功能 38 39 面向开发工具的设计 只有现有软件工具直接支持的情况下增强产品的功能 如果他不支持 就放弃这些功能 当时间成为主要约束时 该模型能够比其他模型能够更完整的实现功能 该方法的缺点是失去了很多对产品的控制能力 40 商品软件 商品软件也许未必满足你的所有要求 但自己开发也需要一个周期 到那时候 商品软件可能已经满足了你的要求 商品软件可能存在不足 但是 你自己开发的产品也未必那么完美 当你补充了商品软件的不足时 也许带了新的问题 因而 商品软件始终是一个值得考虑的方案 41 练习 案例研究 某教育部门希望目前的中小学有一个现代化的信息交流平台 即校务管理系统 为此 他们提出了需求 希望软件公司能够开发这种软件 该软件是对学校校务和教学活动进行综合管理的平台系统 是一个学校和地区教育信息化的基础信息平台 它要完成学校管理层 教师 学生 家长等日常工作 学习 管理 咨询等任务 42 校务通系统的全部功能分为通用功能和日常业务管理功能两大类 因此 可以先基于通用功能做出一个最小的使用版本 再逐步添加其它功能 这样一来 用户可以在先试用最小版本的同时 提出更多明确的需求 这有助于下一阶段的开发 大大减少了开发的风险 用户明确了需求的大部分 但也存在不很详细的地方 如 关于教师档案 比照所提供的资料设计 现在也没有一个成型的东西 资源库系统只提到 应提供一个标准的资源库系统解决方案 这样 只有等到一个可用的产品出来 通过客户使用这个可用产品 然后进行评估 评估的结果作为下个增量的开发计划 下一个增量发布一些新增的功能和特性 直至产生最终的完善产品 43 在校务通系统需求中 要求系统有可扩充性 若使用增量式模型 可以保证系统的可扩充性 系统要求有可扩充性 可以在现有系统的基础上 通过前台就可以加挂其他功能模块 说明用户会增加新的需求 对一个管理方式已经比较成熟的学校 要完全舍弃原有的管理方式 用校务通系统替换全部管理 这是不实际的 所以 可以从最基础的做起 逐步的扩充其功能 44 项目计划 集成测试 产品移交 增量1 总体设计 需求分析 增量2 增量6 增量5 增量4 增量3 45 项目规划阶段阶段目标 根据合同和初步需求分析 确定项目的规模 时间计划和资源的需求输入 合同文本过程 项目规划 计划确认输出 项目计划需求分析阶段阶段目标 确定用户需求输入 项目计划过程 需求获取 需求分析 需求控制输出 需求规格 原型系统项目规划阶段阶段目标 总体系统结构设计输入 需求规格 原型系统过程 总体设计输出 系统设计说明书 数据库结构定义 46 增量1实现阶段目标 实现系统的通用功能输入 系统设计说明书 数据库结构定义过程 详细设计 编码 代码走查 代码评审 单元测试输出 详细设计说明书 源代码 可运行版本 1增量2实现阶段目标 实现系统的招生功能输入 系统设计说明书 数据库结构定义过程 详细设计 编码 代码走查 代码评审 单元测试输出 详细设计说明书 源代码 可运行版本 2 47 增量3实现阶段目标 实现系统的学生日常功能输入 系统设计说明书 数据库结构定义过程 详细设计 编码 代码走查 代码评审 单元测试输出 详细设计说明书 源代码 可运行版本 3增量4实现阶段目标 实现系统的教务管理功能输入 系统设计说明书 数据库结构定义过程 详细设计 编码 代码走查 代码评审 单元测试输出 详细设计说明书 源代码 可运行版本 4增量5实现阶段目标 实现系统的教师辅助功能输入 系统设计说明书 数据库结构定义过程 详细设计 编码