1 / 28

Software Project Management 5 th Edition

第 4 章. Software Project Management 5 th Edition. 选择合适的项目方法. 项目方法的选择. 内部开发 : 大多数的问题由 IS 的计划和标准解决 软件公司 : 不同客户有不同的需要 方法选择受影响 : 项目的不确定性 待建应用（软件系统）的性质. 一般方法. 看风险和不确定性，例如 需求理解了吗 ? 技术理解了吗 ? 看待建应用的类型，例如 信息系统 ? 嵌入式系统 ? 重点 ? 目标环境和开发环境之间的差异 ? 客户的需求 需要用特别的方法. 过程模型的选择.

crwys
Download Presentation

Software Project Management 5 th Edition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 第 4章 Software Project Management5th Edition 选择合适的项目方法

  2. 项目方法的选择 • 内部开发: 大多数的问题由IS的计划和标准解决 • 软件公司: 不同客户有不同的需要 • 方法选择受影响: • 项目的不确定性 • 待建应用（软件系统）的性质

  3. 一般方法 • 看风险和不确定性，例如 • 需求理解了吗? • 技术理解了吗? • 看待建应用的类型，例如 • 信息系统? 嵌入式系统? • 重点? 目标环境和开发环境之间的差异? • 客户的需求 • 需要用特别的方法

  4. 过程模型的选择 • ‘瀑布’ ， ‘一枪’, ‘一次过’ • 增量式交付 • 演化开发 • 敏捷，例如极限编程。

  5. 瀑布 The waterfall model

  6. 瀑布式 • 经典模型 • 给项目以结构 • 每个阶段需要验收和结束活动 • 重复少

  7. V-过程模型 瀑布的另一个视角

  8. 演化式交付 ‘ 快速创建的迭代过程，测试需求和假设的低价可用模型 什么将被演化？ • 人-机接口 • 功能

  9. 原型式理由 • 做中学 • 通讯的改善 • 用户参加况的改善 • 反馈意见循环的建立 • 减少文档的需求 • 减少维护费用，例如在应用进入使用后的改变费用 • 原型能够用于产生期望的结果

  10. 原型式: 风险 • 用户可能误解原型的作用 • 缺乏控制和可能的标准 • 建造原型的附加费用 • 注重用户接口可能付出机器效率的代价

  11. 其他的原型分类 • what is being learnt? • organizational prototype • hardware/software prototype (‘experimental’) • application prototype (‘exploratory’) • to what extent • mock-ups • simulated interaction • partial working models: vertical versus horizontal

  12. design design design build build build install install install evaluate evaluate evaluate 增量式交付 delivered system increment 1 first incremental delivery increment 2 second incremental delivery increment 3 thirdincremental delivery

  13. The incremental process Intentional incremental delivery

  14. Incremental approach:benefits • feedback from early stages used in developing latter stages • shorter development thresholds • user gets some benefits earlier • project may be put aside temporarily • reduces ‘gold-plating’: BUT there are some possible disadvantages • loss of economy of scale • ‘software breakage’

  15. The outline incremental plan • steps ideally 1% to 5% of the total project • non-computer steps should be included • ideal if a step takes one month or less: • not more than three months • each step should deliver some benefit to the user • some steps will be physically dependent on others

  16. Which step first? • some steps will be pre-requisite because of physical dependencies • others may be in any order • value to cost ratios may be used • V/C where • V is a score 1-10 representing value to customer • C is a score 0-10 representing value to developers

  17. V/C ratios: an example

  18. ‘敏捷’ 方法 structured development methods have some perceived advantages • produce large amounts of documentation which can be largely unread • documentation has to be kept up to date • division into specialist groups and need to follow procedures stifles communication • users can be excluded from decision process • long lead times to deliver anything etc. etc The answer? ‘Agile’ methods?

  19. 动态系统开发方法 • UK-based consortium • arguably DSDM（动态系统开发方法） can be seen as replacement for SSADM（结构系统分析和设计方法） • DSDM is more a project management approach than a development approach • Can still use DFDs, LDSs etc!

  20. DSDM九个核心原理 1. Active user involvement 2. Teams empowered to make decisions 3. Frequent delivery of products 4. Fitness for business purpose 5.Iterative and incremental delivery 6. Changes are reversible 7. Requirements base-lined at a high level 8. Testing integrated with development 9. Collaborative and co-operative approach

  21. DSDM framework Figure 4.6 here DSDM process model

  22. DSDM: time-boxing • time-box fixed deadline by which something has to be delivered • typically two to six weeks • MOSCOW priorities • Must have - essential • Should have - very important, but system could operate without • Could have • Want - but probably won’t get!

  23. 极限编程 • increments of one to three weeks • customer can suggest improvement at any point • argued that distinction between design and building of software are artificial • code to be developed to meet current needs only • frequent re-factoring to keep code structured

  24. Extreme programming - contd • developers work in pairs • test cases and expected results devised before software design • after testing of increment, test cases added to a consolidated set of test cases

  25. Grady Booch’s concern Booch, an OO authority, is concerned that with requirements driven projects: ‘Conceptual integrity sometimes suffers because this is little motivation to deal with scalability, extensibility, portability, or reusability beyond what any vague requirement might imply’ Tendency towards a large number of discrete functions with little common infrastructure?

  26. Macro and micro processes A macro process containing three iterative micro processes

  27. IF complexity is high but uncertainty is not • THEN use incremental approach ‘rules of thumb’ about approach to be used IF uncertainty is high THEN use evolutionary approach • IF uncertainty and complexity both low • THEN use one-shot • IF schedule is tight • THEN use evolutionary or incremental

  28. Combinations of approach installation one-shot incremental evolutionary one-shot yes yes no construction incremental yes yes no evolutionary yes yes yes one-shot or incremental installation - any construction approach possible evolutionary installation implies evolutionary construction

More Related