2014年软考《系统架构设计师》考点:第四章

　　4.1.5 软件系统工具

　　按软件过程活动将软件工具分为 软件开发工具、软件维护工具、软件管理和软件支持工具。

　　软件开发工具有：需求分析工具、设计工具、编码与排错工具、测试工具 等。

　　需求分析工具，生成完整的、清晰的、一致的功能规范。功能规范是软件开发者和用户间的契约，也是软件设计者的和实现者的依据。正确、完整 表达清晰的、无歧义的。

　　需求分析工具分为 基于自然语言或图形描述的工具，基于形式化需求定义语言的工具。

　　项目管理工具：项目的 计划、调度、通信、成本估算、资源分配、质量控制等。

　　4.2 需求管理

　　需求 最终文档 经过评审批准后，则定义了需求基线 Baseline;构筑了 功能需求 和 非功能需求 的一个 约定Agreement。约定是需求开发和需求管理之间的桥梁。

　　需求管理是一个 对系统 需求变更、了解和控制 的过程，初始需求导出的同时 就启动了需求管理规划。

　　4.2.1 需求管理原则

　　过程能力成熟度模型 CMM，指导软件过程改进，5个成熟级别，6个关键过程域KPA。

　　一旦需求 文档化了，开发组和有关团队 需要评审文档。发现问题应与客户或者其他需求源协商解决。软件开发计划是基于 已确认的需求。

　　绝不要承诺 任何 无法实现的事。

　　关键处理领域 通过版本控制和变更控制 来管理需求文档。确保与新的需求保持一致。

　　4.2.2 需求规格说明的版本控制

　　版本控制是管理需求的一个必要方面，必须统一确定需求文档的每一个版本，当需求发生变更时，及时通知所有涉及人员。

　　为了尽量减少困惑、冲突、误传，应该仅允许指定的人员来更新需求。

　　清楚地区分草稿和文档定稿版本。

　　4.2.3 需求变更

　　迟到的 需求变更 会对已进行的工作产生非常大的影响。

　　如果每一个建议的需求变更都采用，该项目将可能永远无法完成。

　　需求文档应该 精确描述 要交付的产品。

　　项目负责人 在信息充分的条件下 做出决策。

　　变更成本计算 应该包括 需求文档的修改、系统修改的设计、实现的成本。

　　变更控制过程 并不是给变更设置障碍，相反，它是一个渠道和过滤器，确保采纳最合适的变更，使变更产生的负面影响降到最低，变更过程应该做成文档。

　　绝不能 删除或者修改 变更请求的 原始文档。

　　变更控制委员会 只要能决定合适的人做正确的事就足够了，在保证权威性的前提下 应尽可能精简人员。

　　对每个变更 权衡利弊 做出决定。

　　“利”包括 节省资金 或 额外收入、客户满意度、竞争优势、减少上市时间;

　　“弊”是指 增加开发费用、推迟交付日期、产品质量下降、减少功能、用户不满意。

　　变更总是有代价的，即使 拒绝的变更 也因为决策行为 而耗费资源。

　　接受了重要的需求变更时，为了适应变更情况 要与管理部门和客户重新协商约定。推迟交货时间、增加人手、推迟实现尚未实现的较低优先级的需求，或质量上进行折中。

　　要是不能获得一些约定的调整，应该把面临的风险写进风险计划中。

　　4.2.4 需求跟踪

　　需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档 等。

　　跟踪能力(联系)链(traceability link)是优秀需求规格说明书的一个特征，确保软件需求规格说明包括所有客户需求。

　　跟踪能力联系链 记录了单个需求之间的 父层、互连、依赖 的关系。

　　不必拥有所有种类的跟踪能力联系链，要根据具体情况调整。

　　相关推荐：

　　软考经验：8种方法有效帮你调节考前心理

　　考前必备：计算机软考临考前十大注意事项

　　2014计算机软考软件设计师试题分析及备考建议