软件工程基础-软件质量与其他

1. Software Quality

1.1. Desirable Software Quality(理想的软件质量)

• External characteristics： External characteristics are characteristics that a user of the software product is aware of
• Internal : developer directly experience

联系

The difference between internal and external characteristics isn’t completely clear-cut because at some level internal characteristics affect external ones. Software that isn’t internally understandable or maintainable impairs your ability to correct defects, which in turn affects the external characteristics of correctness and reliability. Software that isn’t flexible can’t be enhanced in response to user requests, which in turn affects the external characteristic of usability.

External characteristics：

• Correctness
  • 一个系统在其规格、设计和实现中没有错误的程度
• Usability
  • 用户学习和使用一个系统的容易程度
• Efficiency
  • 对系统资源的最小化使用，包括内存和执行时间
• Reliability
  • 一个系统在规定的条件下，无论何时都能执行所需功能的能力–具有较长的平均故障间隔时间( a long mean time between failures)
• Integrity
  • 完整性的概念包括限制未经授权的用户访问，以及确保数据被正确访问
• Adaptability
  • 一个系统在没有修改的情况下，可以在其专门设计之外的应用或环境中使用的程度
• Accuracy
  • 精确性与正确性不同；它决定了一个系统在多大程度上完成了它所构建的工作(而不是关注错误)
• Robustness
  • 一个系统在无效的输入或紧张的环境条件下继续运行的程度

internal quality characteristics：

• Maintainability
  • 你可以修改一个软件系统以改变或增加功能、提高性能或纠正缺陷的容易程度

    The ease with which you can modify a software system to change or add capabilities, improve performance, or correct defects

• Flexibility
  • 可以修改一个系统的用途或环境的程度，而不是它的专门设计
• Portability
  • 你可以修改一个系统以在不同于其专门设计的环境中运行的容易程度
• Reusability
  • 你可以在其他系统中使用一个系统的部分的程度和容易程度
• Readability
  • 你能够阅读和理解一个系统的源代码的难易程度
• Testability
  • 你可以对一个系统进行单元测试和系统测试的程度；你可以验证该系统满足其要求的程度
• Understandability
  • 在系统-组织和详细陈述层面上，你能理解一个系统的难易程度。与可读性相比，可理解性与系统在更一般的层面上的一致性有关
  • Readability is part of understandability. But you can have readable methods or functions and an impossible to grasp architecture

---

• 最大化某些特征的尝试不可避免地与最大化其他特征的尝试相冲突。从一组相互竞争的目标中找到一个最佳解决方案，是使软件开发成为真正的工程学科的一项活动。
• 专注于一个特定的特征并不总是意味着要与另一个特征进行交换。有时一个会伤害另一个，有时会帮助另一个，有时既不伤害也不帮助另一个 Focusing on one external characteristic of software quality can affect other characteristics positively, adversely, or not at all

1.2. Techniques for Improving Software Quality（提高软件质量的方法）

1.2.1. Setting Objectives

One powerful technique for improving software quality is setting explicit quality objectives from among the external and internal characteristics described in the previous section

Explicit quality-assurance activity.

• Making the quality-assurance activity explicit makes the priority clear, and programmers will respond accordingly.

1.2.2. Development Process

• Change-control procedures
  • One big obstacle to achieving software quality is uncontrolled changes. Uncontrolled requirements changes can result in disruption to design and coding. Uncontrolled changes in design can result in code that doesn’t agree with its requirements, inconsistencies in the code, or more time spent modifying code to meet the changing design than spent moving the project forward. 实现软件质量的一个大障碍就是不受控制的变更。不受控制的需求变更会导致设计和编码的中断。不受控制的设计变更会导致代码与需求不一致，代码中的不一致，或者花在修改代码以满足不断变化的设计上的时间比花在推进项目上的时间多
• Measurement of results
  • 除非对质量保证计划的结果进行测量，否则你将无法知道该计划是否有效
• Prototyping
  • Prototyping is the development of realistic models of a system’s key functions. A developer can prototype parts of a user interface to determine usability, critical calculations to determine execution time, or typical data sets to determine memory requirements. 原型验证是对系统关键功能的现实模型的开发。开发者可以对用户界面的一部分进行原型开发以确定可用性，对关键计算进行原型开发以确定执行时间，或对典型数据集进行原型开发以确定内存需求。

1.3. 不同质量保证的方法的有效性

这个数据所揭示的最有趣的事实是，任何一种技术的模态率都没有超过75%，各种技术平均约为40%。此外，对于最常见的缺陷检测–单元测试和集成测试–模式率只有30-35%。典型的组织使用重测试的缺陷清除方法，只能达到约85%的缺陷清除效率。领先的组织使用更广泛的技术，实现了95%或更高的缺陷清除效率。

如果项目开发人员要争取更高的缺陷发现率，他们需要使用多种技术组合（if project developers are striving for a higher defect detection rate, they need to use a combination of techniques）

Cost of Finding Defects发现漏洞的成本

• Most studies have found that inspections are cheaper than testing. A study at the Software Engineering Laboratory found that code reading detected about 80 percent more faults per hour than testing
  Cost of Fixing Defects
• the longer a defect remains in the system, the more expensive it becomes to remove. A detection technique that finds the error earlier therefore results in a lower cost of fixing it

Here’s a recommended combination for achieving higher-than-average quality:

• Formal inspections of all requirements, all architecture, and designs for critical parts of a system
• Modeling or prototyping
• Code reading or inspections
• Execution testing

1.4. When to Do Quality Assurance

the earlier an error is inserted into software, the more entangled it becomes in other parts of the software and the more expensive it becomes to remove.

• 一个错误越早插入软件，它在软件其他部分的纠缠就越多，消除它的代价就越大。需求中的错误会在设计中产生一个或多个相应的错误，而设计中的错误又会在代码中产生许多相应的错误。一个需求错误会导致额外的架构或错误的架构决策。额外的架构会导致额外的代码、测试用例和文档。或者一个需求错误会导致架构、代码和测试用例被丢弃
• Defects creep into software at all stages
  • 质量保证工作应当在每一构建环节都介入
  • It should be planned into the project as work begins;
  • it should be part of the technical fiber of the project as work continues;
  • and it should punctuate the end of the project, verifying the quality of the product as work ends.

1.5. The General Principle of Software Quality

The General Principle of Software Quality is that improving quality reduces development costs.

• 这个原则本质上也是个“悖论”paradox
• 提高生产力和质量的最好方法是减少代码返工的时间，无论返工是由于需求的变化、设计的变化还是调试的变化
• Compared to the traditional code-test-debug cycle, an enlightened software-quality program saves money

the best way to improve productivity and quality is to reduce the time spent reworking code, whether the rework arises from changes in requirements, changes in design, or debugging. The industry-average productivity for a software product is about 10 to 50 of lines of delivered code per person per day (including all noncoding overhead). It takes only a matter of minutes to type in 10 to 50 lines of code

• 你是否考虑过一些特性可能与其他特性竞争或互补的方式？

1.6. key points

1. Quality is free, in the end, but it requires a reallocation of resources so that defects are prevented cheaply instead of fixed expensively.
2. Not all quality-assurance goals are simultaneously achievable. Explicitly decide which goals you want to achieve, and communicate the goals to other people on your team.
3. No single defect-detection technique is completely effective by itself. Testing by itself is not optimally effective at removing errors. Successful quality-assurance programs use several different techniques to detect different kinds of errors.
4. You can apply effective techniques during construction and many equally powerful techniques before construction. The earlier you find a defect, the less intertwined it will become with the rest of your code and the less damage it will cause.
5. Quality assurance in the software arena is process-oriented. Software development doesn’t have a repetitive phase that affects the final product like manufacturing does, so the quality of the result is controlled by the process used to develop the software.

---

2. Intellectual Property 知识产权

Intellectual property is any articulable, tangible production of a mind whose physical realisations are restricted by law (e.g., in distribution)

知识产权是任何可阐明的、有形的思想成果，其物质实现受到法律的限制（例如，在分销方面）。

---

Copyright is a licensable monopoly of the tangible expression of an idea with respect to reproduction, derivation, display，distribution, and the like.

版权是对思想的有形表达在复制、衍生、展示、传播等方面的一种可授权的垄断。

3. 程序等价

• 如果我们无法区分两个程序（在某种程度上），那么这两个程序就是等价的（以这种方式）。
• Two programs are functionally equivalent just in case they implement exactly the same functionality.
• if two programs are behaviourly equivalent then they are functionally equivalent.
• 这里将等价性定义为“给定相同合法输入，有相同输出”

4. Managing Construction

4.1. Key Points

1. Good coding practices can be achieved either through enforced standards or through more light-handed approaches.
   1. Encouraging Good Coding
2. Configuration management, when properly applied, makes programmers’ jobs easier. This especially includes change control.
   1. Configuration management is the practice of identifying project artifacts and handling changes systematically so that a system can maintain its integrity over time. Another name for it is “change control.” It includes techniques for evaluating proposed changes, tracking changes, and keeping copies of the system as it existed at various points in time.
   2. Software Code Changes、Tool Versions、Machine Configurations、Backup
3. Good software estimation is a significant challenge. Keys to success are using multiple approaches, tightening down your estimates as you work your way into the project, and making use of data to create the estimates.
   1. Use estimating software、algorithmic approach、Have a walk-through meeting for estimates
4. Measurement is a key to successful construction management. You can find ways to measure any aspect of a project that are better than not measuring it at all. Accurate measurement is a key to accurate scheduling, to quality control, and to improving your development process.
5. Programmers and managers are people, and they work best when treated as such

5. character

1. our personal character directly affects your ability to write computer programs.
2. The characteristics that matter most are humility, curiosity, intellectual honesty, creativity and discipline, and enlightened laziness.
3. The characteristics of a superior programmer have almost nothing to do with talent and everything to do with a commitment to personal development.
4. Surprisingly, raw intelligence, experience, persistence, and guts hurt as much as they help.
5. Many programmers don’t actively seek new information and techniques and instead rely on accidental, on-the-job exposure to new information. If you devote a small percentage of your time to reading and learning about programming, after a few months or years you’ll dramatically distinguish yourself from the programming mainstream.
6. Good character is mainly a matter of having the right habits. To be a great programmer, develop the right habits and the rest will come naturally.

6. 开发成本

• The unit cost diminishes as the number of units increases
  • So focus on lines of code or bits of functionality
• Cost Ratios
  • Before deployment (aka submission)
    • Small fixes are cheap
  • After deployment (aka submission)
    • Even “small” fixes are expensive (or impossible)
  • Strategies
    • Avoid late bugs
    • Make fixing late bugs cheaper
• The General Principle of Software Quality is that improving quality reduces development costs

6.1. Trade-Offs

• Time for Space (and the reverse)
• Performance for Readability (and the reverse)

6.2. Alternatives

• Buy More and Faster Hardware
• Use the Optimiser
• Better compilers/frameworks/libraries

6.3. Technical Debt

In software development, technical debt (also known as design debt or code debt) is the implied** cost of additional rework** caused by choosing an easy(limited) solution now instead of using a better approach that would take longer

技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是程序设计及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

• 如果我们等待，就会产生利息
  • 我们写的测试越多，以后要改的测试就越多
  • 可能会导致更对债务

Intentional Vs Unintentional Debt
无意的债务==意外的或偶然的

• 我们可能不知道我们产生了它!
• 我们可能不知道有利息！
  故意的债务 == 故意的，有意识地产生的
• 需要一个可识别的理由（identifiable rationale）
• 有一个范围

为什么负债

• Short-Term Debt

  • 战术原因 Tactical reasons

• Long-Term Debt

  • 战略原因 Strategic reasons

• 重构是还债最常见的方式

• 其余还包括增加测试用例等

7. Managing Complexity

7.1. No silver bullet

The complexities of software systems lead to difficulties in both accident and essence. According to Brooks, the accidental complexities are largely caused by artificial barriers, including poor programming skills, severe hardware constraints and lack of machine time. On the contrary, the essential complexities, inherent in the nature of the software, are reflected by the hardship of composing the abstract software entity, including specification, design and testing of the conceptual construct, rather than the labour of actual construction.

What is highlighted in Brooks’ essay is that no once-and-for-all solution to remove the complexity of the software, thus “no silver bullet”. From the aspect of accidental complexities, although problems can be considerably alleviated by the high-level language, time-sharing and unified programming environment, it is impossible to avoid “accidents”, particularly when products increase with size. From the aspect of accidental complexities, the inherent properties of modern software systems determine the difficulty of finding a solution, as technologies that are advanced as potential “silver bullet” yet mostly remain problem-specific. An artificial intelligence implement of computer images, for example, cannot easily transfer to different programming practices.

However, there are some promising attacks, raised by Brooks, on the conceptual essence. These contain the principles of buy rather than build, rapid prototyping of system and cautious design.

In general, considering the shrinking marginal benefit of reducing accidents, and the inherent complexity of software systems, finding “silver bullets” to minimize complexity remains challenging yet possible.

---

Brooks observes that the major accidental difficulties in software were addressed long ago. For example, accidental difficulties related to clumsy language syntaxes were largely eliminated in the evolution from assembly language to third-generation languages and have declined in significance incrementally since then. Accidental difficulties related to noninteractive computers were resolved when time-share operating systems replaced batch-mode systems. Integrated programming environments further eliminated inefficiencies in programming work arising from tools that worked poorly together.

Brooks argues that progress on software’s remaining essential difficulties is bound to be slower. The reason is that, at its essence, software development consists of working out all the details of a highly intricate, interlocking set of concepts. The essential difficulties arise from the necessity of interfacing with the complex, disorderly real world; accurately and completely identifying the dependencies and exception cases; designing solutions that can’t be just approximately correct but that must be exactly correct; and so on. Even if we could invent a programming language that used the same terminology as the real-world problem we’re trying to solve, programming would still be difficult because of the challenge in determining precisely how the real world works. As software addresses ever-larger real-world problems, the interactions among the real-world entities become increasingly intricate, and that in turn increases the essential difficulty of the software solutions.

The root of all these essential difficulties is complexity—both accidental and essential.

7.2. Importance of Managing Complexity

• Projects fail most often because of poor requirements, poor planning, or poor management. But when projects do fail for reasons that are primarily technical, the reason is often uncontrolled complexity. The software is allowed to grow so complex that no one really knows what it does. When a project reaches the point at which no one completely understands the impact that code changes in one area will have on other areas, progress grinds to a halt.
• no one’s skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn’t try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time.
• Keeping routines short helps reduce your mental workload. Writing programs in terms of the problem domain, rather than in terms of low-level implementation details, and working at the highest level of abstraction reduce the load on your brain.

7.3. How to Attack Complexity

• Minimize the amount of essential complexity that anyone’s brain has to deal with at any one time
  • 尽量减少任何人的大脑在任何时候都必须处理的基本复杂性。
• Keep accidental complexity from needlessly proliferating
  • 防止意外的复杂性不必要地扩散

8. Architecting: How Much and When?

8.1. the Cost of Fixing Software

8.2. How Much Architecting Is Enough

The evidence provided across 40 years of data on the degree of increase in software cost-to-fix versus delay-of-fix is that for large projects, the increase from fixing requirements changes and defects during requirements definition to fixing them once the product is fielded continues to be around 100:1. However, this ratio can be significantly reduced by higher investments in early requirements and architecture verification and validation. As shown by the CCPDS-R project data in Figure 10-6, the ratio can approach 1:1 if the high-risk fixes are addressed early.
The evidence for small projects continues to show ratios around 5:1, but these can also be flattened by the use of outstanding personnel and by Agile methods, such as pair programming and continuous integration, that shorten the delay-of-fix time. Small, noncritical projects can also spread their architecting activity across the life cycle via refactoring, but need to watch out for making easiest-first architectural commitments that cannot be easily undone by refactoring, such as committing to unscalable COTS products or security-incompatible data and control structures.
The evidence provided more recently on the payoff of architecting and risk resolution efforts, such as those on CCPDS-R, is that the location of the highest-payoff “how much architecting is enough” sweet spot is a function of project size and criticality (larger, more critical projects require more architecting investment), but also a function of requirements volatility (more volatile projects would be slowed down by the need to revise extensive documentation). For detailed project planning and budgeting, the sweet-spot numbers need to be adjusted to reflect additional project, personnel, and product-related cost drivers. A recent COSYSMO model is now available to support such adjustments.
Very large projects are likely to have elements that are high in criticality and stability (e.g., safety and security-critical elements), as well as elements that are high in requirements volatility (e.g., user interfaces, external-system interfaces, device drivers, database schemas). In such cases, a hybrid approach using Agile methods for the rapidly changing parts and plandriven methods for the more stable and high-criticality parts will work, as long as the overall system is based on an architecture using the [Parnas 1979] information-hiding approach of encapsulating sources of change within modules.
Thus, there are no one-size-fits-all solutions for the increasingly rapid change that projects will experience in the future. Large projects or enterprises with a mix of critical and volatile elements are best served by risk-driven process generators, such as the Incremental Commitment Model and risk-driven versions of the Rational Unified Process. These model generators use the degree of developer-supplied evidence of project feasibility to determine project risk. Such evidence is critical to the success of many future projects facing the prospect of having to cope with increasing size, criticality, volatility, and complexity. In addition, the use of such evidence-based models will have the double benefit of reducing risk and adding to the knowledge base of evidence that can be analyzed for further sources of project and enterprise improvement.