软件经济学.pptVIP

瀑布式和迭代式的项目风险曲线 图5-2 先架构后生产 瀑布式和迭代式的资源消耗比例 表5-1 资源消耗情况 软件管理的80/20法则 20%的需求消耗了80%的工程工作 20%的组件消耗了80%的软件成本 20%的组件导致了80%的错误 20%的变更导致了80%的软件废品和返工 20%的组件消耗了80%的资源（执行时间、磁盘空间、内存） 20%的人完成了80%的工作 提高团队效率 提高软件经济性的至高需要：用更少的人做更多的事 对称职人员的需求总是大于合格人员的供应 成功的项目和软件组织：配置了一个规模最小但最有能力的团队 肥胖症——项目配备的人员超过了需要 原因：项目的文化更多关注于遵守过程或者按照一组严格的角色划分来使技能过度专业化，而不是关注于获得结果。 提高团队效率方法 微妙但根本的区别： 成功：结果驱动而可以放松角色的正规度和过程的严格性 不成功：过程与角色驱动 增强个人绩效 提高员工能力：培训、团队构成、经验 优秀团队的特征：均衡与全面 均衡：领导者追随者；空想家实干家；乐观主义者悲观主义者；保守者冒险者 全面：技巧、工具和技能互补 提高团队效率方法 改进项目的团队协作：团队管理格言 管理得当的项目即便使用工程技能一般的人员也能取得成功。 管理不当的项目即便使用由专家组成的工程团队也不能取得成功。 由技能一般的软件开发人员组成的团队能够完成一个架构很好的系统的开发工作。 即使团队成员都是专家级的开发人员，想要完成一个架构很差的系统也只能是一番苦苦挣扎。 提高团队效率方法 推进组织级能力 随机级（60%）：组织还不成熟，每个新项目都会使用专用的过程、方法和工具。 可重复级（30%）：组织较为成熟，它们使用的一些基本能力大致可追溯到业界的一些最佳实践上。他们能够获得可重复级的性能，并且在过程、方法、培训和工具方面获得一些相对稳定的投资回报。 改进级（10%）：业界中更优秀的软件组织在一条共同业务线上实现了整个组织范围内的公共的过程框架、方法、培训和工具。跨项目地使用一致客观的度量可以使投资回报逐项目递增。这就是ISO9000或者SEWE CMM 过程改进运动的基本目标，不过此类运动大多数采取的是关注过程和关注活动的视角，而不是关注项目结果的视角。 市场领先级：这些组织拥有出色的组织级能力，当他们在一个公共框架下执行多个项目时，能够连续获得较好的性能。他们可以从多个性能维度来优化业务性能（权衡质量、面市时间和成本），并且实行量化的过程管理。 通过集成工具来提高自动化 开发环境及工具： 需求管理的工具、可视化建模的工具、文档自动化工具、宿主/目标编程工具、自动化回归测试、集成的变更管理、构建自动化和特性/缺陷跟踪工具等。 自制的业务定制与维护工具 ？ 成功组织的特征 图8-1 在四个维度同时追求改进的组织的目标曲线 现代软件开发文化 低中级管理者是关键的执行者。 需求、设计和计划要可变并且具体。 要鼓励进行雄心勃勃的演示。 项目性能的好坏在生命周期的早期更明显。 早期的迭代式应该是不完全的。 详细完整的工作在早期不太重要，在后期比较重要。 真正的问题（重要而非表面的问题）会系统化的出现，也应系统化地加以解决。 质量保证是每个人的职责，不是一个单独的行当。 应该把对于自动化的投资看作是必要的。 软件工程实用度量（量化） 软件开发组织关注的目标 缩短交付解决方案所要花的时间（面市时间），要求保持最低程度的功能和指定的质量水平及成本。 降低成本，要求保持最低程度的功能和指定的质量水平，通常有面市时间的约束。 改进质量，要求保持最低程度的功能、成本和面市时间。 软件开发组织关注的目标 管理的本质是以一种可以接受的方式来管理目标（成本、时间、质量和范围）之间的权衡，并达到利益相关者的期望要求。 目标是一种预测，但预测是件很困难的事，尤其是关于未来的预测。 现实是变化的，因此需要目标容忍度，在一个偏差范围内是可以接受的 软件开发组织关注的目标 度量偏差与项目进度的关系： 图9-2 迭代式的开发方式使误差随着项目的进展逐步降低 量化工作何时会出错 最糟糕的实践，但非常普遍 预先执行详细计划，然后对计划进行度量 表现形式 1）在项目启动时，作为最早的行为之一，项目经理制定了一个项目计划。根据有关所解决问题的一些概略信息和含糊的目标，项目经理尽自己所能来”猜”出进度和成本可能是什么样的。 2）无论我们多少次提醒说“计划在本质上是暂定的”，而计划的“命运”却从未因此而改变过。早期的计划实际上只是一些思考实验—它们只是在它们所基于的那些假设下才成立。计划变成了对于“成功将会是什么样”的一种预测。而管理层监督的重点则从计划转移到了度量偏差，而不是引领项目向着成功的结果前进。计划变成了项目经理脖子