Scheduling 1. You selected an Appropriate Process Model

Transcription

1 Chapter 24 Software Engineering CSCI 3321 Software Engineering : A Practitioner s Approach Software Project Scheduling Dr. Thomas E. Hicks Dr. Thomas Hicks Computer Science Department Trinity University Computer Science Department Trinity University Thanks To Ian Sommerville & Roger Pressman For Much Of The Slide Content 1 Scheduling 1. You selected an Appropriate Process Model 2. You identified the Software Engineering Tasks to be performed. 3. You estimated the Amount of Work. 4. You selected and estimated the Number of People 1

2 5. You know the Deadline. 6. You considered the Risks. 7. You created a Schedule you created a Network of Software Engineering Tasks that would enable you to getc the job done on time. You assigned Responsibility for Each SE Task You tried to make sure Each SE Task was done on time You adapt the Network as Risks become Reality Rick trotter Story From Text In the late 1960 s, a bright-eyed young engineer was chosen to write a computer program for an automated manufacturing application. The reason for his selection was simple. He was the only person in his technical group who had attend classes in computer programming. He knew the ins and outs of assembly language and Fortran, but had never had Software Engineering. He knew nothing about project scheduling or tracking. His boss gave him appropriate manuals and a verbal description of what had to be done. He read the manuals, considered the After two weeks, the boss called him into his office and asked him how things were going. Really Great! replied the young engineer with youthful enthusiasm. This was much easier than I thought. I am probably 75% finished. The boss smiled and encouraged the young engineer to keep up the good work. They planned to meet again in a weeks time. A week later, the boss called him into his office and asked Where are we Everything s going well said the youngster, but I have run into a few small snags. I ll get them ironed out soon and be back on track soon. approach, and started writing code. 2

3 How does the deadline look?, asked the boss. No problem! said the engineer. I am close to 90% complete. If you have been working with software for more than a few years, you can finish the story! It ll come as no surprise that the young engineer stayed 90% complete for the entire duration of the project. Excessive or irrational schedules are probably the most single destructive influence in all of software. The only reason the project was finished more than a month after the deadline is because others were hired to help complete the job. This story has been repeated tens of Caspers Jones thousands of times during the past four decades. Patterns Of Large Software Systems: Failures & Successes Any Commander and Chief who undertakes to carry out a plan which he considers defective is at fault. Projects Are Late He must put forth his reasons, insist on the plan being changed, and finally tender his resignation rather than be the instrument of his army s downfall. Napoleon 9 Of The More Common Reasons Why Are Projects Late Projects are sometimes Late because an Unrealistic Deadline was established by someone outside the software development group 2. Projects are sometimes Late because Changes To The Requirements have occurred and these changes are not reflected in schedule changes. 3. Projects are sometimes Late because the effort and/or resources, necessary to complete the job, were honestly underestimated by project management. 4. Projects are sometimes Late because one or more Identified Risks became a Reality. 9 Of The More Common Reasons Why Are Projects Late Projects are sometimes Late because Unidentified Risks have surfaced as a Reality. 6. Projects are sometimes Late because of Technical Difficulties that could not have been foreseen in advance. 7. Projects are sometimes Late because of Human Difficulties that could not have been foreseen in advance. 8. Projects are sometimes Late because of Miscommunication among project staff that results in delays. 9. Projects are sometimes Late because the project management has failed to recognize that the project is falling behind schedule and a lack of action to correct the problem 3

4 Iterative Development Process Chapter 23 dealt with Estimation Techniques. Chapter 24 deals with Scheduling! If the best estimates indicate that the deadline is unrealistic, a competent project manager should protect his team from undue pressure and reflect the pressure back to it s originators Pressman Revisit The Iterative Development Process 1. Recognizes the reality of changing requirements Caspers Jones s research on 8000 projects What s A Project Manager To Do? Scenario 40% of final requirements arrived after the analysis phase, after development had already begun 2. Promotes early risk mitigation, by breaking down the system into mini-projects and focusing on the riskier elements first 3. Allows you to plan a little, design a little, and code a little 4. Encourages all participants, including testers, integrators, and technical writers to be involved earlier on 5. Allows the process itself to modulate with each iteration, allowing you to correct errors sooner and put into practice lessons learned in the prior iteration 6. Focuses on component architectures, not final big bang deployments Scenario Your company has just been hired to build a real time controller for a medical diagnostic instrument that is to be introduced to the market in nine months. You have been given the project. You Are The Project Manager! You do a careful estimation and a careful risk analysis and come to the conclusion that the software, as requested, will require 14 calendar months to create with your available staff. What Do You Do? Scenario (cont - 1) Pressman says You can t just march into the customer/marketing/sales group and demand that the deadline be changed! There are external market pressures that have often dictated the date, and the stakeholder is going to feel that the product must be released as advertised. What Do You Do? Pressman says it is equally foolish to refuse to undertake the work (from a career standpoint). What Do You Do? 4

5 Scenario (Pressman Solution - 1 ) Scenario (Pressman Solution - 2 ) 1. Perform a detailed estimate using historical data from past 4. Pressman says to say something like: products. Determine the effort and duration for the project. I think we may have a problem with the delivery date for the XYZ controller software. I ve given each of you an abbreviated breakdown of production rates for past projects and an estimate that we ve done in a number of different ways. 2. Using an Incremental Process Model (ch 3), develop a software engineering strategy that will deliver critically functionality by the imposed deadline, but delay other functionality until later. Document the plan. 3. Meet with the customer and (using the detailed estimate), You ll note that I have assumed a 20% improvement in past production rates, but we still get a delivery date that is 14 calendar months rather than 9 months away. explain why the imposed deadline is unrealistic. Be certain to note that all of the estimates are based on performance on past projects. Also be certain to indicate the percent improvement that would be required to achieve the deadline as it currently exists. Scenario (Pressman Solution - 3 ) Scenario (Pressman Solution - 3 ) 5. Pressman says to offer the Incremental Development 5. (cont) strategy as an alternative: We have a few options, and I would like you to make a decision based on them. First, we can increase the budget and bring on additional resources so that we ll have a shot at getting the job done in 9 months. But understand that this will increase the risk of poor quality due to a tight timeline. Third, we can dispense with reality and wish the project complete in nine months. We will wind up with nothing that can be delivered to the customer. The third option, I hope you agree, is unacceptable. Past history, and our best estimates, say that it is unrealistic and a recipe for disaster. Second, we can remove a number of the software functions and capabilities that you are requesting. This will make the preliminary version of the product less functional, but we can announce all functionality and then deliver over a 14 month period. (cont) 6 Major Scheduling Principles Scheduling Principles 1. Compartmentalization - define Distinct Tasks 2. Interdependency - indicate Task Interrelationship 3. Effort Validation - be Sure Resources Are Available 4. Defined Responsibilities - people Must Be Assigned 5. Defined Outcomes - each Task Must Have An Output 6. Defined Milestones - review For Quality 5

6 About Program Scheduling Relationship Between People & Effort Really Small Project single person can do analysis, design, coding, and testing. As the Size of the Project Increases, more people must become involved. Effort Cost Really small projects, today, require more than a ten year Ea = m (td 4 /t a4 ) Impossible region person effort. [Rarely can we wait 10 years for one person to do it.] Ea = effort in person-months t d = nominal delivery time for schedule t o = optimal development time (in terms of cost) t a = actual delivery time desired Ed Eo td to development time Tmin =0.75T d Myth If we fall behind schedule, we can always add more programmers and catch up later in the project The new people need to learn the project Those who were doing the work often teach them Fall Further Behind! How Do So Many Projects Fall Behind Schedule? From The Mythical Man Month Pressman says that Project Schedules are elastic to some degree; we can add additional staff successfully to some degree. One Day At A Time! Fred Brooks Mythical Man Month Putnam-Norden-Rayleigh (PNR) Curve Effort Calculation Effort Cost 4 4 Ea = m (td /t a ) Impossible Ea = effort in person-months region t d = nominal delivery time for schedule t o = optimal development time (in terms of cost) t a = actual delivery time desired Ed Eo td to development time Tmin =0.75T d 6

7 Effort Calculation (Use As Guide Only) Effort Allocation No Lines Delivered Source Code L = P x E1/3 t4/3 L is related to effort and development! E = development effort in person months P = productivity parameter (2,000 20,000) that reflects a variety of factors that lead to high quality software engineering work t = project duration in calendar months Development Effort in Person Years E = L3 / (P3 t 4 ) Can include a burdened labor rate factor ($/Person-Year) to the Development Effort equation to get a Cost relationship. Effort Allocation Task Set Refinement Front End Activities Customer Communication Analysis Design Review And Modification Construction Activities Coding Or Code Generation Testing And Installation Unit, Integration White -box, Black Box Regression % % 20% % -40% Task Set Refinement Define a Task Network 1.1 scoping determines the overall scope of the project. I.5a Implement. I.3a Tech. Risk Assessment Task definition: Task 1.1 Scoping Identify need, benefits and potential customers; Define desired output/control and input events that drive the application; Begin Task FTR: Review written description of need FTR indicates that a formal technical review (Chapter 26) is to be conducted Derive a list of customer visible outputs/inputs FTR: Review outputs/inputs with customer and revise as required; endtask Task Define the functionality/behavior for each major function; I.1 scoping I.2 planning I.3b Tech. Risk Assessment I.3c Tech. Risk Assessment I.4 Proof of I.5b Imple ment. Integrate a, b,c I.6 Customer Reaction I.5c Imple ment. Begin Task FTR: Review output and input data objects derived in task 1.1.2; Derive a model of functions/behaviors; FTR: Review functions/behaviors with customer and revise as required; endtask Task is refined to Isolate those elements of the technology to be implemented in software; Research availability of existing software; Define technical feasibility; Make quick estimate of size; Three I.3 tasks are applied in parallel to 3 different concept functions Three I.3 tasks are applied in parallel to 3 different concept functions Create a Scope Definition; endtaskdefinition: Task 1.1 7

8 Use Tools Timeline Charts Tasks Week 1 Week 2 Week 3 Week 4 Week n Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12 Use Automated Tools to Derive a Timeline Chart Work tasks I.1.1 I.1.2 I.1.3 I.1.4 I.1.5 I.1.6 I.1.7 I.1.8 week 1 week 2 week 3 Schedule Tracking week 4 week 5 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement defined Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI defined Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition complete Isolate software elements Milestone: Software elements defined Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identified Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed Make quick estimate of size Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete Schedule Tracking Conduct periodic project status meetings in which each team Earned Value Analysis member reports progress and problems. Evaluate the results of all reviews conducted throughout the software engineering process. Determine whether formal project milestones have been accomplished by the scheduled date. Compare actual start-date to planned start-date for each project task listed in the resource table Meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. Use earned value analysis to assess progress quantitatively. 8

9 Earned Value Analysis (EVA) Computing Earned Value-I The budgeted cost of work scheduled (BCWS) is Earned value is a measure of progress enables us to assess the percent of completeness of a project using quantitative analysis rather than rely on a gut feeling provides accurate and reliable readings of performance from as early as 15 percent into the project. [FLE98] Computing Earned Value-II Next, the value for budgeted cost of work performed (BCWP) is computed. The 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. the 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] Given values for BCWS, BAC, and BCWP, important progress indicators can be computed: Schedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP BCWS SPI is an indication of the efficiency with which the project is utilizing scheduled resources. determined for each work task represented in the schedule. BCWSi is the effort planned for work task i. To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule. The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence, BAC = (BCWS k ) for all tasks k Computing Earned Value-III Percent scheduled for completion = BCWS/BAC provides an indication of the percentage of work that should have been completed by time t. Percent complete = BCWP/BAC provides a quantitative indication of the percent of completeness of the project at a given point in time, t. Actual 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 compute Cost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP ACWP Software Engineering CSCI 3342 Dr. Thomas E. Hicks Computer Science Department Trinity University Textbook: Software Engineering By Roger Pressman Textbook: Software Engineering By Ian Sommerville Special Thanks To WCB/McGraw -Hill & Addison Wesley For Providing Graphics Of Some Of Text Book Figures For Use In This Presentation. 9