系统架构师学习笔记_第四章(下)

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.铅板恢复法

你可能感兴趣的:(学习笔记)