福州大学 · 软件学院 · 计算机教研室

1. 软件维护 (Software maintenance) 福州大学·软件学院·计算机教研室 王灿辉 SOFTWARE ENGINEERING

2. 软件维护 (Software maintenance) • 软件维护是指软件系统交付使用以后对它所做的改变，也是软件生命周期中最后一个阶段（不属于开发阶段）。 • The maintenance phase focuses on change that is associated with error correction, adaptations required as the software’s environment evolves,and changes due to enhancements brought by changing customer requirements. SOFTWARE ENGINEERING

3. 软件维护 (Software maintenance) • The maintenance phase reapplies the steps of the definition and development phases,but does so in the context of existing software. • 统计资料表明：大部分的维护工作是由用户的需求改变而引起的，而不是由可靠性问题引起的。 SOFTWARE ENGINEERING

4. 软件维护 (Software maintenance) • 软件维护是软件生命周期中历时最长，人力和资源耗费最多的一个阶段，也是研究最少的一个阶段。 SOFTWARE ENGINEERING

5. 软件维护 (Software maintenance) SOFTWARE ENGINEERING

6. 软件维护分类 • Corrective maintenance changes the software to correct defects. • Adaptive maintenance results in modification to the software to accommodate change to its environment. • Perfective maintenance extends the software beyond its original functional requirements. • Preventive maintenance,often called software reengineering,makes changes to computer programs so that they can be more easily corrected,adapted,and enhanced. SOFTWARE ENGINEERING

7. 软件维护分类 SOFTWARE ENGINEERING

8. 软件维护中的问题(1) • 读懂他人编写的程序通常相当困难，特别是一些非结构化程序。如果只有程序代码而没有文档说明问题将会十分严重。 • 软件人员经常流动，所以当要求对软件进行维护时，不可能依靠原开发人员提供对软件的解释（即使可能有时也因时间太久而导致原开发人员无法提供帮助）。 • 没有文档、文档严重不足，文档难于理解，或文档与程序不一致。 • 通过多种版本或发行，要追踪软件的演化变得很困难，甚至不可能。 SOFTWARE ENGINEERING

9. 软件维护中的问题(2) • 绝大多数软件在设计时不考虑以后可能的改变。除非采用功能独立的模块化设计方法，否则软件修改将是困难的，而且还容易引入新的错误。 • 追踪软件的建立过程非常困难。 • 维护被看作是毫无吸引力的工作，高水平的程序员自然不愿主动去做，而公司也舍不得让高水平的程序员去做。带着低沉情绪的低水平的程序员只会把维护工作搞得一塌糊涂。 • 维护将会产生不良的副作用，不论是修改代码、数据或文档，都有可能产生新的错误。 SOFTWARE ENGINEERING

10. 影响软件维护的因素 • 影响软件维护的因素包括：人员因素，技术因素和管理因素，程序自身的因素，具体如下： • 系统的规模。系统规模越大，维护越困难。 • 系统的年龄。系统运行时间越长，在维护中结构的多次修改会造成维护的困难。 • 系统的结构。不合理的程序结构会带来维护困难。 • 使用软件工程方法开发的软件，虽然不能保证维护没有问题，但可以减少维护的工作量，并提高质量。 SOFTWARE ENGINEERING

11. 软件维护费用 • 软件维护是既破财又费神的工作。看得见的代价是那些为了维护而投入的人力与财力。而看不见的维护代价则更加高昂，我们称之为“机会成本”，即为了得到某种东西所必须放弃的东西。 • 把很多程序员和其它资源用于维护工作，必然会耽误新产品的开发甚至会丧失机遇，这种代价是无法估量的。 SOFTWARE ENGINEERING

12. 软件维护费用 • 软件维护费用不断上升，从上世纪六十年代的40%左右到目前超过60%。 • 维护一行源代码的代价大概是开发的40倍！ • 维护工作量模型：M=P+K.e(c-d) ，其中，M：用于维护工作的总工作量；P：生产性的工作量(维护时对软件分析、评价、设计、修改和编码所需要的工作量)；K：经验常数；c：软件复杂程度的度量(如未采用结构化设计和缺少文档所引起的复杂性)；d：对该软件熟悉程度的度量。 SOFTWARE ENGINEERING

13. 软件的可维护性 • 软件的可维护性可以定义为：软件能够被理解、改正、适应和完善以适应新的环境的难易程度。 • 如果软件是可测试的，可理解的，可修改的，可移植的，可靠的，有效的和可用的，则说该软件是可维护的。 SOFTWARE ENGINEERING

14. 软件的维护任务 • 软件的维护任务包括： • 建立维护机构 • 编制维护报告(软件问题报告和软件修改报告) • 为维护请求规定工作流程 • 维护的技术工作(修改设计，复审设计，编码，单元测试、集成测试（含回归测试），有效性测试，最终复审) • 记录和保存维护活动的相关信息 • 对维护进行评价 SOFTWARE ENGINEERING

15. 软件维护的副作用 • 所谓软件维护的副作用(maintenance side effects)，就是指由于修改而导致的错误或其他多余动作的发生。 • 修改代码的副作用(回归测试可减少编码副作用) • 修改数据的副作用 • 修改文档的副作用 • 在软件再次交付使用之前，对整个软件配置进行评审将能大大减少文档的副作用。 SOFTWARE ENGINEERING

16. 再生工程 福州大学·软件学院·计算机教研室 王灿辉 SOFTWARE ENGINEERING

17. 再生工程 • 如果希望提高已有软件的质量并且提高商业竞争力，却又无法靠维护来实现，只好对已有软件进行全部或者部分的改造，这种活动叫再生工程（Reengineering）。 • 再生过程也叫改造工程，它不是从现有的软件中恢复设计信息，而是利用这些信息去改变或重建现存的系统，尽最大努力来提高它的整体质量。 SOFTWARE ENGINEERING

18. 再生工程 • 再生工程与维护的共同之处是没有抛弃原有的软件。如果把维护比作“修修补补”，那么再生工程就算是“痛改前非”。再生工程并不见得一定比维护的代价要高，但再生工程在将来获取的利益却要比通过维护得到的多。 • 再生工程（Reengineering）的三种类型：重构（Restructure）、逆向工程（Reverse Engineering）和前向工程（Forward Engineering）。 SOFTWARE ENGINEERING

19. 再生工程--重构 • 重构一般是指通过修改代码或数据以使软件符合新的要求。重构通常并不推翻原有软件的体系结构，主要是改造一些模块和数据结构。重构的一些好处如下： （1）使软件的质量更高，或使软件顺应新的潮流（标准）。 （2）使软件的后续（升级）版本的生产率更高。 （3）降低后期的维护代价。 • 要注意的是，在代码重构和数据重构之后，一定要重构相应的文档。 SOFTWARE ENGINEERING

20. 逆向工程 • 软件的逆向工程就是分析一个程序的过程，以最大努力去建立比源代码抽象层次更高的程序表达式。逆向工程也是一个设计的恢复过程。 • 逆向工程来源于硬件世界。硬件厂商总想弄到竞争对手产品的设计和制造“奥秘”。但是又得不到现成的档案，只好拆卸对手的产品并进行分析，企图从中获取有价值的东西。 • 软件的逆向工程在道理上与硬件的相似。但在很多时候，软件的逆向工程并不是针对竞争对手的，而是针对自己公司多年前的产品。期望从老产品中提取系统设计、需求说明等有价值的信息。 SOFTWARE ENGINEERING

21. 前向工程 • 前向工程也称预防性维护，由Miller倡导。他把这个术语解释成“为了明天的需要，把今天的方法应用到昨天的系统上”。 • 乍看起来，主动去改造一个目前运行得正常的软件系统简直就是“惹事生非”。但是软件技术发展如此迅速，与其等待一个有价值的产品逐渐老死，还不如主动去更新，以获取更大的收益。其道理就同打预防性针一样。所以，预防性维护是“吃小亏占大便宜”的事。 SOFTWARE ENGINEERING

22. 变更管理 福州大学·软件学院·计算机教研室 王灿辉 SOFTWARE ENGINEERING

23. 变更管理 • 变更是不可避免的。大多数变更是合理的。 • 不受控制的一系列变更轻而易举就能使一个运行良好的软件项目变得混乱。 • 由于在开发软件时会产生很多工作产品，所以必须唯一标识每一个工作产品。 • 变更管理，通常也叫软件配置管理(SCM)是贯穿于整个软件过程的普适性活动。区别于软件维护仅发生在软件交付给用户以后。 SOFTWARE ENGINEERING

24. 变更管理 • 软件配置管理(SCM)活动的目标：标识变更；控制变更；保证正确地实现变更；向利害相关人员报告变更。 • 软件配置管理(SCM)是一组在计算机软件的整个生存周期内管理变更的活动，可以把SCM看作是应用于整个软件过程的软件质量保证活动。 • 软件配置管理(SCM)计划：定义了变更管理的项目策略。 SOFTWARE ENGINEERING

25. 变更管理 • 软件配置项：是在软件工程过程中创建的信息（程序、数据、文档、软件工具）。 • 基线：已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。 • 基线是软件开发中的里程碑。 • SCM过程：配置对象标识；变更控制；版本控制；配置审核；状态报告； SOFTWARE ENGINEERING

26. 软件度量 福州大学·软件学院·计算机教研室 王灿辉 SOFTWARE ENGINEERING

27. 软件度量 • 如果不进行测量，就没法确定我们是否在改进，只能根据主观评价来做判断。 • 度量时,先收集基本的质量数据和生产率数据,往后分析这些数据,与过去的平均值进行比较,通过评估来确定是否已经有质量和生产率的提高。 • 度量也可以用来查明问题区域,以便确定合适的补救措施,并改进软件过程。 SOFTWARE ENGINEERING

28. 软件度量 • 只有度量是直观的且易于计算时才会被使用。若需要大量的“计数”，且需要复杂的计算，则该度量不可能得到广泛采纳。 • 度量可以应用于软件过程中，目的是持续地改进软件过程。度量应用于项目管理可以改进项目工作流程和技术活动。 SOFTWARE ENGINEERING

29. 软件度量—基于功能的度量 • 利用基于软件信息域可数的(直接)测度和软件复杂性评估的经验关系来计算功能点。 • 信息域及加权因子：外部输入数、外部输出数、外部查询数、内部逻辑文件数、外部接口文件数。 • 功能点FP=总计*(0.65+0.01+∑Fi) SOFTWARE ENGINEERING

30. 软件质量 (Software Quality) 福州大学·软件学院·计算机教研室 王灿辉 SOFTWARE ENGINEERING

31. Software Quality • 软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。 • 质量是软件需求方最关心的问题,生产率是软件供应方最关心的问题。质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提。 SOFTWARE ENGINEERING

32. Software Quality • 如果一个软件产品向其终端用户提供了实质性的益处，他们可能愿意忍受偶尔的可靠性和性能问题。 SOFTWARE ENGINEERING

33. Software Quality • 从短期效益看，追求高质量会延长软件开发时间并且增大费用，似乎降低了生产率。从长期效益看，高质量将保证软件开发的全过程更加规范流畅，大大降低了软件的维护代价，实质上是提高了生产率，同时可获得很好的信誉。 • 质量与生产率之间不存在根本的对立，好的软件工程方法可以同时提高质量与生产率。 SOFTWARE ENGINEERING

34. Software Quality • 对开发人员而言，如果非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二。这是因为：（1）质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求。（2）高质量对所有的用户都有价值，而高生产率只对开发方有意义。（3）如果一开始就追求高生产率，容易使人急功近利，留下隐患。宁可进度慢些，也要保证每个环节的质量，以图长远利益。 SOFTWARE ENGINEERING

35. Software Quality • “零缺陷”质量管理的观念来源于一些国际上著名的硬件生产厂商。尽管软件的开发与硬件生产有极大的差别，但我们仍可以从“零缺陷”质量管理中得到启迪。 • “零缺陷”质量管理至少有两个核心内容：一是高目标，二是可执行的规范。 • 软件的高质量主要是设计出来的，不是“管”出来的，更不能依赖质量检查。为此程序员要充分了解软件的质量因素，只有提高设计水平，才能开发出高质量的软件。 SOFTWARE ENGINEERING

36. Software Quality • 软件的质量因素很多，如正确性，性能与效率、可靠性、容错性、易用性、灵活性、可理解性与简洁性、可复用性和可扩充性、可维护性等等。有些因素相互重叠，有些则相抵触，真要提高质量可不是一件容易的事！ SOFTWARE ENGINEERING

37. Software Quality • 如：健壮性是软件的一个质量因素，指的是在硬件发生故障、输入的数据无效或操作错误等意外情况下，软件系统能做出适当响应的程度。 • 程序员在编写实现方法的代码时，既应该考虑效率，也应该考虑健壮性。通常需要在健壮性与效率之间做出适当的折衷。必须认识到，对于任何一个实用软件来说，健壮性都是不可忽略的质量指标。 SOFTWARE ENGINEERING

38. Software Quality • 与明确定义的功能和性能需求的一致性 • 与明确成文的开发标准的一致性 • 与所有专业开发的软件所期望的隐含的特性（如：健壮性、可维护性、良好的界面风格、可移植性等）的一致性 SOFTWARE ENGINEERING

39. 软件质量 (Software Quality) • 软件质量是难于定量度量的软件属性，但是仍然能够提出许多重要的软件质量指标，这些指标主要从管理的角度对软件质量进行度量。 • The factors that affect software quality can be categorized in two broad groups: • Factors that can be directly measured (e.g.,defects per function point) and • Factors that can be measured only indirectly(e.g.,usability or maintainability) SOFTWARE ENGINEERING

40. 软件质量 (Software Quality) • 软件质量指标往往互相矛盾。例如：采用容错技术==》提供可靠性==》但占用较多的存储空间和执行时间==》降低时空效率，增加软件系统维护的困难===》因此应综合平衡 SOFTWARE ENGINEERING

41. 软件质量(Software Quality)—(McCall’s Software Quality Factors) Maintainability Flexibility Testability Portability Reusability Interoperability Product Revision Product Transition Product Operation Correctness Reliability Usability Integrity Efficiency SOFTWARE ENGINEERING

42. 软件质量(Software Quality)—(McCall’s Software Quality Factors) SOFTWARE ENGINEERING

43. 软件质量—(Hewlett-Packard’s Software Quality Factors) • Hewlett-Packard has developed a set of software quality factors that has been given the acronym FURPS—functionality, usability, reliability, performance, and supportability. SOFTWARE ENGINEERING

44. 软件质量—(Hewlett-Packard’s Software Quality Factors) • Supportability combines the ability to extend the program(extensibility),adaptability,and serviceability(these three attributes represent a more common term--maintainability), as well as testability,compatibility,configurability(the ability to organize and control elements of the software configuration),the ease with which a system can be installed,and the ease with which problems can be localized. SOFTWARE ENGINEERING

45. 软件质量 (Software Quality) • 为了在软件开发过程中保证软件的质量，主要采取下述措施： • 复审（至少在每个开发阶段结束前一次） • 复查（在每个开发阶段开始前） • 管理复审 • 测试 • 软件质量在产品或系统中是事先设计好的，而不是事后强加的。 SOFTWARE ENGINEERING

46. 软件质量 (Software Quality) • 质量检查并不是要等到项目结束时才执行唯一的一次，应该在每个实践环节都要执行。对应于进度表，在每个里程碑到达时执行质量检查比较合理。 • 做好检查工作并不是件容易的事。自古以来“上有政策，下有对策”。 虚假的质量检查还不如不检查。 SOFTWARE ENGINEERING

47. 软件优化 • 软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好，使三维图形的真实感更强等等。 • 想做好优化工作，首先要让开发人员都有正确的认识：优化工作不是可有可无的事情，而是必须要做的事情。当优化工作成为一种责任时，程序员才会不断改进软件中的算法，数据结构和程序组织，从而提高软件质量。 SOFTWARE ENGINEERING

48. 软件优化 • 优化工作的复杂之处是很多目标存在千丝万缕的关系。当不能够使所有的目标都得到优化时，就需要“折衷”策略。 • 软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。就象党支部副书记扮演和事佬的角色：“…为了使整个组织具有最好的战斗力，我们要重用几个人，照顾一些人，在万不得已的情况下委屈一批人”。 SOFTWARE ENGINEERING

49. 软件优化 • 软件折衷的重要原则是不能使某一方损失关键的职能，更不可以象“舍鱼而取熊掌”那样抛弃一方。 • 人都有惰性，如果允许滥用折衷的话，那么一当碰到困难，人们就会用拆东墙补西墙的方式去折衷，不再下苦功去做有意义的优化。所以我们有必要为折衷制定严正的立场：在保证其它因素不变差的前提下，使某些因素变得更好。 SOFTWARE ENGINEERING

50. 软件质量保证 (Software Quality Assurance) 福州大学·软件学院·计算机教研室 王灿辉 SOFTWARE ENGINEERING