外文翻译8为软件质量制定计划Word文件下载.docx

1、 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）.Its 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? Alwa

2、ys underpromise and overdeliver.There sure are some catchy slogans, and clichs become clichs because theyre 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 QualityBefore you can plan for quality

3、, 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 do

4、esnt 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

5、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 projects deliverable to satisfy the stated and implied requirement. Quality is all of items we mention here, but its more than ju

6、st the deliverable; its 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 scopeAs the project manager, you primary co

7、ncern 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 youll be in good shape with satisfying the customers expectations for quality. But, in order to satisfy the prod

8、uct 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.Pro

9、ject 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

10、 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.

11、 Youll 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

12、product scope if you plan how to do it. Quality is no accident.6.3 Referring to the project scopeThe project scope defines all of the work（and only the required work ） to create the project deliverable. The project scope defines what will and wont be included in the project deliverable. Project scop

13、e 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

14、 draws a line in the sand when it comes to project changes. Changes, as were sure youve 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 managers approach to project

15、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. Thi

16、s isnt 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 mileOne clich that rings true is that its always better to underpromise an

17、d overdiliver. Weve 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

18、 a Web form to the customers 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 achi

19、eved by meeting the customers 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

20、 faster without all the extras youve included. The customer may believe the project deliverable could have been completed for fewer dollars without all the extras youve included. If the customer discovers bugs in the software, the blame may lie with the extras. The customer may not want the extras,

21、regardless of how ingenious you believe they are. Overdelivering is not meeting expectations: youre 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 cant emphasize enough how important it is to tell the custo

22、mer what you can do, even if its 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 execut

23、ion 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 wont create what the customer expects.Avoiding go

24、ld- plated softwareYou 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 wit

25、h 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 youve delivered underbudget. Then theyll wonder whether you cut corners or just didnt have a clue as to the actual cost of the proj

26、ect. 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 youve created a massive, unused project budget

27、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 havent guessed, a bad thing. The best thing to do is to deliver an accurate estimate to begin with and avoid this sc

28、enario altogether. We discuss time estimates in Chapter 8 and cost estimates in Chapter 9. For now, know that your customers 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

29、 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 youve accomplished in the project and whats left in the kitty. Dont eat up the budget with extras, and dont beat yourself up over it. Mistakes happen, especi

30、ally to beginners, and its 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 projects status and the remaining budget? If the extras are value-added scope changes, we say yes. If the extras are truly gold-plate

31、d 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 dont 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 cla