软件项目管理.软件管理的复兴

这本书好早就有了，但是没有看过；现在看了才知道为什么大家这么推崇
俺不是做管理的，本书只是粗略一读，顺便列出目录

软件项目管理
软件管理的复兴
    传统的软件管理
        实践
            拖延的集成与后期的设计变更范围
            后期的风险解决方案
            需求驱动的功能分解
            项目相关人员之间的敌对关系
            致力于文档和评审会
        传统软件管理的性能
            在交付之后找到并修复一个软件问题的成本，超过了在设计的前期阶段找到并修复该问题的成本的100倍
            你可以将软件开发进度压缩25％，但是不能再多了
            你在开发中每花掉1美元，就得在维护中花费2美元
            软件开发和维护成本主要是源代码行数的函数
            人与人的不同导致了软件生产率的最大差异
            总体上软件和硬件成本比仍然在上升
            只有15％的软件开发工作是专用于编码的
            软件系统和产品每行代码的成本通常是个人软件的3倍。软件系统产品的成本通常是个人软件程序的9倍
            走查发现了60％的错误
            20％的贡献者作出了80％的贡献
    软件经济学的进化
        软件成本模型
            规模
            过程
            人员
            环境
            所要求质量
        开发者与软件成本估计模型和工具提供商间
            使用哪一个成本估计模型
            是用源代码行还是功能点来度量软件的规模
            是什么形成了一个好的估计
    改进软件经济学
        缩小软件产品的规模
        改进软件过程
        改进群组的有效性
        借助软件环境改进自动化
        达到要求的质量
    旧方法和新方法
        传统软件工程原理
            把质量放在第一位
            高质量的软件是可能的
            尽早向客户交付产品
            在编写需求之前确定问题
            评价设计可选方案
            使用合适的过程模型
            在不同的阶段使用不同的语言
            尽可能缩小理解差距
            技术比工具重要
            在想快之前先保证正确
            评审代码
            好的管理比好的技术更重要
            人员是成功的关键
            谨慎地跟随潮流
            负责任
            理解客户需求的优先级
            他们看得越多，就想要得到越多
            计划丢弃
            为变更作设计
            没有文档的设计不是设计
            使用工具
            避免玩弄小技巧
            封装
            使用耦合与内聚
            使用McCabe复杂度度量标准
            不要测试自己开发的软件
            分析错误原因
            意识到软件熵的增长
            人员和时间是不可以互换的
            期待优秀的表现
        现代软件管理原理
            将过程建立在构架优先方法的基础上
            建立一个能尽早面对风险的迭代式生命周期过程
            设计方法向强调基于构件的开发转变
            建立一个变更管理环境
            通过支持双向工程的工具增强变更的自由度
            用严格的、基于模型的符号标记设计制品
            为过程配备工具进行客观的质量控制以及进度评估
            使用基于演示的方法评估中间制品
            计划在大量的使用场景中使用细节的进化等级进行中间发布
            建立一个经济上具有伸缩性的可配置的过程