Announcements � Quiz #4 will be on Thursday INF 111 / CSE 121: ● UML & Software Tools and Methods ● Readings not covered on previous quizzes � Regrades for Quiz #3 are due on � Regrades for Quiz #3 are due on Thursday Lecture Notes for Summer, 2008 Michele Rousseau � Assignment #3 due next Monday � Readings: Set 9 – Estimation Techniques ● Van Vliet Chapter 7 Lecture Notes 9 - Estimation 2 Class Averages Class Overall & Quiz 3 Quiz #3 90-100 ● Max 100% 80-89 ● Min 54% ● Avg 85% 70-79 ● Median M di 86% 86% Class Overall 60-69 ● Max 97% <60 ● Min 32% ● Avg 80% 0 5 10 15 20 ● Median 87% Quiz3 Class Overall Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 3 4 Previously in INF 111/CSE 121 Today’s Lecture � UML � Effort Estimation ● Package Diagrams ● State Transition Diagrams ● Activity Diagrams ● Communication Diagrams ● Communication Diagrams Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 5 6 1
The Mythical Man-Month Effort Estimation Predicting the resources required for a “Most software projects have gone software development process awry for lack of calendar time than for all other causes combined. � How much effort is required to complete an activity? an activity? Why is this cause of disaster so � How much calendar time is needed to common?” complete an activity? Brooks p. 14 � What is the total cost of an activity? � Project estimation and scheduling and interleaved management activities Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 7 8 Effort Estimation The Mythical Man-Month Chapter 2 of Brooks � How do you know how long a programming problem will take? � Source of some key ideas in software engineering about effort estimation ● Lessons that we haven’t really learned ( (as you can see in van Vliet) y ) � Don’t confuse effort with progress ● Just because you put in time, it doesn’t mean that you’re closer to your goal � Adding people to a project that is already late will only make it later Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 9 10 Poor Estimation 5 Key Points from MMM 1. Poor Estimation � Assumes nothing will go wrong � Large project has many smaller tasks 2. Effort estimates confuse effort with progress ● Hard to know all in advance ◘ Assuming men and months are interchangeable ● Hard to estimate accurately 3. 3. We don’t back up our estimates. We don t back up our estimates. � Probability of success in every step is small 4. Schedule progress is poorly monitored. � Progress is poorly monitored 5. Adding people to a project that is already late � Most measures confuse effort with will only make it later. progress Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 11 12 2
Why are Men and Months not Problems with Communication interchangeable? � Man-month: how much work is completed by 1 � Adding new people requires training them person in 1 month � Productive people are taken off the project � Intercommunication � Some attempt to schedule based on man- months.. ● If each part of the task must be coordinated ● Project is planned for: 5 people x 4 months ● Project is planned for: 5 people x 4 months ◘ 3 workers takes 3x the communication ◘ 3 workers takes 3x the communication ◘ 4 workers takes 6x the communication ● but there’s no time: x 2 /2 � Effort of communicating must be added to ● just double people!: 10 people x 2 months the amount of work to be done � Generally, adding more people lengthens ● Myth: men and months are interchangeable the process ● Why not? ◘ Communication!! Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 13 14 What about System Testing? Factors Affecting Productivity Rates � Optimism: My code is bug-free � Application domain experience � Usually the most mis-scheduled part of � Process quality programming � Project size Project size � Testing should account for ½ of the ● Negative relationship schedule � Technology support � Awareness of being behind schedule occurs at the last minute � Working environment Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 15 16 How are project plans created? How are project plans created? (2) � A wish list for the project is created � Numbers are passed up the chain ● Clients, executives, product ● Numbers are inflated and deflated managers, and programmers have to suit whether the availability of: input ◘ Money ◘ Calendar time, work time ◘ Calendar time work time � Tasks on the wish list are sized ◘ Market pressures, e.g. competitive ● Programmers are asked about bids, competitor time to market, trade feasibility and effort required - they shows give their best guess � Project plans are based on effort estimates! Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 17 18 3
Poor Estimation Techniques Parkinson's Law � Guessing � “Work fills the time available.” � Parkinson's Law � The project takes all the available time ● Adjust functionality? � Pricing to win � Advantage ● No overspending � Budget method � Disadvantages � Brooks, Chapter 2 ● Unethical ● “Good cooking takes time. If you are ● Unreliable made to wait, it is to serve you better, ● System is usually unfinished and to please you.” ● Gutless estimating Wait or eat it raw Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 19 20 Pricing to Win Pricing to Win (2) � The project costs less than whatever our competitors say � Advantages � The project cost is agreed on the basis ● You get the contract of an outline proposal and the � Disadvantages development is constrained by that cost p y ● Unethical ● Unreliable � A detailed specification may be ● The probability that the customer gets the system he or she wants is small. negotiated or an evolutionary approach ● Costs do not accurately reflect the work used for system development required London Ambulance System Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 21 22 Gutless Estimating Budget Method � More typical in S/E than in other � Similar to Parkinson’s law, but based on engineering disciplines money instead of time � Schedule to meet the client’s desired date � The project costs whatever the � Estimate based on little data customer has to spend on it � Managers need a backbone: � Advantages and Disadvantages similar to Parkinson’s Law ● “Poor hunches sometimes better than wish-derived estimates” Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 23 24 4
Better Estimation Techniques Take a break! � Get some Coffee � Estimating based on experience or hard data � Wakey-Wakey ● Expert judgment ● Estimation by analogy When we return… � Variation: Delphi method p � Better Estimation Techniques � Algorithmic cost modeling � Personal Software Process Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 25 26 Expert Judgment Estimation by Analogy � One or more experts in both software � The cost of a project is estimated by development and the application domain use comparing the project to a similar project in their experience to predict software costs. the same application domain � Advantages � Advantages ● Relatively cheap estimation method ● Relatively cheap estimation method ● Accurate if project data available A t if j t d t il bl ● Can be accurate if experts have direct experience with similar systems � Disadvantages ● Impossible if no comparable project has been � Disadvantages undertaken ● Very inaccurate if there are no experts ● Estimates can be inaccurate if details overlooked ◘ Are you an expert? ● Subsequent similar projects can be quicker ● Does not use hard data Lecture Notes 9 - Estimation Lecture Notes 9 - Estimation 27 28 Delphi Method Delphi Method (2) � Idea: Create a group expert opinion, 1. Experts independently create estimates. while counterbalancing personality factors in process 2. Moderator collects written estimates from individuals. � Panel of independent expert estimators 3. Estimates are distributed to group. 3. Estimates are distributed to group. + moderator d t Anonymously 4. Experts deliver new estimates based on new information from moderator (others opinions may help fill in forgotten details) 5. Continue until consensus is reached Lecture Notes 9 - Estimation 29 30 5
Recommend
More recommend
