C第八章软件质量与质量保证CM解读.ppt

4. 维护的问题很多 与软件维护有关的绝大部分问题，都可归因于软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。 和软件维护有关的部分问题： 理解别人写的程序通常非常困难，而且困难程度随着配置成分的减少而迅速增加。 如果仅有程序代码没有文档，则会出现严重的问题 需要维护的软件往往没有合格的文档，或者文档资料显著不足。 认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。 由于维护阶段持续的时间很长，因此，当需要理解软件时，往往原来写程序的人已经不在附近了。 绝大多数软件在设计时没有考虑将来的修改。 除非是强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。 软件维护不是一项吸引人的工作。 形成这种观念很发程度上是因为维护工作经常遭受挫折。 上述种种问题在现有的没采用软件过程思想开发出来的软件中，都或多或少地存在着。 8.2 软件维护的特点 8.10 软件维护8.10.2 软件维护步骤 1．维护步骤 （1）分析和理解程序 （2）修改程序 （3）详细地分析要修改的模块和数据结 构的内部细节，设计修改计划，标 明新逻辑及要改动的现有逻辑。 （4）向用户提供回避措施。 （5） 修改代码以适应变化 （6）重新验证程序 软件维护工作流程DFD 维护请求 类型 类型 严重性 评估后按优先 级在队列排队 “救火行动”,当 排在队列之首 评估后分类 评估后按优先 级在队列排队 采取的行动 通知请求者 并说明原因 按优先级在 队列中排队 从维护请求队列之首取出一任务 按SE方法学规划、组织、实施工程 队列中还有维护请求吗？ 资源用于开发新的软件。 y n 改正性 其他 完善性 适应性 拒绝 接受 并不严重 非常严重 软件维护工作流 2．维护组织 每个维护申请通过维护管理员转告给系统管理员，系统管理员一般都是对程序特别熟悉的技术人员，对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构（一个或一组管理者）报告，由它最后确定是否采取行动。 软件维护记录 维护结果：经过对需求的进一步确认，对指定编号的模块进行了修改，纠正了源程序中出现的错误。 维护人员：***** …… **** 0.2个人月 修改部分源程序 查错，确定错误位置 **月**日 维护人员 工作量 增/删/改 维护内容 日期 编号：evalobject_01 机器指令长度：25Kb 程序安装日期：****年**月**日 程序运行时间： 模块名称：测评控制管理 源程序行数：210 编程语言：PHP 失效次数：3 初始状态描述：不同类型的人员可以进行交叉测评。按需求：各类人员只进行自身类型的测测评，如管理人员只能对管理人员进行测评，教师只能测评教师。 项目名称：网络测评系统 计划编号：eval_wh_012 日期：****年**月**日 记录编号：eval_wh_012 8.10 软件维护8.10.3 软件的可维护性 1．影响可维护性的因素 （1）是否拥有一组训练有素的软件人员； （2）系统结构是否可理解； （3）是否使用标准的程序设计语言； （4）是否使用标准的操作系统； （5）文档的结构是否标准化； （6）测试用例是否合适； （7）是否已有嵌入系统的调试工具； （8）是否有一台计算机可用于维护。 影响可维护性的因素 开发环境 开发方法 维护工具的 因素 系统本身 的因素 人的因素 8.10 软件维护8.10.3 软件的可维护性 2．量化的测度 （1）发现问题所用的时间； （2）收集维护工具使用的时间； （3）分析问题所需时间； （4）形成修改说明书所用时间； （5）纠错（或修改）所用时间； （6）局部测试所用时间； （7）整体测试所用时间； （8）维护复审所用时间； （9）完全恢复所用时间。 这些数据反映了维护全过程中检错－纠错－验证的周期，即从检测出软件存在的问题开始至修正它们并经回归测试验证这段时间。可以粗略地认为，这个周期越短，维护越容易。 8.10 软件维护8.10.3 软件的可维护性 3．保证可维护性的复审 在软件工程每一阶段的复审中，可维护性都是重要的指标。 需求分析阶段的复审: 设计阶段的复审 代码复审 配置复审 软件开发期间各个检查点的检查重点 8.10 软件维护8.10.4 软件维护的副作用 软件维护的副作用， 是指软件维护过程中可能会引入的错误。 8.10 软件维护8.10.4 软件维护的副作用 1．代码副作用：多做回归测试。 （1）修改或删除子程序； （2）修改或删除语句标号； （3）修改或删除标识符； （4）为提高执