4.2 需求管理
需求 最终文档 经过评审批准后，则定义了需求基线 Baseline；构筑了 功能需求 和 非功能需求 的一个 约定Agreement。约定是需求开发和需求管理之间的桥梁。
需求管理是一个 对系统 需求变更、了解和控制 的过程，初始需求导出的同时 就启动了需求管理规划。
4.2.1 需求管理原则
过程能力成熟度模型 CMM，指导软件过程改进，5个成熟级别，6个关键过程域KPA。
一旦需求 文档化了，开发组和有关团队 需要评审文档。发现问题应与客户或者其他需求源协商解决。软件开发计划是基于 已确认的需求。
绝不要承诺 任何 无法实现的事。
关键处理领域 通过版本控制和变更控制 来管理需求文档。确保与新的需求保持一致。
4.2.2 需求规格说明的版本控制
版本控制是管理需求的一个必要方面，必须统一确定需求文档的每一个版本，当需求发生变更时，及时通知所有涉及人员。
为了尽量减少困惑、冲突、误传，应该仅允许指定的人员来更新需求。
清楚地区分草稿和文档定稿版本。
4.2.4 需求变更
迟到的 需求变更 会对已进行的工作产生非常大的影响。
如果每一个建议的需求变更都采用，该项目将可能永远无法完成。
需求文档应该 精确描述 要交付的产品。
项目负责人 在信息充分的条件下 做出决策。
变更成本计算 应该包括 需求文档的修改、系统修改的设计、实现的成本。
变更控制过程 并不是给变更设置障碍，相反，它是一个渠道和过滤器，确保采纳最合适的变更，使变更产生的负面影响降到最低，变更过程应该做成文档。
绝不能 删除或者修改 变更请求的 原始文档。
变更控制委员会 只要能决定合适的人做正确的事就足够了，在保证权威性的前提下 应尽可能精简人员。
对每个变更 权衡利弊 做出决定。
“利”包括 节省资金 或 额外收入、客户满意度、竞争优势、减少上市时间；
“弊”是指 增加开发费用、推迟交付日期、产品质量下降、减少功能、用户不满意。
变更总是有代价的，即使 拒绝的变更 也因为决策行为 而耗费资源。
接受了重要的需求变更时，为了适应变更情况 要与管理部门和客户重新协商约定。推迟交货时间、增加人手、推迟实现尚未实现的较低优先级的需求，或质量上进行折中。
要是不能获得一些约定的调整，应该把面临的风险写进风险计划中。
4.2.5 需求跟踪
需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档 等。
跟踪能力（联系）链（traceability link）是优秀需求规格说明书的一个特征，确保软件需求规格说明包括所有客户需求。
跟踪能力联系链 记录了单个需求之间的 父层、互连、依赖 的关系。
不必拥有所有种类的跟踪能力联系链，要根据具体情况调整。
4.2.6 需求变更的代价和风险
只有在知道变更成本后 才能做出理智的选择，一个表面上很简单的变更 也可能转变成很复杂的局面。
影响分析 确定对现有系统做出是修改或者抛弃的决定，创建新系统以及评估每个任务的工作量，进行 影响分析的能力 依赖于 跟踪能力、数据的质量、完整性。
4.3 开发管理
1、范围
可交付物、架设、约束条件 的基础上准备详细的项目范围说明书，是项目成功的关键。
2、时间
进度安排的准确程度可能比成本估计的准确程度更重要。对于成本估计的偏差，可以靠重新定价或大量的销售来弥补成本的增加，
如果进度计划不能得到实施，则会导致市场机会的丧失或用户不满意，而且会使成本增加。
工作分解结构 Work Breakdown Structure WBS
4.3.2 配置管理 文档管理
1、配置管理
配置项 Configuration Item CI，
属于产品组成部分的工作成果，如 需求文档、设计文档、源代码、测试用例 等。
属于项目管理和机构支撑过程域 产生的文档，如 工作计划、项目质量报告、项目跟踪报告 等。
每个配置项的主要属性有 名称、标识符、文件状态、版本、作者、日期 等。
2、文档管理
文档是影响软件可维护性的决定因素，使用过程中必然会经受多次修改，所以文档比程序代码更重要。
用户文档：主要描述系统功能和使用方法。
系统文档：描述系统设计、实现、测试 等各方面内容。
软件文档应该满足下述要求：
1.如何使用
2.怎样安装 和 管理
3.需求 和 设计
4.实现 和 测试
说明用户操作错误时 应该怎样恢复和重新启动。
4.3.3 软件开发的质量与风险
1、软件质量
IOS9000 对 项目质量 的定义：一组固有特性 满足需求的 程度。
质量 与 范围、成本 和 时间，是项目成功的关键因素，通过范围管理 转换隐含需求为项目需求。
质量低 说明产品或服务存在问题，而低等级的产品或服务 不一定存在问题，二者概念不同。
2、软件开发风险
认识不足 或者 没有足够的力量加以控制。
了解、掌握 风险的来源、性质、发生规律，进而施行有效的管理。
或然性、不确定性、涉及到某种选择时，才成为有风险，以上三个是风险定义的必要条件，不是充分条件，具有不确定性的事件不一定是风险。
4.4.1 结构化分析与设计
结构程序设计 较流行的定义为：采用自顶向下 逐步求精 的设计方法 和 单入口单出口的控制构件。
自顶向下逐步求精的方法是：先整体后局部，先抽象后具体，一般具有较清晰的层次。
仅使用单入口单出口的控制构件，具有良好的结构特征。
采用结构程序设计，可能会多占用一些时间和空间资源，这也是那些反对从高级语言中排除GOTO语句者的主要依据。实际上，硬件飞速发展，这点耗费，不再是重要的因素。
4.4.2 面向对象的分析设计
面向对象的 分析模型主要由 顶层架构图、用例与用例图、领域概念模型 构成；
设计模型包含：
以包图表示的 软件体系结构图、
以交互图表示的 用例实现图、
完整精确的类图、
针对复杂对象的状态图、
描述流程化处理过程的 活动图 等。
4.5 软件的重用
重复使用 相同或相似 软件元素。
软件元素：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识 等，通产这些软件元素称为 软部件。
不断地进行软部件的积累，并将它们组织成软部件库。
横向重用（horizontal reuse）：重用不同应用领域中的软件元素。
标准函数库 是一种 典型的、原始的 横向重用机制。
纵向重用广受瞩目，并称为软件重用技术的真正希望所在，关键点是 域分析，根据应用领域的 特征 以及 相似性 预测软部件的可重用性。
库的组织结构 直接影响软部件的检索效率。
由于软部件大都经过严格的质量认证，并在实际运行环境中得到检验，因此重用软部件有助于改善软件质量。
4.6 逆向工程与重构工程
逆向工程 就是 分析已有的程序，寻找比源代码更高级的抽象表现形式。
相关概念：
重构 Restructuring，在同一抽象级别上转换系统描述形式；
设计恢复 design recovery，
重构工程 re-engineering，也称 修复和改造工程。
1、恢复信息的级别
逆向工程导出的信息，4个抽象层次
1.实现级
2.结构级
3.功能级
4.领域级
2、恢复信息的方法，4类：
1.用户指导下搜索与变换
2.变换式方法
3.基于领域知识的
4.铅板恢复法