软件工程 02 软件过程模型讲解.ppt

  1. 1、本文档共91页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
* CMU,SEI,1987 除了各阶段评审反馈,还可从使用与维护反馈用户意见 * * * JAD是应用程序开发联系会议。JAD程序包括加强用户参与的途径,促进系统开发,提高产品规格的质量。 * * * 知识社会化的内涵及维度。Nonaka 等从知识转换模式视角提出了知识的社会化概念,即知识的社会化又叫共同化,它是隐性知识的转化,即将隐性知识如经验、价值、行为模式,经由隐性学习与同化的过程,由某一群组转移至另一群组( 个人、团体、或组织) 而产生新知识的过程,也即人们透过观察、模仿、学习型对话,直接向他人学习隐性知识的过程。 * * 渗透交流就是信息流向团队成员的背景听觉,使得成员就像通过渗透一样获取相关信息。这种交流通常都是通过团队成员在同一间工作室内工作而实现的。若其中一名成员提出问题,工作室内的其他成员可以选择关注或不关注的态度,可以加入到这个问题的讨论当中来,也可以继续忙自己的工作。 个人安全指的是当您指出困扰您的问题时,您不用担心受到报复。个人安全非常重要,有了它,团队可以发现和改正自身的缺点。没有它,团队成员们知而不言,缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任,团队协作才能真正的实施,开发效率也就会直线上升的。 * * * * * * 两类极端:很多老板只重结果;我们老师看重过程,举例平时考试,半期,期末,项目等。 Scrum 每24小时 Scrum:15分钟日例会团队成员基本问题 1、上次例会后做了什么? 2、遇到什么困难? 3、下次例会前做些什么? 冲刺结束时展示的新功能 产品待定项分优先级的客户急需产品特征 Scrum过程流(使用许可) 冲刺待定项分配给冲刺的特征 团队展开的具体项目 30天 Crystal-透明水晶方法 Crystal——区分特征 经常交付、持续测试集成 焦点, 确定首先要做什么,然后安排时间,以平和的心态开展工作。确保团队成员清楚的了解他们自己最重要的任务是什么,确保他们能够有充分的时间去完成这些任务。 配有自动测试、配置管理和经常集成功能的技术环境 渗透交流、个人安全 与专家用户建立方便的联系 建议使用“反思研讨会”审查团队的工作习惯 适合于一个小团队来进行敏捷开发,人数在6人以下为宜 特征驱动开发FDD (Feature Driven Development) FDD——区分特征 强调特征定义 特征“是可以在2周或更短时间实现的具有客户价值的功能” 使用特征模版 action the result by | for | of | to a(n) object 创建一个特征列表并实施“特征计划” 在FDD中合并设计和构建 基本原理: 重点强调团队合作 使用特征分解随后集成的方法解决管理和复杂性 使用口头、图解以及文本的方法交流技术细节 使用阶段审查、收集度量、使用模板等方法保证质量 特征驱动开发FDD 开发全局模型 更多外观而非内容 构造特征列表 特征计划 特征设计 特征构建 设计包(序列) 具有客户价值的完整功能 开发计划类属性 特征集属性 按照主题 领域划分 增加更多内容到对象模型 一个对象模型说明 敏捷建模AM (Agile Modeling) 提出一系列敏捷建模原则 有目的的模型:开发者有明确的目标 使用多个模型:描述软件可以采用多种模型或表示法 轻装上阵:随着工作进展,只保留有长期价值的模型,其余抛弃 内容重于表现形式:提供有用内容的模型更为重要 理解模型及构件工具 适应本地需要:建模方法应该适应敏捷团队的需要 如何选择过程模型? 软件开发模型是不断发展的 各种软件开发模型各有优缺点 选用时不必拘泥与某种模型 可组合多种模型 也可根据实际创建新的模型 参考原则 1. 在前期需求明确的情况下,尽量采用瀑布模型或改进的瀑布模型。 2. 在用户无系统使用经验,需求分析人员技能不足情况下一定要借助原型。 3. 在不确定因素很多,很多东西前面无法计划的情况下尽量采用增量迭代和螺旋模型。 4. 在需求不稳定的情况下尽量采用增量迭代模型。 5. 在资金和成本无法一次到位的情况下可采用增量模型,软件产品多个版本进行发布。 6. 对于完成多个独立功能开发可以在需求分析阶段就进行功能并行,但每个功能内部都应该遵循瀑布模型。 7. 对于全新系统的开发必须在总体设计完成后再开始增量或并行。 8. 对于编码人员经验较少的情况下建议不要采用敏捷或迭代等生命周期模型。 9. 增量、迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口原则。 10.UP适用于面向对象项目。 11.敏捷开发适合高开发效率和响应能力需求的项目。 以产品为中心 过程 B 产品 过程 C 过程 A 需求 Focus 产品 产品 过程和产品 过程很薄弱,最终产品必将受到影响 过分依赖

文档评论(0)

shuwkb + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档