软件工程专业软件质量中英文资料外文翻译文献

软件工程专业软件质量中英文资料外文翻译文献

Planning for Software Quality

In this Chapter: Defining quality in software projects, working with your organization’s quality policy, Creating a quality management plan, Identifying how changes in time and cost will affect project quality.

When it comes to quality, you’ve probably heard some great clichés: quality is planned into a project, not added through inspection(you should spend your time in planning quality instead of inspecting after you have errors).It’s always cheaper(and more efficient) to do a job right the first time around. Why is there always time to do work right the second time? Always underpromise and overdeliver.

There sure are some catchy slogans, and clichés become clichés because they’re usually accurate. In this chapter we explore what quality is , how to plan it into your project, and how to create a quality management plan.

6.1 Defining Quality

Before you can plan for quality, you must first define what quality is. Ask your customers, your project team, your management team, and even yourself what quality is and you get a variety of answers:

What customers say: The software you create lives up to expectations, is reliable, and does some incredible things the customer doesn’t expect(or even think of ).

What your project team says: The work is completed as planned and as expected, with few errors- and fewer surprises.

What managers say: The customer is happy and the project delivers on time and on budget.

What you may say: The project team completes its work according to its estimates, the customer is happy, and management is happy with the final costs and

schedule.

Quality, for everyone concerned, is the ability of the project and the project’s deliverable to satisfy the stated and implied requirement. Quality is all of items we mention here, but it’s more than just the deliverable; it’s following a process, meeting specified requirements, and performing to create the best possible deliverable. Everything, from the project kickoff meeting to the final testing, affects the project quality.

6.2 Referring to the product scope

As the project manager, you primary concern is satisfying the product scope. The product scope is the description of the software the customer expects from your project.

If you work primarily to satisfy the product scope, then you’ll be in good shape with satisfying the customer’s expectations for quality. But, in order to satisfy the product scope you must first have several documents:

Product scope description document. This document defines what the customer expects from the project. What are the characteristics of the software? This description becomes more complete as you progress through the project and gather more knowledge.

Project requirements document. This document defines exactly what the project must create without being deemed a failure. What types of functionality should stakeholders be able to perform with the software? This document prioritizes the stakeholders’ requirements.

Detailed design document. This document specifies how the project team will create units that meet the project requirements, which in turn will satisfy the product scope.

Metrics for acceptability. Many software projects need metrics for acceptability. These metrics include speeds, data accuracy, and metrics from user acceptability tests. You’ll need to avoid vague metrics, such as good and fast. Instead, aim to define accurate numbers and determine how the values will be captured.

Satisfying the product scope will assure that the customer is happy with you and with deliverables the project team has created. You will only satisfy the product scope if you plan how to do it. Quality is no accident.

6.3 Referring to the project scope

The project scope defines all of the work(and only the required work ) to create

the project deliverable. The project scope defines what will and won’t be included in the project deliverable. Project scope is different than the product scope, because the product scope describes only the finished deliverable, whereas the project scope describes the work and activities needed to reach the deliverable.

You must define the project scope so that you use it as an appropriate quality tool. The project scope draws a line in the sand when it comes to project changes. Changes, as we’re sure you’ve experienced, can trickle into the project and cause problems with quality. Even the most innocent changes can bloom into monsters that wreck your project.

Figure 6-1 shows the project manager’s approach to project changes and quality. Early in the project, during the initiation and planning stages, you safely entertain changes to the project. After you create the project scope, however, your rule when it comes to changes should be “Just say no!”

Changes to the project may affect the quality of the product. This isn’t to say that changes should come into a project at all- far from it. But changes to the project must be examined, weighed, and considered for the affect on time, cost, and impact on project quality.

6.3.1 Going the extra mile

One cliché that rings true is that it’s always better to underpromise and overdiliver. We’ve heard project managers tell us this is their approach to keep people happy. It sounds good, right? A customer asks for a piece of software that can communicate with a database through a Web form. Your project team, however, creates a piece of software that can communicate through a Web form to the customer’s database, and you add lots of query combinations for each table in the database. Fantastic!

A valid argument can be made that you should never underpromise, but promise what you can deliver and live up to those promises. Technically, in project management, quality is achieved by meeting the customer’s expectations-not more than they expect, and certainly not less than they expect.

Surprising the customer with more than the project scope outlines can actually backfire, for the following reasons: The customer may believe the project deliverable could have been completed faster without all the extras you’ve included. The customer may believe the project deliverable could have been completed for fewer dollars without all the extras you’ve included. If the customer discovers bugs in the software, the blame may lie with the extras. The customer may not want the extras,

regardless of how ingenious you believe they are. Overdelivering is not meeting expectations: you’re not giving the customer what he or she asked for.

Now, Having put the wet blanket on the fire of creativity, let us say this: communicate. We can’t emphasize enough how important it is to tell the customer what you can do, even if it’s more than what the customer has originally asked for. In software development, customers may need guidance on what each deliverable can do, and they look to you as the expert to help them make those decisions. But notice this process is done before the project execution begins, not during the implementation phase.

The product scope and the project scope support one another. If the customer changes details in the product scope will also change. If not, then your project team will be completing a project scope that wo n’t create what the customer expects.

Avoiding gold- plated software

You create gold-plated software when you complete a project, and the software is ready to go the customer, but suddenly realize that you have money to burn. If you find yourself with a hefty sum of cash remaining in the project budget, you may feel tempted to fix the situation with a lot of bling. After all, if you give the project deliverable to the customer exactly as planned, several things may happen: You customer may be initially happy that you’ve delivered underbudget. Then they’ll wonder whether you cut corners or just didn’t have a clue as to the actual cost of the project. The customer may wonder why your estimate and the actual cost of the project deliverable are not in sync. The remaining budget will be returned to the customer unless your contract stipulates otherwise. Other project managers may not be happy that you’ve created a massive, unused project budget when their projects have been strapped for cash. Key stakeholders may lose confidence in your future estimates and believe them to be bloated, padded, or fudged.

This is , in case you haven’t guessed, a bad thing. The best thing to do is to deliver an accurate estimate to begin with and avoid this scenario altogether. We discuss time estimates in Chapter 8 and cost estimates in Chapter 9. For now, know that your customer’s confidence in future estimates is always measured on your ability to provide accurate estimates at the beginning of the process.

If you find yourself in the scenario where you have a considerable amount of cash left in the project budget, the best thing to do is to give an accurate assessment to the customer of what you’ve accomplished in the project and what’s left

in the kitty. Don’t eat up the budget with extras, and don’t beat yourself up over it. Mistakes happen, especially to beginners, and it’s still more forgivable to be underbudget than it is to be overbudget.

So should you also present extras to the customer when you present the project’s status and the remaining budget? If the extras are value-added scope changes, we say yes. If the extras are truly gold-plated extras to earn more dollars, then we say no. Software quality is based on whether the product delivers on its promises. If the proposed changes don’t make the software better, no one needs them.

What you do on your current project may influence what you get to do on future projects. Honesty now pays dividends later.

6.4 Examining quality versus grade

Quality and grade are not the same thing. Low quality is always a problem, but low grade may not be. Quality, as you know, is the ability of software to deliver on its promises. Grade is the ranking or classification we assign to things.

Consider your next flight. You expect the airplane to safely launch, fly, and land. And you expect to be reasonably comfortable during the flight. You expect the behavior of the crew and fellow passengers to be relatively considerate, even if they’re a little cramped and annoyed. (You have to factor in that crying baby three rows back. It’s not the baby’s fault, after all.)

Now consider were you’re seated on the airplane. Are you in first class or coach? That’s the grade!

Within software developments we also have grades and quality issues.

A quick, cheap software fix may be considered low grade, but it can still be a high-quality software solution because it satisfies the scope of the simple project. On the other hand, the rinky-dink approach won’t work during the development of a program to track financial data through e-ecommerce solutions for an international company.

During the planning process, one goal of stakeholder analysis is to determine the requirements for quality and grade.

6.5 Working with a Quality policy

A quality policy isn’t a policy that’s “real good.”A quality policy is an organization-wide policy that dictates how your organization will plan, manage, and then control quality in all projects. This policy sets the expectations for your projects, and everyone else’s, for metrics of acceptability.

Quality policies fall under the big umbrella of quality assurance. QA is an organization-wide program, the goal of which is to improve quality and to prevent mistakes.

So who decides what quality is and what’s bunk? You might guess and say the customer, which to some extent is true, but generally the quality policy is set by management. The quality policy can be written by the geniuses within your organization, or your organization may follow a quality system and the proved quality approaches within these systems. For example, your company might participate in any number of proprietary and nonproprietary organizations, thereby pledging to adhere to their quality policies. The following sections discuss a few of them.

Working ISO programs

The International Organization for Standardization(ISO) is a world wide body with

153 members that convenes in Geneva, Switzerland. The goal of the ISO is to set compatibility standards for all industries, to establish common ground, and to maintain interoperability between businesses, countries, and devices.

In case you’re wondering, the abbreviation for the international Organization for Standardization is ISO, not IOS. This is because of all the different countries represented and the varying languages; they decided to use the abbreviation of ISO taken form the Greek isos, which means equal.

There are many different ISO programs, but the most popular is ISO 9000. An ISO 9000-certified organization focuses on business-to-business dealing and striving to ensure customer satisfaction. An ISO 9000-certified organization must ensure that it: Establishes and meets the customer’s quality requirements. Adheres to applicable regulatory requirements. Achieves customer satisfaction throughout the project. Takes internal measures to continually improve performance, not just once.

You can learn more about ISO programs and how your organization canparticipate by visiting their Web site: https://www.360docs.net/doc/6d16246579.html,.

Visit these Web sites for more assistance with quality management:

https://www.360docs.net/doc/6d16246579.html,

https://www.360docs.net/doc/6d16246579.html,

https://www.360docs.net/doc/6d16246579.html,

Getting a total Quality Management workout

The U.S. Naval Air Systems Command originated the term Total Quality

Management as a means of describing the Japanese-style management approach to quality

improvement.

TQM requires that all members of an organization contribute to quality improvements in products, services, and the work culture. The idea is that if everyone is involved in quality and works to make the total environment better, then the services and products of the organization will continue to improve.

In software development, TQM means that the entire team works to make the development of the software better, the process from start to completion better, and the deliverable better as well. TQM is largely based on W.Edwards Deming’s 14 Points for Quality. Here’s how Deming’s 14 points and TQM are specifically applicable to software development(you can find out more about W.Edwards Deming in the nearby sidebar, “W.Edwards Deming and the software project manager”):

Create constancy of purpose for improving products and services. Every developer must agree and actively pursue quality in all of his or her software creation, testing, and development.

Adopt the new philosophy. This philosophy can’t be a fad. The software project manager has to constantly motivate the project team to work towards quality.

Cease dependence on inspection to achieve quality. Software development has tradition of coding and inspection, and then reacting to errors. This model is dangerous because developers begin to lean on the testing phase to catch errors, rather than striving to incorporate quality into the development phase. As a rule, quality should be planned into software design, never inspected in.

End the practice of awarding business on price alone; instead, minimize total cost by working with a single supplier. The idea here is that a relationship will foster a commitment to quality between you and the supplier that’s a bit more substantial than an invoice and a check.

Constantly strive to improve every process for planning, production, and service. Quality planning and delivery is an iterative process.

Institute training on the job. If your software developers don’t know how to develop, they’ll certainly create some lousy software. If your team doesn’t know how to do something, you must train them.

Adopt and institute leadership. The project manager must identify how to lead

and motivate the project team, or the team may lead itself, remaining stagnant.

Drive out fear. Are your software developers afraid of you? If so, how can they approach you with ideas for quality improvements, news on development, and flaws they’ve identified within the software? Fear does nothing to improve quality.

为软件质量制定计划

在这一章中我们将讨论：在软件工程中为质量下定义，遵循你所在团队的质量方针，

创造一个质量管理计划，弄清楚时间和成本上的变化会对软件质量有何影响。

当谈到质量的时候，你非常有可能听到一些陈词滥调：质量要被预先计划到项目中，

而不是由检测来完成（你应在质量计划上花时间而不是发现错误后再检测）。在第一次

就把工作做好往往是更加划算的（和更有效的）。为什么总要第二次才能把工作做好呢？

总要谨慎承诺并给他人意外的收获。

这些的确是一些好听的口号和陈词滥调，因为这些话总是很正确的。在这一章中我

们要探索什么是质量，怎么把计划加入到项目里，和怎样制定一个质量管理计划。

6.1 为质量下定义

在你能对质量作计划之前，你必须先定义质量是什么。咨询你的顾客，你的项目小

组，你的管理小组，甚至你自己什么是质量然后你会得到很多答案：

顾客会说：你们创造的软件完成了我们的期望，这一点是可信赖的，但也确实给我

们顾客带来了一些不可思议的事情（或从没料到的事情）。

项目组会说：工作正如所计划和期望的一样完成了，只是有一点小错误――和少许

的惊讶。

项目经理会说：顾客很高兴并且项目在预算内如期交付。

你也许会说：项目组根据评估完成了工作，顾客很高兴，并且经理对最终成本和进

度也很满意。

质量为每个人所关心，是项目和项目交付能否满足规定的和指定的需求的一种能力

上的判断。质量是我们在这一直讨论的东西，但是它不仅仅是交付；它通过一个过程，满足了制定的需求，并且能够创造出最可行的交付。从项目开始的会议到最终的测试，每一件事情都影响了项目的质量。

6.2 对产品范围作参考

作为项目经理，你主要关心的是去满足产品范围。所谓产品范围是指对于顾客所期

待的软件的描述。

如果你的工作主要是满足产品范围，那么你就要努力满足顾客对质量的期望。但是，

为了满足产品范围，你必须首先要有一些文档：

产品范围描述文档。这个文档定义了顾客从项目里期望得到什么。这个软件有

什么特征？这个描述会变得更加完整，随着项目的逐渐完成和对项目更多的了解。

项目需求文档。这个文档准确地定义了为了不使项目被认为是个失败品而必须

被创造的东西。用户能够使用软件的哪些功能？这个文档优先描述了用户的需求。

详细设计文档。这个文档详细地描述了项目组该如何创建各个模块来满足项目

需求，这反过来也同样能满足产品范围。

衡量标准要有可接受性。很多的软件工程项目都需要可让人接受的度量标准。

这些度量包括速度，数据准确性，以及从用户的可接受性测试得来的度量。你需要避免

那些糊不清的度量，如好和快。并且，把目标定位在定义精确的数字和如何获取这些值。

满足产品范围会确保顾客对你和项目组的最后交付很满意。如果你打算去做什么的

话，那你只需要满足产品范围就可以了。质量是不会出意外的。

6.3 对项目范围作参考

项目范围定义了所有可以使得项目交付的工作（以及必要的工作）。项目范围定义

了项目交付包括什么和不包括什么。项目范围和产品范围是不同的，因为产品范围只描

述了完成的可交付性，但是项目范围却描述了满足交付需要的工作和活动。

你真的需要把项目范围写下来，并且让项目经理和项目保证人签字。对于一些项目，

比如国内的项目，其他的股东也许需要在项目范围上达成一致。对于那些在组织外完成

的项目，那些项目范围也要写下来（SOW），并且包含在合同条款里。

你必须定义项目范围，这样你也能够用它作为一个合适的质量工具。当项目有变时，

项目范围也会使得条理很清晰。我们确信你一定经历过项目中的变化并且导致了质量问

题。甚至最微小的改变都能成长为庞大的怪兽进而把系统摧毁。

图表6-1显示了项目经理如何处理项目变化和项目质量的。在项目早期，初始和计

划阶段，你能安全地应变各种项目上的变化。但是在你创建完项目范围后，你就只能对

一切项目变化说不。

项目上的变化可能会影响项目的质量。这并不是说要让变化远离项目，但是项目上