- 1、本文档共56页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
软件工程导论(4) 软件工程思想 思想? 本章内容 4.1 永远不可低估思想的作用 4.2 以人为本 4.3 软件开发不是一门艺术 4.4 向传统工业学习 4.5 软件工程的例外 4.6 软件工厂思想 本章内容 4.1 永远不可低估思想的作用 4.2 以人为本 4.3 软件开发不是一门艺术 4.4 向传统工业学习 4.5 软件工程的例外 4.6 软件工厂思想 永远不可低估思想的作用 软件工程思想决定了软件工程的策略和方法 本章内容 4.1 永远不可低估思想的作用 4.2 以人为本 4.3 软件开发不是一门艺术 4.4 向传统工业学习 4.5 软件工程的例外 4.6 软件工厂思想 以人为本 管理学的佐证 由智力活动所决定 软件工程是知识工程 本章内容 4.1 永远不可低估思想的作用 4.2 以人为本 4.3 软件开发不是一门艺术 4.4 向传统工业学习 4.5 软件工程的例外 4.6 软件工厂思想 软件危机 软件是高科技的智力产品,需要很高的创造性,但还是不能抹去其工业性 软件质量问题直接危害到人们的生命财产、会造成国家经济的严重损失,企业会为此付出很大的代价 艺术可以定义为“人类以创造美为主要目的的技术及其产品” 本章内容 4.1 永远不可低估思想的作用 4.2 以人为本 4.3 软件开发不是一门艺术 4.4 向传统工业学习 4.5 软件工程的例外 4.6 软件工厂思想 向传统产业学习什么? 4.4 向传统工业学习 客户为导向 满足客户的期望 超越客户的期望 一切从客户出发 体现在具体过程中 让客户参与到公司的质量管理中 质量=客户满意度 需求分析是基础 以客户为导向,最直接体现在客户需求工作之上 对需求不重视,导致软件开发的返工率很高、成本高、质量低等一系列问题 一个惊人的数字 如果在项目执行的最后再来修正错误,那么可能比在项目的需求阶段就修正错误,多付出多少的代价? 一个惊人的数字 在项目的最后阶段修正需求错误比在需求阶段修正它要多花费200倍的代价 过程决定结果 有什么流程,就有什么结果,流程决定了结果 产品是构建于过程之中 自动化生产线就是一个很好的例子 过程活动决定了成本 持续改进过程 PDCA IDEAL DMAIC QIP PDCA IDEAL DMAIC QIP 缺陷预防 软件的劣质成本占开发的总成本在40%以上 如果第一次就把事情做对了,就消除了劣质成本 相比软件测试/质量检验,更有效的方法是开展预防缺陷的活动 在开发的每个阶段实施根本原因分析, 为有效开展缺陷预防活动提供依据 围绕项目开展工作 项目管理已经很成熟,形成比较完整的体系 不管大大小小的事情,都可以看作一个项目 把一个个项目做好了,就把整个工程做好了 围绕项目开展各项工作 验证和确认缺一不可 验证过程: Are we building the product right? 是否正确地构造了软件?即是否正确地做事,验证开发过程是否遵守已定义好的过程规范。 确认过程: Are we building the right product? 是否构造了正确的软件?即是否正在做用户真正所需要的产品 以架构设计为中心 软件架构设计决定了软件系统的性能、可靠性、扩充性和维护性等 良好的架构设计能适应用户不同的需求、支持用户需求的改变 RUP也提倡“以架构设计为中心”的理念 本章内容 4.1 永远不可低估思想的作用 4.2 以人为本 4.3 软件开发不是一门艺术 4.4 向传统工业学习 4.5 软件工程的例外 4.6 软件工厂思想 软件工程有什么不同? 4.5 软件工程的例外 4.5.1 迭代 4.5.2 敏捷开发思想 4.5.3 持续构建和集成 4.5.4 永远的Beta 4.5.5 面向对象是一种思想 4.5.6 软件工程应归为知识管理 为什么选择迭代? 市场的压力和竞争策略的需要 产品开发的资金、周期和资源是有限的 软件的复杂程度不断提高,增加了项目失败的可能性,将一个产品进行分阶段处理,可以尽早发现产品的市场问题或方向错误,降低风险。 对于越来越复杂、庞大的系统,多数情况下不容易一次性整体实现,而是通过分解逐步实现。 软件比较容易修改或扩充,在技术上可以保证软件迭代的可行性。 迭代 迭代开发流程 XP-eXtreme Programming极限编程 最简单的可能就是最有效的 极限编程适合 小团队 (2-10 programmers) “高风险” 快速变化或不稳定的需求 强调可测试性 格言 “沟通、简化、反馈、激励” TDD - Test-Driven Development测试驱动
文档评论(0)