复制成功
  • 图案背景
  • 纯色背景
  •   |  注册
  • /
  • 批注本地保存成功,开通会员云端永久保存 去开通
  • 网上数字图..

    上传于:2015-05-31

    粉丝量:1171

    所发布亚博足球app下载来源于互联网和个人收集,仅用于分享交流和学习使用,请下载后于24小时内删除,版权为原作者所有,请支持购买原版。因上传亚博足球app下载受大小限制,部分亚博足球app下载拆分上传,请浏览确认后下载。如有侵犯您的版权,请通过站内信息告知,将立即删除相关资料.如有其它问题也欢迎联系,谢谢!

    

    计算机书籍 计算机书籍 Software Project Survival Guide

    下载积分:600

    内容提示: Here is Edward Bear, coming downstairs now, bump, bump, bump on theback of his head, behind Christopher Robin.It is, as far as he knows, the only way of coming downstairs,but sometimes he-feels that there really is another way,if only he could stop bumping for a moment and think of it.And then he feels that perhaps there isn't. Software Project Survival GuidePublished by Microsoft PressA Division of Microsoft CorporationOne Microsoft WayRedmond, Washington 98052-6399Copyright © 1998 by Steve McConn...

    亚博足球app下载格式:PDF| 浏览次数:6| 上传日期:2015-05-31 08:31:32| 亚博足球app下载星级:
    Here is Edward Bear, coming downstairs now, bump, bump, bump on theback of his head, behind Christopher Robin.It is, as far as he knows, the only way of coming downstairs,but sometimes he-feels that there really is another way,if only he could stop bumping for a moment and think of it.And then he feels that perhaps there isn't. Software Project Survival GuidePublished by Microsoft PressA Division of Microsoft CorporationOne Microsoft WayRedmond, Washington 98052-6399Copyright © 1998 by Steve McConnellAll rights reserved. No part of the contents of this book may be reproduced ortransmitted in any form or by any means without the written permission of the publisher.Library of Congress Cataloging-in-Publication DataMcConnell, Steve.Software Project Survival Guide: how to be sure your first important project isn't yourlast / Steve McConnell.p. cm.Includes index.ISBN 1-57231-621-71 Computer software—Development—Management. QA76.76.D47M394 1997005.1'06R'4--dc21 I. Title.97-37923CIPPrinted and bound in the United States of America.10 11 12 13 14 15 QMQM 2 1 0Distributed to the book trade in Canada by Penguin Books Canada Limited.A CIP catalogue record for this book is available from the British Library.Microsoft Press books are available through booksellers and distributors worldwide. Forfurther information about international editions, contact your local Microsoft Corpora-tion office Or contact Microsoft Press International directly at fax (425) 936-7329. Visitour Web site at mspress.microsoft.com.Microsoft, Microsoft Press, Visual Basic, Visual C++, Windows, and Windows NT areregistered trademarks of Microsoft Corporation. Java is a trademark of SunMicrosystems, Inc. Other product and company names mentioned herein may be thetrademarks of their respective owners.Frontispiece from WINNIE-THE-POOH by A.A. Milne, illustrated by E.H. Shepard.Copyright 1926 by E.P. Dutton, renewed 1954 by A.A. Milne. Used by permission ofDutton Children's Books, a division of Penguin Books USA Inc.Acquisitions Editor: David ClarkProject Editor: Victoria Thulman Acknowledgments Preliminary Survival Briefing viviiTHE SURVIVAL MIND-SET1 Welcome to Software Project Survival Training 32 Software Project Survival Test 113 Survival Concepts 194 Survival Skills 355 The Successful Project at a Glance 51SURVIVAL PREPARATIONS6 Hitting a Moving Target 737 Preliminary Planning 858 Requirements Development 1139 Quality Assurance 12510 Architecture 14311 Final Preparations 155SUCCEEDING BY STAGES12 Beginning-of-Stage Planning 17313 Detailed Design 18714 Construction 19915 System Testing 21516 Software Release 22117 End-of-Stage Wrap-Up 237MISSION ACCOMPLISHED18 Project History 24719 Survival Crib Notes 253Epilogue 261Notes 263Glossary 273Index 283 AcknowledgmentsAs an experiment, I posted draft chapters of this book on my Internet Website and invited readers to comment on them. Many people downloaded thechapters, and they contributed literally thousands of insightful review com-ments. The diversity of viewpoints was tremendous (bordering on over-whelming), and the book is more readable, cohesive, practical, and usefulas a result.Thanks first to the people who reviewed the whole manuscript. Thesepeople include Robert C. Burns (The Boeing Company), Lawrence Casey,Alan Brice Corwin (Process Builder), Thomas Duff, Mike Cargal, Pat Forman(Lynden), Manny Gatlin, Marc Gunter, Tom Hill, William Horn, GregHitchcock, Grant McLaughlin, Mike Morton, Matt Peloquin, David Roe,Steve Rinn, Andre Sintzoff, Matthew J. Slattery, and Beth Weiss.I am also grateful to the people who commented on significant sectionsof the book, including Ray Bernard (Ray Bernard Consulting and Design),Steven Black, Robert Brown, Jacob L. Cybulski, Tom Gilb, Dick Holland,Gerard Kilgallon, Art Kilner, Steve Kobb, Robert E. Lee, Pete Magsig, HankMeuret (Meuret Consulting), Al Noel, Karsten M. Self, Rob Thomsett, andGregory V, Wilson.Other people commented on one or more details of the manuscript,and I've listed those people where appropriate in the "Notes" section at theend of the book.It was a pleasure to see the staff at Microsoft Press transform the rawmaterial of my manuscript into finished form. Special thanks to VictoriaThulman, project editor, for her wonderful forbearance and resiliency inaccommodating an author who has opinions about every facet of book pro-duction. Thanks to Kim Eggleston for the book's spare, elegant design, andto the rest of the Microsoft Press staff, including David Clark, Abby Hall,Cheryl Penner, and Michael Victor.Thanks finally to my wife, Tammy, for her unmatchable moral supportand trademark good humor. (This is number three, so now you have to thinkof a new joke. Fa!)vi About two million people are working on about 300,000 softwareprojects in the United States at this time.1 Between one third and twothirds of those projects will exceed their schedule and budget targets beforethey are delivered. Of the most expensive software projects, about half willeventually be canceled for being out of control. Many more are canceled insubtle ways—they are left to wither on the vine, or their sponsors simplydeclare victory and leave the battlefield without any new software to showfor their trouble. Whether you're a senior manager, an executive, a softwareclient, a user representative, or a project leader, this book explains how toprevent your project from suffering these consequences.Software projects fail for one of two general reasons: the project teamlacks the knowledge to conduct a software project successfully, or the projectteam lacks the resolve to conduct a project effectively. This book cannot domuch about the lack of resolve, but it does contain much of the knowledgeneeded to conduct a software project successfully.The factors that make a software project successful are not especiallytechnical. Software projects are sometimes viewed as mysterious entities thatsurvive or perish based on the developers' success in chanting magic tech-nical incantations. When asked why they delivered a component two weekslate, developers say things like, "We had to implement a 32-bit thunkinglayer to interface with our OCX interface." Faced with explanations like that,it is no wonder that people without deep technical expertise feel powerlessto influence a software project's success.1. Source citations and notes about related topics can be found in the "Notes" section at theend of the book.vii Preliminary Survival BriefingThe message of the Software Project Survival Guide is that softwareprojects survive not because of detailed technical considerations like"thunking layers" but for much more mundane reasons. Software projectssucceed or fail based on how carefully they are planned and how deliber-ately they are executed. The vast majority of software projects can be run ina deterministic way that virtually assures success. If a project's stakehold-ers understand the major issues that determine project success, they canensure that their project reaches a successful conclusion. The person whokeeps a software project headed in the right direction can be a technicalmanager or an individual software developer—it can also be a top manager,a client, an investor, an end-user representative, or any other concernedparty.WHO SHOULD READ THIS BOOKThis book is for anyone who has a stake in a software project's outcome.TOP MANAGERS, EXECUTIVES, CLIENTS,INVESTORS, AND END-USER REPRESENTATIVESNonsoftware people are commonly given responsibility for overseeing thedevelopment of a software product. These people have backgrounds in sales,accounting, finance, law, engineering, or some other field. They might nothave any formal authority to direct the project, but they will still be heldaccountable for seeing that the project goes smoothly. At a minimum, theyare expected to sound an alarm if the project begins to go awry.If you're in this group, this book will provide you with a short, easilyreadable description of what a successful project looks like. It will give youmany ways to tell in advance whether the project is headed for failure orsuccess. It will also describe how to tell when no news is good news, whengood news is bad news, or when good news really is good news.PROJECT MANAGERSMany software project managers are thrust into management positions with-out any training specific to managing software projects. If you're in thisgroup, this book will help you master the key technical management skillsof requirements management, software project planning, project tracking,quality assurance, and change control.viii Preliminary Survival BriefingTECHNICAL LEADERS, PROFESSIONALDEVELOPERS, AND SELF-TAUGHT PROGRAMMERSIf you're an expert in technical details, you might not have had much exposureto the big-picture issues that project leaders need to focus on. In that case, youcan think of this book as an annotated project plan. By providing an overviewof a successful software project, this book will help you make the transitionfrom expert technician to effective project leader. You can use the plan describedin this book as a starting point, and you can tailor its strategies to the needsof your specific projects. If you've read Rapid Development, the first part of thisbook will be about half review for you. You might want to skim Chapters 1through 5, read the end of Chapter 5 carefully, skim Chapter 6, and then beginreading carefully again starting with Chapter 7.KINDS OF PROJECTS THIS BOOK COVERSThe plan will work for business systems, broad-distribution shrink-wrapsoftware, vertical market systems, scientific systems, and similar programs.It is designed for use on desktop client/server projects using modern develop-ment practices such as object-oriented design and programming. It can easilybe adapted for projects using traditional development practices and main-frame computers. The plan has been designed with project team sizes of3 to 25 team members and schedules of 3 to 18 months in mind. These areconsidered to be medium-sized projects. If your project is smaller you canscale back some of this book's recommended practices. (Throughout the book,I point out places you can do that.)This book is primarily intended for projects that are currently in theplanning stages. If you're at the beginning of the project, you can use theapproach as the basis for your project plan. If you're in the middle of a project,the Survival Test in Chapter 2 and the Survival Checks at the end of eachchapter will help you determine your project's chance of success.By itself, this book's plan is not formal or rigorous enough to supportlife-critical or safety-critical systems. It is appropriate for commercial appli-cations and business software, and it is a marked improvement over manyof the plans currently in use on multimillion-dollar projects.A NOTE TO ADVANCED TECHNICAL READERSThe Software Project Survival Guide describes one effective way to conduct asoftware project. It'is not the only effective way to run a project, and for anyix Preliminary Survival Briefingspecific project it might not be the optimum way. The extremely knowledge-able technical leader will usually be able to come up with a better, fuller,more customized development plan than the generic one described here. Butthe plan described here will work much better than a hastily thrown togetherplan or no plan at all, and no plan at all is the most common alternative.The plan described in the following chapters has been crafted to addressthe most common weaknesses that software projects face. It is loosely basedon the "key process areas" identified by the Software Engineering Institute(SEI) in Level 2 of the SEI Capability Maturity Model. The SEI has identifiedthese key processes as the critical factors that enable organizations to meettheir schedule, budget, quality, and other targets. About 85 percent of allorganizations perform below Level 2, and this plan will support dramaticimprovements in those organizations. The SEI has defined the key processareas of Level 2 as follows:Project planningRequirements managementProject tracking and oversightConfiguration managementQuality assuranceSubcontract managementThis book addresses all of these areas except subcontract management.THIS BOOK'S FOUNDATIONIn writing this book, I have kept three primary references at my elbow thathave been invaluable resources, in addition to the many other resources I'vedrawn from. I've tried to condense the contents of these three references andpresent them in the most useful way that I can.The first reference is the Software Engineering Institute's Key Practicesof the Capability Maturity Model, Version 1.1. This book is a gold mine of hard-won industry experience in prioritizing implementation of new develop-ment practices. At almost 500 pages it is somewhat long, and even at thatlength the information is still dense. It is not a tutorial and so is not intendedfor the novice reader. But for someone who has a basic understanding of thepractices it describes, the summary and structure that Key Practices providesX Preliminary Survival Briefingis a godsend. This book is available free on the Internet at http://www.sei.cmu.edu/or from the National Technical Information Service (NTIS)branch of the U.S. Department of Commerce in Springfield, Virginia.The second reference is the NASA Software Engineering Laboratory's(SEL's) Recommended Approach to Software Development, Revision 3. The SELwas the first organization to receive the IEEE Computer Society's ProcessAchievement Award. Many keys to the success of its process are describedin the Recommended Approach. Whereas the SEI's document describes a setof practices without showing how to apply them to a specific project, theRecommended Approach describes a structured sequence of practices. The twovolumes together form a complementary set. This book is also available freeon the Internet at http://fdd.gsfc.nasa.gov/seltext.himl.The final "book" at my elbow has been my own experience. I am writ-ing not as an academician who wants to create a perfect theoretical frame-work, but as a practitioner who wants to create a practical reference thatwill aid me in my work and my clients in theirs. The information drawntogether here will make it easier for me to plan and conduct my next projectand easier to explain its critical success factors to my clients. I hope it doesthe same for you.Steve McConnellBellevue, WashingtonAugust 1997xi Survival prospects for software projects areoften poor, but they do not need to be. The firststep in surviving a software project is being sureto begin the project in a civilized way. From thatstarting point, much more than mere survival ispossible. I The Survival Mind-SetOThe software user community expects software products to run for hourswithout crashing, executing millions of source code instructions with few orno errors. But the software development community expects far less fromits projects. Users and clients might complain if a project is delivered onemonth, three months, or six months late, if it's hard to use, or if it lacks a fewcritical functions. But if the bulk of the planned software product is deliv-ered at all—at any cost—ever—most software consumers will consider thatproject to be a success. We have suffered so many failed projects that the onlyoutcome we really consider to be a failure is total collapse.The upper echelons of the software industry have understood for manyvears what is needed to perform at a much higher level than is currentlypracticed. A successful project should be one that meets its cost, schedule,and quality goals within engineering tolerances and without padding itsschedule or budget. After detailed plans have been made, the current stateof the art supports meeting project goals within plus or minus 10 percent orbetter. This level of performance is currently within the reach of the averagesoftware project manager, and in many cases can be substantially influencedby project "outsiders"—upper managers, executives, clients, investors, andend-user representatives.As chief software engineer at Construx Software Builders, I have beenasked to review many failed projects. To the trained eye, the reasons for fail-ure are usually apparent. Failure of medium-size software projects (those with20,000-250,000 lines of source code) is almost always avoidable. Moreover, Ihave found that software projects can be optimized to meet any of severalgoals: shortest schedule, least cost, best quality, or any other goal. Not all ofthese goals can be achieved simultaneously, and the approach described in thisbook strikes a careful balance among these objectives so that a high-qualityproduct can be delivered according to an efficient schedule at moderate cost.ur standards for software product performance are unbelievablyexacting compared to our standards for software project performance.SURVIVAL NEEDSThe first step in software project survival is recognizing a software project'sessential survival needs. Abraham Maslow observed that human beingsrespond to a hierarchy of needs that involve a natural progression from4 1 Welcome to Software Project Survival Traininglower motives to higher ones. The lowest level needs are called "survivalneeds," because they address physical needs that must be satisfied for ahuman being to exist at all. The lower motives, which are illustrated in Fig-ure 1-1 as the motives below the dashed line, must be satisfied before we canprogress to the higher motives. Thus physiological needs for food, air, andwater must be satisfied before we can be motivated by the need for"belongingness" and love, self-esteem, or self-actualization.I have found—along with many software experts—that a similar hier-archy of needs applies to software projects. Software projects have a set of basicsurvival needs that must be satisfied before it becomes possible for the projectteam to focus effectively on the project's higher level needs. And the higherlevels of the pyramid are where dramatic improvements in quality and pro-ductivity take place.FIGURE 1-1 higher level needs can be addressed.Maslow's human need hierarchy. Lower level needs must be satisfied before5 I The Survival Mind-SetA project team must be satisfied that the project can be completed at all,for example, before it will begin to worry about whether it will be completedwithin plus or minus 10 percent of its schedule and budget targets. A projectteam must be capable of delivering software on time before it will becomecapable of optimizing a software project to meet an aggressive schedule witha limited budget—and advance the state of the art all at the same time.As Figure 1-2 illustrates, the needs of the software project hierarchy arenot exactly the same as the needs of individual project participants. A devel-oper, for example, will typically prioritize his or her individual self-esteemabove the need for healthy team dynamics. But the project typically has agreater need for healthy team dynamics than it has a need for the high self-esteem of individual team members.This book focuses on the lower levels of the software project need hi-erarchy, reaching into the higher levels mainly when a higher-level needmust be addressed before a lower-level need can be satisfied.FIGURE 1-2 mately the same as the needs of the project's participants.Software project need hierarchy. Needs of the project are only approxi-6 1 Welcome to Software Project Survival TrainingSURVIVAL RIGHTSA struggling project threatens each party's survival needs. The customerworries whether the project will be delivered too late to serve its intendedpurpose, delivered at prohibitive cost, or delivered at all. The managerworries whether the customer will cancel the project and make him look likea failure, or whether the developers are even capable of completing theproject. The developer worries whether she will lose her job or be forced tosacrifice hundreds of hours of leisure time to show she is committed to theproject. In each of these circumstances, the individuals retreat to the lowerlevels of the project need hierarchy—focusing on the safety need of meetingtheir personal promises. But this reaction causes the individuals to abandonthe higher levels of the pyramid that must be exercised to achieve top qualityand productivity.As Thomas Hobbes observed in the 17th century, life under mob ruleis solitary, poor, nasty, brutish, and short. Life on a poorly run softwareproject is solitary, poor, nasty, brutish, and hardly ever short enough. Thefirst step toward surviving a software project is for all parties to agree to treatone another in a civilized way. I've summarized some of the rules of civili-zation as they apply to software projects in the form of a "Customer's Billof Rights." (In some cases, the project will not have a customer per se. Inthose cases, these rights may belong to the product manager, marketingrepresentative, or end-user representative instead of the customer.)71. To set objectives for the project and have them followed2. To know how long the software project will take and how much it will cost3. To decide which features are in and which are out of the software4. To make reasonable changes to requirements throughout the course of theproject and to know the costs of making those changes5. To know the project's status clearly and confidently6. To be apprised regularly of risks that could affect cost, schedule, or quality,and to be provided with options for addressing potential problems7. To have ready access to project deliverables throughout the project I The Survival Mind-SetThe rights I'm most familiar with are the rights enumerated in theUnited States Bill of Rights. Those rights are not just "nice to have" but areessential to the operation of a representative democracy. Similarly, thesesoftware project rights do not just make a software project more enjoyable;they are required for it to work at all.Another software project concept aligned with the United States Bill ofRights is the assumption that one person's software project rights are anotherperson's software project responsibilities. We all enjoy the right to free speech,but the price we pay for that right is tolerating other people's right to freespeech, even when we disagree with what they say or find it offensive. Ona software project, customers must pay for their rights by respecting theproject team's rights, which are listed here.1. To know the project objectives and to clarify priorities.2. To know in detail what product I'm supposed to build and to clarify theproduct definition if it is unclear.3. To have ready access to the customer, manager, marketer, or other personresponsible for making decisions about the software's functionality.4. To work each phase of the project in a technically responsible way, especiallyto not be forced to start coding too early in the project.5. To approve effort and schedule estimates for any work that T will be asked toperform. This includes the right to provide only the kinds of cost and sched-ule estimates that are theoretically possible at each stage of the project; totake the time needed to create meaningful estimates; and to revise estimateswhenever the project's requirements change.6. To have my project's status reported accurately to customers and uppermanagement.7. To work in a productive environment free from frequent interruptions anddistractions, especially during critical parts of the project.The first step toward project success is getting all parties to respect therights that make a successful project possible. The second step is to conductthe project in such a way that each party's survival needs are thoroughlysatisfied and none of the parties feels threatened. How to do that is thesubject of the rest of the book.8 1 Welcome to Software Project Survival TrainingSURVIVAL CHECKSSurvival Checks appear at the end of each chapter. They refer to projectcharacteristics that you can check from outside the project to gauge thehealth of the project.Keys to success are marked with a thumbs-up symbolthat exhibit these characteristics are headed for success. Potential pitfalls areindented and marked with a bomb symbolcharacteristics are at risk.j.Projects that exhibit theseProjectsThe agreement in principle is not followed in practice.The project team's survival needs are being met.The customer and the project team agree to respect each other'ssoftware project rights.9 A short test can assess a softwareproject's health. If the test indicatesthe project is at risk, you can im-prove its condition by taking stepsto raise its score. I The Survival Mind-SetTget? Will it be a glorious achievement or an embarrassing mistake? The workyou do on this test can help you find out.his chapter contains a test you can use to assess a project's chancesof successful completion. Will it be delivered on time and within bud-SURVIVAL TEST QUESTIONSGive the project 3 points for each "yes" answer. Give the project partial creditif you feel that is most accurate—for example, give it 2 points for "probably"and 1 point for "kind of, but not really." If the project is in the early stages,answer the questions based on the project plans. If the project is well under-way, answer the questions based on what has actually happened on theproject. The section following the test explains how to interpret the score.1SURVIVAL TESTREQUIREMENTS1. Does the project have a clear, unambiguous vision state-ment or mission statement?2. Do all team members believe the vision is realistic?3. Does the project have a business case that details the busi-ness benefit and how the benefit will be measured?4. Does the project have a user interface prototype that realis-tically and vividly demonstrates the functionality that theactual system will have?5. Does the project have a detailed, written specification ofwhat the software is supposed to do?6. Did the project team interview people who will actuallyuse the software (end users) early in the project and con-tinue to involve them throughout the project?1, This test is available in electronic form on the Survival Guide Web site. The site address ishttp://www.construji.com/surmvalguide/.12 2 Software Project Survival TestPLANNING7. Does the project have a detailed, written Software Devel-opment Plan?8. Does the project's task list include creation of an installa-tion program, conversion of data from previous versions ofthe system, integration with third-party software, meet-ings with the customer, and other "minor" tasks?9. Were the schedule and budget estimates officially updatedat the end of the most recently completed phase?10. Does the project have detailed, written architecture anddesign documents?11. Does the project have a detailed, written Quality Assur-ance Plan that requires design and code reviews in addi-tion to system testing?12. Does the project have a detailed Staged Delivery Plan forthe software, which describes the stages in which the soft-ware will be implemented and delivered?13. Does the project's plan include time for holidays, vacationdays, sick days, and ongoing training, and are resources al-located at less than 100 percent?14. Was the project plan, including the schedule, approved bythe development team, the quality assurance team, and thetechnical writing team—in other words, the people respon-sible for doing the work?PROJECT CONTROL15. Has a single key executive who has decision-making au-thority been made responsible for the project, and does theproject have that person's active support?16. Does the project manager's workload allow him or her todevote an adequate amount of time to the project?(continued)13 I The Survival Mind-Set17. Does the project have well-defined, detailed milestones("binary milestones") that are considered to be either 100percent done or 100 percent not done?18. Can a project stakeholder easily find out which of these bi-nary milestones have been completed?19. Does the project have a feedback channel by which projectmembers can anonymously report problems to their ownmanagers and upper managers?20. Does the project have a written plan for controllingchanges to the software's specification?21. Does the project have a Change Control Board that has fi-nal authority to accept or reject proposed changes?_ 22. Are planning materials and status information for theproject—including effort and schedule estimates, task as-signments, and progress compared to the plan thus far—available to every team member?23. Is all source code placed under automated revision control?24. Does the project environment include the basic toolsneeded to complete the project, including defect trackingsoftware, source code control, and project managementsoftware?RISK MANAGEMENT25. Does the project plan articulate a list of current risks to theproject? Has the list been updated recently?_, 26. Does the project have a project risk officer who is respon-sible for identifying emerging risks to the project?, 27. If the project uses subcontractors, does it have a plan formanaging each subcontract organization and a single per-son in charge of each one? (Give the project full score if itdoesn't use subcontractors.)14 2 Software Project Survival TestPERSONNEL28. Does the project team have all the technical expertiseneeded to complete the project?29. Does the project team have expertise with the business en-vironment in which the software will operate?30. Does the project have a technical leader capable of leadingthe project successfully?31. Are there enough people to do all the work required?32. Does everyone work well together?33. Is each person committed to the project?TOTALPreliminary score. Add up the points next to each answer.Size multiplier. Write in 1.5 if the project team has 3 or fewerfull-time-equivalent people including developers, qualityassurance personnel, and first-level management. Write in1.25 if it has 4 to 6 full-time-equivalent people. Otherwise,write in 1.0.Final score. Multiply the preliminary score by the size mul-tiplier.INTERPRETING THE SURVIVAL TESTThis is a difficult test for most projects; many will score less than 50 points.Table 3-1 on the following page explains how to interpret the score.The Software Project Survival Test establishes a measurement baselineyou can use for future comparisons. It is similar to the kind of test you takeat the beginning of a class in school. After you take the test, you spend a termstudying and learning a new subject, and at the end of the term, you take thetest again. If the instructor has done a good job of teaching the class (and youhave done a good job of taking it), your score will improve.15 I The Survival Mind-Set90+ Outstanding A project with this score is virtually guaranteed to succeed inall respects, meeting its schedule, budget, quality, and othertargets. In terms of Chapter 1's project needs hierarchy, such aproject is fully "self-actualized."A project at this level is performing much better than average.Such a project has a high probability of delivering its softwareclose to its schedule, budget, and quality targets.A score in this range represents a better-than-average level ofsoftware development effectiveness. Such a project stands afighting chance of meeting either its schedule or its budgettarget, but it probably won't meet both.This score is typical. A project with this score will likelyexperience high stress and shaky team dynamics, and thesoftware will ultimately be delivered with less functionalitythan desired at greater cost and with a longer schedule. Thiskind of project stands to experience the greatest benefitfrom applying the plan described in this book.A project with this score has significant weaknesses in themajor areas of requirements, planning, project control, riskmanagement, and personnel. The primary concern of a projectin this category should be whether it will finish art all.80-89 Excellent 60-79 Good 40-59 Fair < 40 At Risk To be a good "before and after" test, the test should cover the entiresubject of the class. The Survival Test does cover the entire subject of soft-ware project survival. After reading this book, plan your next project andthen take the survival test again. The project's score will have improved, andthe project's chance of surviving will have improved with it,16 2 Software Project Survival TestSurvival CheckThe project scores at least 60 on the Survival Test.The project scores less than 60, but corrective actions are plannedto improve its score.The project team doesn't follow through on the planned cor-rective actions. Well-defined development processes are important and neces-sary elements of software project survival. With we...

    关注我们

  • 新浪微博
  • 关注微信公众号

  • 打印亚博足球app下载
  • 复制文本
  • 下载计算机书籍 计算机书籍 Software Project Survival Guide.XDF
  • 您选择了以下内容