发布时间 : 星期一 文章软件工程专业软件质量中英文资料外文翻译文献更新完毕开始阅读6dba80d5453610661fd9f491
外文翻译文献
软件工程专业软件质量中英文资料外文翻译文献
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
1
外文翻译文献
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
2
外文翻译文献
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,
3
外文翻译文献
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 won’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
4