软件工程笔记：软件演变

该部分为本科期间软件工程课程笔记备份。

Evolution Concept

Software change 软件更改

Software change is inevitable 必然的

• New requirements emerge when the software is used; 出现新需求
• The business environment changes; 商业环境改变
• Errors must be repaired; 修复错误
• New computers and equipment is added to the system; 在系统中增加了新的计算机和设备;
• The performance or reliability of the system may have to be improved. 可能需要提高系统的性能或可靠性。

A key problem for all organizations is implementing and managing change to their existing software systems. 所有组织的一个关键问题是实施和管理对其现有软件系统的更改。

Importance of evolution 进化的重要性

Organizations have huge investments in their software systems - they are critical business assets. 组织对其软件系统进行了巨额投资--它们是关键的业务资产。

To maintain the value of these assets to the business, they must be changed and updated. 若要保持这些资产对业务的价值, 必须对其进行更改和更新。

The majority of the software budget in large companies is devoted to changing and evolving existing software rather than developing new software. 大公司的大部分软件预算都用于改变和发展现有软件, 而不是开发新的软件。

A spiral modelof development and evolution 螺旋模型

Evolution and servicing 进化和服务

• Evolution 进化、演化
  • The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system.软件系统生命周期中的一个阶段, 它正在运行, 并随着系统中提出和实施新的需求而不断演变。
• Servicing 服务
  • At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added. 在此阶段, 软件仍然有用, 但所做的唯一更改是保持其运行所需的更改, 即错误修复和更改, 以反映软件环境中的更改。未添加新功能。
• Phase-out 逐步淘汰
  • The software may still be used but no further changes are made to it. 该软件仍可使用, 但不会对其进行进一步更改。

Evolution processes 演变过程

Software evolution processes depend on 软件的进化过程取决于

• The type of software being maintained; 正在维护的软件类型;
• The development processes used; 使用的开发过程;
• The skills and experience of the people involved. 相关人员的技能和经验。

Proposals for change are the driver for system evolution 修改建议是系统演进的驱动力

• Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated. 应与受变化影响的组件挂钩, 从而能够估计变化的成本和影响。

Change identification and evolution continues throughout the system lifetime. 更改识别和演变在整个系统生命周期中继续进行。

Change identification and evolution processes 更改识别和演变过程

The software evolution process 软件的演变过程

Change implementation 更改实施

Change implementation 更改实施

Iteration迭代 of the development process where the revisions修订 to the system are designed, implemented and tested. 对系统的修订进行设计、实施和测试的开发过程的迭代。

A critical difference is that the first stage of change implementation may involve program understanding, especially if the original system developers are not responsible for the change implementation. 一个关键的区别是, 更改实现的第一阶段可能涉及程序理解, 特别是在原始系统开发人员不负责更改实现的情况下。

During the program understanding phase, you have to understand how the program is structured, how it delivers functionality and how the proposed change might affect the program. 在程序理解阶段, 您必须了解程序的结构、如何提供功能以及建议的更改可能对程序产生的影响。

Urgent change requests 紧急变更请求

Urgent changes may have to be implemented without going through all stages of the software engineering process 可能必须在不经历软件工程过程所有阶段的情况下实施紧急变革

• If a serious system fault has to be repaired to allow normal operation to continue; 如果必须修复严重的系统故障, 以便继续正常运行;
• If changes to the system’s environment (e.g. an OS upgrade) have unexpected effects; 如果对系统环境的更改 (例如操作系统升级) 具有意外效果;
• If there are business changes that require a very rapid response (e.g. the release of a competing product). 如果有业务变化需要非常迅速的反应 (例如, 发布竞争产品)。

The emergency repair process 紧急维修流程

Agile敏捷的 methods and evolution

Agile methods are based on incremental development so the transition过渡 from development to evolution is a seamless无缝的 one. 敏捷方法是以增量开发为基础的, 因此从开发到进化的过渡是一个无缝的过程。

• Evolution is simply a continuation延续 of the development process based on frequent system releases. 进化仅仅是基于频繁系统发布的开发过程的一个延续。

Automated regression testing 自动回归测试 is particularly valuable when changes are made to a system. 当对系统进行更改时, 自动回归测试特别有价值。

Changes may be expressed as additional user stories. 更改可以表示为其他用户情景。

Handover problems 移交问题

Where the development team have used an agile approach but the evolution team is unfamiliar with agile methods and prefer a plan-based approach. 开发团队使用了敏捷方法, 但进化团队不熟悉敏捷方法, 更喜欢基于计划的方法。

• The evolution team may expect detailed documentation to support evolution and this is not produced in agile processes. 进化团队可能期望详细的文档来支持进化, 而这并不是在敏捷过程中产生的。

Where a plan-based approach has been used for development but the evolution team prefer to use agile methods. 在开发中使用了基于计划的方法, 但进化团队更喜欢使用敏捷方法。

• The evolution team may have to start from scratch 从头开始developing automated tests, and the code in the system may not have been refactored重构 and simplified简化 as is expected in agile development. 进化团队可能必须从零开始开发自动测试, 系统中的代码可能没有像敏捷开发中预期的那样被重新分解和简化。

Program evolution dynamics 程序进化动态

Program evolution dynamics is the study of the processes of system change. 是对系统变化过程的研究。

After several major empirical studies, Lehman and Belady(1985) proposed that there were a number of ‘laws’ which applied to all systems as they evolved. 经过几项重大实证研究, 雷曼兄弟和 Belady(1985) 提出, 有一些 "法律" 随着系统的发展而适用于所有系统。

There are sensible observations rather than laws. They are applicable to large systems developed by large organisations. 有合理的观察而不是法律。它们适用于大型组织开发的大型系统。

• It is not clear if these are applicable to other types of software system. 目前尚不清楚这些系统是否适用于其他类型的软件系统。

Change is inevitable 改变是不可避免的

The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements! 由于环境正在变化, 在系统开发过程中, 系统需求可能会发生变化。因此, 交付的系统将无法满足其需求!

Systems are tightly coupled with their environment. When a system is installed in an environment, it changes that environment and therefore changes the system requirements.系统与环境紧密相连。当系统安装在环境中时, 它将更改该环境, 从而更改系统需求。

Systems MUST be changed if they are to remain useful in an environment. 如果要在环境中保持有用, 就必须更改系统。

Lehman’s laws 雷曼兄弟的法律

Law	Description描述
Continuing change持续变化	A program that is used in a real-world environment must necessarily change, or else become progressively less useful in that environment. 在实际环境中使用的程序必须更改, 否则在该环境中的用处会逐渐降低。
Increasing complexity日益增加的复杂性	As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure. 随着程序的不断发展, 其结构往往变得更加复杂。必须投入额外资源来维护和简化结构。
Large program evolution大型程序的演变	Program evolution is a self-regulating process. System attributes such as size, time between releases, and the number of reported errors is approximately invariant for each system release. 程序进化是一个自我调节的过程。对于每个系统版本, 系统属性 (如大小、发布之间的时间和报告的错误数) 大约是不变的。
Organizational stability组织稳定性	Over a program’s lifetime, its rate of development is approximately constant, and independent of the resources devoted to system development. 在程序的生命周期中, 其开发速度大致保持不变, 并且与专门用于系统开发的资源无关。
Conservation of familiarity保护熟悉程度	Over the lifetime of a system, the incremental change in each release is approximately constant.在系统的生存期内, 每个版本中的增量更改大致保持不变。
Continuing growth持续增长	The functionality offered by systems has to continually increase to maintain user satisfaction.系统提供的功能必须不断增加, 以保持用户满意度。
Declining quality质量下降	The quality of systems will decline unless they are modified to reflect changes in their operational environment.除非对系统进行修改以反映其业务环境的变化, 否则系统的质量将下降。
Feedback system反馈系统	Evolution processes incorporate multiagent, multiloop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.进化过程包括多智能体、多回路反馈系统, 您必须将其视为反馈系统, 以实现显著的产品改进。

Applicability适用性 of Lehman’s laws

Lehman’s laws seem to be generally applicable to large, tailored systems developed by large organisations. 雷曼兄弟的法律似乎普遍适用于大型组织开发的大型定制系统。

• Confirmed in early 2000’s by work by Lehman on the FEAST project. 2000年初由雷曼兄弟在 FEED 项目上的工作确认。

It is not clear how they should be modified for 目前尚不清楚应如何修改它们

• Shrink-wrapped software products; 收缩包装的软件产品;
• Systems that incorporate a significant number of COTS components; 包含大量 COTS 组件的系统;
• Small organisations; 小型组织;
• Medium sized systems. 中型系统。

Software maintenance 软件维护

Modifying a program after it has been put into use. 在程序投入使用后对其进行修改。

The term is mostly used for changing custom software. Generic software products are said to evolve to create new versions. 此术语主要用于更改自定义软件。据说, 通用软件产品会不断发展, 以创建新版本。

Maintenance does not normally involve major changes to the system’s architecture. 维护通常不涉及对系统体系结构的重大更改。

Changes are implemented by modifying existing components and adding new components to the system.更改是通过修改现有组件和向系统中添加新组件来实现的。

Types of maintenance 维护类型

Fault repairs. Maintenance to repair software faults 故障修复。修复软件故障的维护

• Changing a system to correct deficiencies in the way meets its requirements. 改变一个系统, 以纠正方式上的缺陷, 满足其需求。

Environmental adaptation. Maintenance to adapt software to a different operating environment 环境适应。维护, 使软件适应不同的操作环境

• Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation. 更改系统, 使其从最初的实现中在不同的环境 (计算机、操作系统等) 中运行。

Functionality addition. Maintenance to add or modify the system’s functionality 功能增加。添加或修改系统功能的维护

• Modifying the system to satisfy new requirements. 修改系统以满足新的需求。

Maintenance effort distribution 维护工作量分配

Maintenance costs 维护成本

Usually** greater than development costs** (roughly two-thirds maintenance, one-third developmentdepending on the application) . 通常大于开发成本 (大约三分之二的维护, 三分之一的开发取决于应用程序)。

Affected by both technical and non-technical factors. 受技术和非技术因素的影响。

Cost Increases as software is maintained. 随着软件的维护而增加成本。

• Maintenance corrupts the software structure so makes further maintenance more difficult. 维护会破坏软件结构, 因此进一步维护更加困难。

Ageing software can have high support costs 老化软件可能具有很高的支持成本 (例如, 旧语言、编译器等)。

Development and maintenance costs 开发和维护成本:

For system1, extra development costs of $25,000 are invested in making the system more maintainable. This results in a saving of $100,000 in maintenance costs over the lifetime of the system. 对于系统 1, 投入了 25, 000 美元的额外开发成本, 使系统更易于维护。这将在系统的整个生命周期内节省 100, 000 美元的维护费用。

This assumes that a percentage increase in development costs results in a comparable percentage decrease in overall system costs.这假定开发成本增加一个百分比, 导致整个系统费用的相应百分比下降。

Maintenance cost factors 维护成本因素

• Team stability 团队稳定性
  • Maintenance costs are reduced if the same staff are involved with them for some time. 如果相同的工作人员参与一段时间, 维护费用就会减少。
• Poor development practice(Contractual responsibility) 不良的发展做法 (合同责任)
  • The maintenance contract may be given to a different company rather than the original system developer. The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change. 维修合同可以交给不同的公司, 而不是原来的系统开发者。系统的开发人员可能没有维护的合同责任, 因此没有为未来的变化设计的动力。
• Staff skills 员工技能
  • Maintenance staff are often inexperienced and have limited domain knowledge.维护人员通常经验不足, 并且拥有有限的领域知识。
• Program age and structure 课程年龄和结构
  • As programs age, their structure is degraded and they become harder to understand and change. 随着节目的老化, 它们的结构退化, 变得更加难以理解和改变。

Maintenance prediction 维护预测

Maintenance prediction is concerned with assessing评估which parts of the system may cause problems and have high maintenance costs维护预测涉及评估系统的哪些部分可能会导致问题并具有较高的维护成本

• Change acceptance depends on the maintainability of the components affected by the change;更改接受程度取决于受更改影响的组件的可维护性;
• Implementing changes degrades the system and reduces its maintainability;实施更改会降低系统的可维护性, 并降低其可维护性;
• Maintenance costs depend on the number of changes and costs of change depend on maintainability.维护成本取决于更改的数量, 更改的成本取决于可维护性。

Maintenance prediction

Change prediction 更改预测

Predicting the number of changes requires and understanding of the relationships between a system and its environment.预测更改的数量需要了解系统与其环境之间的关系。

Tightly coupled紧密耦合的 systems require changes whenever the environment is changed.

Factors influencing the relationships between a system and its environment are影响系统与其环境之间关系的因素包括

• Number and complexity of system interfaces;系统接口的数量和复杂性;
• Number of inherently volatile system requirements;固有的不稳定系统需求的数量;
• The business processes where the system is used.使用系统的业务流程。

Complexity metrics 复杂性指标

Predictions of maintainability can be made by assessing the complexity of system components.通过评估系统组件的复杂性, 可以预测可维护性。

Studies have shown that most maintenance effort is spent on a relatively small number of system components. 大多数维护工作都花在了相对较少的系统组件上。

Complexity depends on 复杂性取决于

• Complexity of control structures;控制结构
• Complexity of data structures;数据结构
• Object, method (procedure) and module size.对象、方法 (过程) 和模块大小。

Process metrics

Process metrics may be used to assess maintainability流程指标可用于评估可维护性

• Number of requests for corrective maintenance;需求纠正性维护的次数;
• Average time required for impact analysis;影响分析所需的平均时间;
• Average time taken to implement a change request;执行变更请求所需的平均时间;
• Number of outstanding change requests.未完成的更改请求数

If any or all of these is increasing, this may indicate a decline in maintainability.如果其中任何或所有的增加, 这可能表明可维护性下降。

System re-engineering 系统再工程

Re-structuring or re-writing part or all of a legacy system without changing its functionality.在不更改部分或全部遗留系统的功能的情况下, 对其进行重组或重写。

Applicable where some but not all sub-systems of a larger system require frequent maintenance.适用于较大系统的某些子系统 (但不是所有子系统) 需要频繁维护的情况。

Re-engineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented.重新设计包括增加努力, 使其更易于维护。该系统可以重新构建结构并重新记录。

Advantages of reengineering 再工程的优点

• Reduced risk 降低风险
  • There is a high risk in new software development. There may be development problems, staffing problems and specification problems.新软件开发存在高风险。可能存在开发问题、人员配置问题和规格问题。
• Reduced cost 降低成本
  • The cost of re-engineering is often significantly less than the costs of developing new software.重新设计的成本往往大大低于开发新软件的成本。

The reengineering process 再工程的过程

Reengineering process activities 再工程过程的活动

• Source code translation源代码转换
  • Convert code to a new language.将代码转换为新语言。
• Reverse engineering逆向工程
  • Analyze the program to understand it;分析程序以了解它;
• Program structure improvement计划结构改进
  • Restructure automatically for understandability;自动重组, 以实现可理解性;
• Program modularization程序模块化
  • Reorganize the program structure;重组方案结构;
• Data reengineering数据再造
  • Clean-up and restructure system data.清理和重组系统数据。

Reengineering approaches 再工程的方法

The diagram shows a spectrum of possible approaches to reengineering .该图显示了一系列可能的重新设计方法。

The costs of reengineering obviously depend on the extent of the work that is carried out.重新设计的费用显然取决于所开展工作的程度。

Costs increase from left to right so that source code translation is the cheapest option.成本从左到右增加, 因此源代码翻译是最便宜的选择。

Reengineering as part of architectural migration is the most expensive.重新设计作为体系结构迁移的一部分是最昂贵的。

Reengineering cost factors 再工程成本因素

The quality of the software to be reengineered.要重新设计的软件的质量。

The tool support available for reengineering.可用于重新设计的工具支持。

The extent of the data conversion which is required.所需的数据转换的范围。

The availability of expert staff for reengineering.有专业人员进行重新设计。

• This can be a problem with old systems based on technology that is no longer widely used.这可能是基于不再广泛使用的技术的旧系统的问题。

Preventative maintenance by refactoring 通过重构进行预防性维护

Refactoring is the process of making improvements to a program to slow down degradation through change.重构是对程序进行改进的过程, 目的是通过更改来减缓退化。

You can think of refactoring as ‘preventative maintenance’ that reduces the problems of future change.您可以将重构视为 "预防性维护", 以减少未来更改的问题。

Refactoring involves modifying a program to improve its structure, reduce its complexity or make it easier to understand.重构包括修改程序以改进其结构、降低其复杂性或使其更易于理解。

When you refactor a program, you should not add functionality but rather concentrate on program improvement.重构程序时, 不应添加功能, 而应专注于程序改进。

Refactoring and reengineering重构和再工程

Re-engineering takes place after a system has been maintained for some time and maintenance costs are increasing. You use automated tools to process and re-engineer a legacy system to create a new system that is more maintainable.再工程是在系统维护一段时间, 维护费用不断增加之后进行的。您可以使用自动化工具来处理和重新设计遗留系统, 以创建更易于维护的新系统。

Refactoring is a continuous process of improvement throughout the development and evolution process. It is intended to avoid the structure and code degradation that increases the costs and difficulties of maintaining a system.重构是一个在整个开发和进化过程中持续改进的过程。其目的是避免结构和代码退化, 因为这种退化增加了维护系统的成本和困难。

‘Bad smells’ in program code程序代码中的 难闻的气味

• Duplicate code 重复的代码（冗余）
  • The same or very similar code may be included at different places in a program. This can be removed and implemented as a single method or function that is called as required.
• Long methods 长方法
  • If a method is too long, it should be redesigned as a number of shorter methods.如果方法太长, 则应将其重新设计为一些较短的方法。
• Switch (case) statements 切换 (案例) 语句
  • These often involve duplication, where the ‘switch’ depends on the type of a value. The switch statements may be scattered around a program. In object-oriented languages, you can often use polymorphism to achieve the same thing.这些通常涉及重复, 其中 “switch” 取决于值的类型。switch语句可能分散在程序中。在面向对象的语言中, 您通常可以使用多态性来实现相同的目标。

‘Bad smells’ in program code

• Data clumping 数据聚集
  • Data clumps occur when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program. These can often be replaced with an object that encapsulates all of the data.当同一组数据项 (类中的字段、方法中的参数) 在程序中的多个位置重新出现时, 就会发生数据团块。这些通常可以替换为封装所有数据的对象。
• Speculative generality 假设的一般性
  • This occurs when developers include generality in a program in case it is required in the future. This can often simply be removed.当开发人员在将来需要的情况下在程序中包含通用性时, 就会发生这种情况。这通常可以简单地删除。

Fowler, in his book and website, also suggests some primitive refactoring transformations that can be used singly or together to deal with the bad smells.
Examples of these transformations are: Extract method(remove duplication and create a new method), Consolidate conditional expression(replace a sequence of tests with a single test), Pull up method(replace similar methods in subclasses with a single method in a super class).
福勒在他的书和网站上也提出了一些原始的重构转换, 可以单独或一起用来处理难闻的气味。
这些转换的示例有: 提取方法 (删除重复并创建新方法)、合并条件表达式 (用单个测试替换测试时序)、"拉" 方法 (用超级类)。

Legacy system management 遗留系统管理

Organizations that rely on legacy systems must choose a strategy for evolving these systems依赖传统系统的组织必须选择开发这些系统的策略

• Scrap the system completely and modify business processes so that it is no longer required;完全报废系统并修改业务流程, 使其不再需要;
• Continue maintaining the system;继续维护系统;
• Transform the system by re-engineering to improve its maintainability;通过重新设计改造系统, 提高系统的可维护性;
• Replace the system with a new system.将系统替换为新系统。

The strategy chosen should depend on the system quality and its business value.所选择的策略应取决于系统质量及其业务价值。

An example of a legacy system assessment遗留系统评估的示例

Legacy system categories 遗留系统类别

• Low quality, low business value低质量、低业务价值
  • These systems should be scrapped. 丢弃
• Low-quality, high-business value低质量、高业务价值
  • These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available.
• High-quality, low-business value高品质、低业务价值
  • Replace with COTS, scrap completely or maintain.
• High-quality, high business value高品质、高业务价值
  • Continue in operation using normal system maintenance

Business value assessment 业务价值评估

Assessment should take different viewpoints into account评估应考虑到不同的观点

• System end-users;系统终端用户;
• Business customers;商业客户;
• Line managers;各级经理;
• IT managers; IT 经理;
• Senior managers.高级管理人员。

Interview different stakeholders and collate results.采访不同的利益相关者, 整理结果。

Issues in business value assessment 业务价值评估中的问题

• The use of the system 系统的使用
  • If systems are only used occasionally or by a small number of people, they may have a low business value. 如果系统只是偶尔使用或由少数人使用, 它们的业务价值可能很低。
• The business processes that are supported 支持的业务流程
  • A system may have a low business value if it forces the use of inefficient business processes(cannot change business processes). 如果系统强制使用效率低下的业务流程 (不能更改业务流程), 则系统的业务价值可能较低。
• System dependability 系统可靠性
  • If a system is not dependable and the problems directly affect business customers, the system has a low business value. 如果一个系统不可靠, 问题直接影响到业务客户, 系统的业务价值就会很低。
• The system outputs 系统输出
  • If the business depends on system outputs, then the system has a high business value. 如果业务依赖于系统输出, 则系统具有较高的业务价值。

System quality assessment 系统质量评估

• Business process assessment 业务流程评估
  • How well does the business process support the current goals of the business? 业务流程在多大程度上支持了业务的当前目标？
• Environment assessment 环境评估
  • How effective is the system’s environment and how expensive is it to maintain? 系统的环境有多有效, 维护成本有多高？
• Application assessment 申请评估
  • What is the quality of the application software system? 应用软件系统的质量如何？

Business process assessment

Use a viewpoint-oriented approach and seek answers from system stakeholders 使用面向视点的方法, 并向系统利益相关者寻求答案

• Is there a defined process model and is it followed? 是否有定义的流程模型, 是否遵循？
• Do different parts of the organisation use different processes for the same function? 组织的不同部分是否对同一职能使用不同的流程？
• How has the process been adapted? 这一进程是如何调整的？
• What are the relationships with other business processes and are these necessary? 与其他业务流程有哪些关系, 这些关系是必要的？
• Is the process effectively supported by the legacy application software?遗留应用软件是否有效地支持该过程？

Example - a travel ordering system may have a low business value because of the widespread use of web-based ordering.例如-旅行订购系统可能有一个较低的商业价值, 因为广泛使用基于 web 的订购。

Factors used in environment assessment 环境评估中使用的因素

Factor因素	Questions问题
Supplier stability供应商稳定性	Is the supplier still in existence? Is the supplier financially stable and likely to continue in existence? If the supplier is no longer in business, does someone else maintain the systems? 供应商是否仍然存在？供应商的财务状况是否稳定, 并有可能继续存在？如果供应商不再营业, 是否有人维护这些系统？
Failure rate失效率	Does the hardware have a high rate of reported failures? Does the support software crash and force system restarts? 硬件是否具有较高的报告故障率？支持软件崩溃并强制系统重新启动吗？
Age 年限	How old is the hardware and software? The older the hardware and support software, the more obsolete it will be. It may still function correctly but there could be significant economic and business benefits to moving to a more modern system. 硬件和软件的历史有多大？硬件和支持软件越旧, 它就会越过时。它可能仍然正常运作, 但转向更现代化的系统可能会带来重大的经济和商业利益。
Performance性能	Is the performance of the system adequate? Do performance problems have a significant effect on system users? 系统的性能是否足够？性能问题是否对系统用户有重大影响？
Support requirements 支持需求	What local support is required by the hardware and software? If there are high costs associated with this support, it may be worth considering system replacement. 硬件和软件需要哪些本地支持？如果与这种支持相关的高成本, 可能值得考虑更换系统。
Maintenance costs 维护成本	What are the costs of hardware maintenance and support software licences? Older hardware may have higher maintenance costs than modern systems. Support software may have high annual licensing costs. 硬件维护和支持软件 许可证的成本是多少？较旧的硬件可能比现代系统具有更高的维护成本。支持软件每年的许可成本可能会很高。
Interoperability 互操作性	Are there problems interfacing the system to other systems? Can compilers, for example, be used with current versions of the operating system? Is hardware emulation required? 系统与其他系统之间是否存在问题？例如, 编译器是否可以与当前版本的操作系统一起使用？是否需要硬件仿真？
Understandability 可理解性	How difficult is it to understand the source code of the current system? How complex are the control structures that are used? Do variables have meaningful names that reflect their function? 了解当前系统的源代码有多困难？使用的控制结构有多复杂？变量是否有反映其函数的有意义的名称？
Documentation 文档	What system documentation is available? Is the documentation complete, consistent, and current? 提供了哪些系统文档？文档是否完整、一致和最新？
Data 数据	Is there an explicit data model for the system? To what extent is data duplicated across files? Is the data used by the system up-to-date and consistent? 系统是否有显式数据模型？数据在多大程度上跨文件重复？系统使用的数据是否最新和一致？
Performance 性能	Is the performance of the application adequate? Do performance problems have a significant effect on system users? 应用程序的性能是否足够？性能问题是否对系统用户有重大影响？
Programming language 编程语言	Are modern compilers available for the programming language used to develop the system? Is the programming language still used for new system development? 现代编译器是否可用于用于开发系统的编程语言？编程语言是否仍用于新系统开发？
Configuration management 配置管理	Are all versions of all parts of the system managed by a configuration management system? Is there an explicit description of the versions of components that are used in the current system? 系统所有部分的所有版本是否都由配置管理系统管理？是否对当前系统中使用的组件版本进行了明确说明？
Test data 测试数据	Does test data for the system exist? Is there a record of regression tests carried out when new features have been added to the system? 是否存在系统的测试数据？在向系统添加新功能时, 是否有进行回归测试的记录？
Personnel skills 人员技能	Are there people available who have the skills to maintain the application? Are there people available who have experience with the system? 是否有具备维护应用程序技能的人员？是否有有使用该系统经验的人？

System measurement 系统度量

You may collect quantitative data to make an assessment of the quality of the application system 您可以收集定量数据, 对申请系统的质量进行评估

• The number of system change requests; 系统更改请求的数量
• The number of different user interfaces used by the system; 系统使用的不同用户界面的数量
• The volume of data used by the system. 系统使用的数据量。