《软件工程-实践者的研究方法》cha.ppt

《《软件工程-实践者的研究方法》cha.ppt》由会员分享，可在线阅读，更多相关《《软件工程-实践者的研究方法》cha.ppt（17页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、1These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Chapter 21nProject SchedulingSlide Set to accompanySoftware Engineering:A Practitioners Approach,7/e by Roger S.PressmanSlides copyright 1996,2001,2005,

2、2009 by Roger S.PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering:A Practitioners Approach,7/e.Any other reproduction or use is prohibited without the express written permission of the author.A

3、ll copyright information MUST appear if these slides are posted on a website for student use.2These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Why Are Projects Late?nan unrealistic deadline established

4、by someone outside the software development groupnchanging customer requirements that are not reflected in schedule changes;nan honest underestimate of the amount of effort and/or the number of resources that will be required to do the job;npredictable and/or unpredictable risks that were not consid

5、ered when the project commenced;ntechnical difficulties that could not have been foreseen in advance;nhuman difficulties that could not have been foreseen in advance;nmiscommunication among project staff that results in delays;na failure by project management to recognize that the project is falling

6、 behind schedule and a lack of action to correct the problem3These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Scheduling Principlesncompartmentalizationdefine distinct tasksninterdependencyindicate task

7、 interrelationship neffort validationbe sure resources are availablendefined responsibilitiespeople must be assignedndefined outcomeseach task must have an outputndefined milestonesreview for quality4These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill

8、 2009).Slides copyright 2009 by Roger Pressman.Effort and Delivery Time5These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Effort Allocationn“front end”activitiesn customer communicationn analysisn design

9、n review and modificationnconstruction activitiesn coding or code generationntesting and installationn unit,integrationn white-box,black boxn regression 40-50%40-50%30-40%30-40%15-20%15-20%6These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Sli

10、des copyright 2009 by Roger Pressman.Defining Task Setsndetermine type of projectnassess the degree of rigor requirednidentify adaptation criterianselect appropriate software engineering tasks7These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).

11、Slides copyright 2009 by Roger Pressman.Task Set Refinement1.1 Concept scoping determines the overall scope of the project.Task definition:Task 1.1 Concept Scoping 1.1.1Identify need,benefits and potential customers;1.1.2Define desired output/control and input events that drive the application;1.1.2

12、.1FTR:Review written description of need FTR indicates that a formal technical review(Chapter 26)is to be conducted.1.1.2.2Derive a list of customer visible outputs/inputs1.1.2.3FTR:Review outputs/inputs with customer and revise as required;1.1.3Define the functionality/behavior for each major funct

13、ion;1.1.3.1FTR:Review output and input data objects derived in task 1.1.2;1.1.3.2Derive a model of functions/behaviors;1.1.3.3FTR:Review functions/behaviors with customer and revise as required;1.1.4Isolate those elements of the technology to be implemented in software;1.1.5Research availability of

14、existing software;1.1.6Define technical feasibility;1.1.7Make quick estimate of size;1.1.8Create a Scope Definition;endTask definition:Task 1.1is refined to8These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Press

15、man.Define a Task Network9These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Timeline ChartsTasksWeek 1Week 2Week 3Week 4Week nTask 1Task 2Task 3Task 4Task 5Task 6Task 7Task 8Task 9Task 10Task 11Task 1210

16、These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Use Automated Tools toDerive a Timeline Chart11These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009)

17、.Slides copyright 2009 by Roger Pressman.Schedule Trackingnconduct periodic project status meetings in which each team member reports progress and problems.nevaluate the results of all reviews conducted throughout the software engineering process.ndetermine whether formal project milestones(the diam

18、onds shown in Figure 27.3)have been accomplished by the scheduled date.ncompare actual start-date to planned start-date for each project task listed in the resource table(Figure 27.4).nmeet informally with practitioners to obtain their subjective assessment of progress to date and problems on the ho

19、rizon.nuse earned value analysis(Section 27.6)to assess progress quantitatively.12These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Progress on an OO Project-InTechnical milestone:OO analysis completed A

20、ll classes and the class hierarchy have been defined and reviewed.Class attributes and operations associated with a class have been defined and reviewed.Class relationships(Chapter 8)have been established and reviewed.A behavioral model(Chapter 8)has been created and reviewed.Reusable classes have b

21、een noted.nTechnical milestone:OO design completedThe set of subsystems(Chapter 9)has been defined and reviewed.Classes are allocated to subsystems and reviewed.Task allocation has been established and reviewed.Responsibilities and collaborations(Chapter 9)have been identified.Attributes and operati

22、ons have been designed and reviewed.The communication model has been created and reviewed.13These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Progress on an OO Project-IInTechnical milestone:OO programmi

23、ng completedEach new class has been implemented in code from the design model.Extracted classes(from a reuse library)have been implemented.Prototype or increment has been built.nTechnical milestone:OO testingThe correctness and completeness of OO analysis and design models has been reviewed.A class-

24、responsibility-collaboration network(Chapter 6)has been developed and reviewed.Test cases are designed and class-level tests(Chapter 19)have been conducted for each class.Test cases are designed and cluster testing(Chapter 19)is completed and the classes are integrated.System level tests have been c

25、ompleted.14These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.Earned Value Analysis(EVA)nEarned valuenis a measure of progressnenables us to assess the“percent of completeness”of a project using quantitat

26、ive analysis rather than rely on a gut feelingn“provides accurate and reliable readings of performance from as early as 15 percent into the project.”Fle9815These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressm

27、an.Computing Earned Value-InThe budgeted cost of work scheduled(BCWS)is determined for each work task represented in the schedule.n BCWSi is the effort planned for work task i.nTo determine progress at a given point along the project schedule,the value of BCWS is the sum of the BCWSi values for all

28、work tasks that should have been completed by that point in time on the project schedule.nThe BCWS values for all work tasks are summed to derive the budget at completion,BAC.Hence,BAC=(BCWSk)for all tasks k16These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(Mc

29、Graw-Hill 2009).Slides copyright 2009 by Roger Pressman.Computing Earned Value-IInNext,the value for budgeted cost of work performed(BCWP)is computed.nThe value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule.n“th

30、e distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed.”Wil99 nGiven values for BCWS,BAC,and BCWP,important progress indicators can be

31、 computed:Schedule performance index,SPI=BCWP/BCWSSchedule variance,SV=BCWP BCWSSPI is an indication of the efficiency with which the project is utilizing scheduled resources.17These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright

32、 2009 by Roger Pressman.Computing Earned Value-IIInPercent scheduled for completion=BCWS/BACnprovides an indication of the percentage of work that should have been completed by time t.nPercent complete=BCWP/BACnprovides a quantitative indication of the percent of completeness of the project at a given point in time,t.nActual cost of work performed,ACWP,is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule.It is then possible to computeCost performance index,CPI=BCWP/ACWPCost variance,CV=BCWP ACWP