1 / 84

PLANNING AND ESTIMATING

PLANNING AND ESTIMATING. Prologu e. There is no easy solution to the difficulties of constructing a SW product, A large product takes time and resources,

oren-ballard
Télécharger la présentation

PLANNING AND ESTIMATING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PLANNING AND ESTIMATING

  2. Prologue • There is no easy solution to the difficultiesof constructing a SW product, • A large product takes time and resources, • Careful planning at the beginning of the project is perhaps the single most important factor that distinguishes success from failure, • planning reach a peak after the specification phase , • The initial planning is by no means enough. Planning, like testing and documentation,must continuethroughout the SW development and maintenance process.

  3. Overview • Planning and the SW process, • Cost & Duration Estimation, • COCOMO, • SW Project Management Plan, • Planning of testing, • Planning of object-oriented projects, • Training requirements, • Documentation standards, • CASE tools for the planning phase, • Testing during the planning phase ,

  4. Planning and the SW process, • Cost & Duration Estimation, • COCOMO, • SW Project Management Plan, • Planning of testing, • Planning of object-oriented projects, • Training requirements , • Documentation standards, • CASE tools for the planning phase, • Testing during the planning phase.

  5. Planning and the SW process • The earliest possible detailed planning isafter the specification phase, because we do not have enough information available during the initial phases, • And what if we have a prototype? • There is a world of difference between the information at the end of the requirements phase,and at the end of the specification phase, Sketch VS blue print:

  6. Planning and the SW process, • Cost & Duration Estimation, • COCOMO, • SW Project Management Plan, • Planning of testing, • Planning of object-oriented projects, • Training requirements, • Documentation standards, • CASE Tools for the Planning Phase, • Testing during the Planning Phase.

  7. Estimation Accuracy VS Process Phase …

  8. Estimation Accuracy… (Cont'd) • Examples based upon the previous figure for a finally cost 1M$ product: • Conclusion: estimation is not an exact science ,

  9. Cost Estimation • Yet, accurate cost estimation is critical, • Underestimation might:cause us to loose money, • Overestimate might:Cancel the project or,Make the client go elsewhere, • Two type of cost estimation: • Internal – salaries, HW, SW, consultant… • External – the price presented to the customer, • There are too many variables for accurate estimateof cost or duration ,

  10. The Human Factor … • Matched pairs of programmers with same background, seniority, and same product size: The comparison measured: • Development time, • Coding time, • Debugging time, • Quality, • Guess …

  11. The Human Factor (Cont’d) • Differences of up to 1 to 28 between pairs of matched programmers!, • Does it important in big teams?, • And what about same programmer consistency?, • Critical staff members may resign during the project , • Can we measure the turnover? ,

  12. Tracking Our Estimates • Whatever estimation method used, careful tracking is vital, • Assume that we predicted a top level-design phase of 3 month require 7 person-months effort. However 4 months have gone and 10 person-months effort have been expended – and we are only half way through… • We must re-consider our preliminary estimation! ,

  13. Metrics for the Size of a Product (I) LOC & KDSI • The most obvious: Code size, • LOC – Lines of Code , • KDSI – Thousand Delivered Source Instructions.

  14. Problems With LOC and KDSI … • LOC is known when the product finished, • Source code is only a small part of the total SW effort, what about planning, designing etc., • Different languages lead to different lengths of code , • It is not clear how to count lines of code: • Executable lines of code? • Data definitions? • Comments? • JCL statements? • Changed / deleted lines? • What if we reuse code?

  15. Problems With LOC and KDSI (Cont'd) • LOC is not defined for nonprocedural languages (LISP), • Not everything written is delivered to the client,(e.g. code for testing..), • What if we use code generator? , • Estimation based on LOC is doubly dangerous: • To start the estimation process, LOC in the finished product must be estimated, • The LOC estimate is then used to estimate the cost of the product — an uncertain input to an uncertain cost estimator.

  16. Metrics (Cont’d) (II) ‘SW Science Metric’: • Metrics based on the number of operands and operators , • Limited predictive power — metrics can be computed only after the product has been implemented.

  17. Metrics – Function Points … (III) – FP • We look for measurable quantities that can be determined early in SW life cycle, • Three steps process:1. UFP • Based on the number of inputs (Inp), outputs (Out), inquiries (Inq), master files (Maf), interfaces (Inf),

  18. Metrics – FP (Cont'd) …

  19. Metrics – FP (Cont'd) … 2.TCF • Compute the Technical Complexity Factor (TCF): • Assign a value from 0 (“not present”) to 5 (“strong influence”) to each of 14 factors: • Sum these numbers  DIDegree of Influence [0, 70], • TCF = 0.65 + 0.01 DI , • TCF is [0.65, 1.35]. ,

  20. Metrics – FP (Cont'd) …

  21. Metrics – FP (Cont'd) 3. • The number of Function Points (FP) is given byFP=UFPTCF

  22. Analysis of FP • Function points are usually better than KDSI— but there are some problems, • “Errors in excess of 800% counting KDSI, but only 200% in counting function points” [Jones, 1987],a most revealing remark… , • What about maintenance? It can be inaccurately measured.

  23. Actual Data Pre – Estimate FP VS KDSI Comparison • Same product was developed in Assembler and Ada: • KDSI/Month: ASM KDSI > Ada KDSI? (in 60%!!), • KDSI: It is cheaper to code in ASM? , • FP: More sensible results!

  24. More Size Estimation Methods (IV) Mk II Function Points • Aimed to compute UFP more accurately, • Decompose SW into component transactions, each consisting of input, process, and output, (V) Feature Points • Aimed for SW with algorithm major role: real-time embedded, communications, etc., • Maf - Master Files , Alg - Algorithms • Feature Points = FP – 3 * Maf + 3 * Alg, (VI) Boeing 3D Function Points • Aimed for scientific and real-time SW.

  25. Duration Estimation • Accurate duration estimation is critical! (Time to Market, occupation for employees), • In order to estimate the size and the duration of a SW project, above its size, we must consider: • Personnel skill level (1:28)…, • Project complexity, • Development team familiarity with application area, • The target HW, • Availability of CASE tools, • The deadline effect ,

  26. 1. Expert Judgment by Analogy • Experts compare target product to completed products: • Would give the most accurate budget because several experts can estimate, compare and discuss the project cost. The estimation process iterates until an agreed estimate is reached. Therefore, the experience driven costing would give a more realistic budget, • Guesses can lead to hopelessly incorrect cost estimates, • Experts may recollect completed products inaccurately, • Human experts have biases ,

  27. 2. Bottom-up approach • Break the product into smaller components, • Estimate each part separately, • Advantages: • Faster and more accurate – per part, • Disadvantages: • The smaller components may be no easier to estimate, • The product is more than the sum of its components ,

  28. 3. Algorithmic models • A model is built from historical cost information that relates SW metric (usually it's size) to the project cost, • The model gets new SW estimated metrics and predicts the effort required, • An algorithmic model is unbiased, and superior to expert opinion, • However, estimates are only as good as the underlying assumptions , • Examples: • RCA Price S Model, • COnstructive COst MOdel (COCOMO).

  29. Planning and the SW process, • Cost & Duration Estimation, • COCOMO • SW Project Management Plan, • Planning of testing, • Planning of object-oriented projects, • Training requirements, • Documentation standards, • CASE Tools for the Planning Phase, • Testing during the Planning Phase.

  30. COCOMO … • COCOMO was put together in 1981, • COCOMO consists of three models:Macro-estimation model for the product as a whole,Intermediate COCOMO,Micro-estimation model which treats the product in detail , • We examine intermediate COCOMO.

  31. Intermediate COCOMO … 1. Estimate the length of the product in KDSI , 2. Estimate the product development mode:Organic Or Semidetached Or Embedded Organic (Small and straightforward) project that is routine for a company. It is in a well understood domain of application, or it is being done by a team that works well together. A project of this type will run smoothly, few hitches anticipated. This is the "easy" end.

  32. Intermediate COCOMO (Cont'd) … 2. Product development mode (Cont’d): Semidetached (medium-sized), The middle of the difficulty spectrum. Projects here are somewhat complex but something the company has experience dealing with. The overall project is not massive or huge, nor is it simple and compact. Embedded (complex), A project that will be difficult for a company. Perhaps it is in a domain of application that is fully novel (in 1965, build a software system to control a rocket that will fly men to the moon and back), or perhaps it is an area in which the company has little experience.

  33. Intermediate COCOMO (Cont'd) … • 3. Set a & b parameters value: • 4. Compute NominalEffort = a´ (KDSI)bperson-months , • There are 5th and 6th steps, but first, an example.

  34. Intermediate COCOMO (Cont'd) … • Example: • Est. 12,000 delivered source statements (12 KDSI), • Straightforward product (“organic mode”), • Nominal Effort = 3.2 ´ (KDSI)1.05 person-months, • Thus Nominal Effort = 3.2 ´ (12)1.05 = 43 person-months , • 12,000 / 43 = 279 LOC per month!

  35. Intermediate COCOMO (Cont'd) … • 5. Set 15 SW development cost multipliers:

  36. Intermediate COCOMO (Cont'd) • Example: Product complexity multiplier • Very low: [0.7] if-then-else, do-while, case, etc., • Low: [0.85] nested if-then-else etc., • Nominal: [1.0] intermodule control & decision tables, etc., • High: [1.15] operators are highly nested, compound predicates, queues, stacks, etc., • Very high: [1.30] reentrant, recursive coding, etc., • Extra high: [1.65] multiple resource scheduling with dynamically changing priorities, etc. , • 6. Multiply the Nominal Effort by each of the selected 15 multipliers,This can lead to 0.088 to 72.3 variance!

  37. Intermediate COCOMO – Example … • Example: μP-based communications processing SW for electronic funds transfer network with high reliability, performance, development schedule, and interface requirements, • 1. Estimate: 10,000 delivered source instructions, • 2. Complex (“embedded”) mode, • 3. a=2.8, b=1.2, • 4. Nominal effort = 2.8´ (10)1.20= 44 person-months , • 5. Set 15 SW development cost multipliers. (next slide).

  38. Inter. COCOMO – Example (Cont'd)

  39. Intermediate COCOMO (Cont'd) … • 6. Product of effort multipliers = 1.35, So estimated effort for project is 1.35 ´ 44 = 59 person-months , • Estimated effort for project (59 person-months) is used as input for additional formulas for: • Dollar costs, • Development schedules, • Phase and activity distributions, • Computer costs, • Annual maintenance costs, • Related items.

  40. Intermediate COCOMO (Cont'd) • Intermediate COCOMO has been validated with respect to a broad sample, • Actual values are within 20% of predicted values about 68% of the time , • Intermediate COCOMO was most accurate estimation method of its time.

  41. COCOMO II • 1995 extension to 1981 COCOMO that incorporates: • Object orientation, • Modern life-cycle models, • Rapid prototyping, • Fourth-generation languages, • COTS SW , • COCOMO II is far more complex than the first version…

  42. Planning and the SW process, • Cost & Duration Estimation, • COCOMO, • SW Project Management Plan, • Planning of testing, • Planning of object-oriented projects, • Training requirements, • Documentation standards, • CASE Tools for the Planning Phase, • Testing during the Planning Phase.

  43. SW Project Management Plan (SPMP) • The SPMP should define: The work to be done, The resources with which to do it, The money to pay for it , The development process.

  44. Work Categories • Project function: • Work carried on throughout project, • Examples: project management, quality control, etc., • Activity: • Work that relates to a specific phase, • A major unit of work, • With precise beginning and ending dates, • That consumes resources, and • Results in work products like the budget, design, schedules, source code, or users’ manual , • Task: • The smallest unit of work subject to management accountability.(An activity comprises a set of tasks).

  45. Completion of Work Products • Milestone: date on which the work product is to be completed, • It must first pass reviews performed by: • Fellow team members, • Management, • Client, • Once the work product has been reviewed and agreed upon, it becomes a baseline, Millstone…

  46. Work Package • Work product, plus: Predecessors, Staffing requirements, Estimated Duration, Resources, Name of responsible individual, Acceptance criteria for work product , Successors.

  47. Resources • Resources needed for SW development: People – developers, Hardware – development environment and target , Support SW – OS, CASE, etc.

  48. Use of Resources Varies With Time • Rayleigh curves accurately depict resource consumption, • Entire SW development plan must be a function of time ,

  49. , Resources Requirement and Allocation • We need three senior programmers with at least 5 years of experience, • Three senior programmers with at least 5 years of experience in real-time programming are needed, two to start three months after the project commences, the third to start six months after that. Two will be phase out when the product testing starts, the third when maintenance begins , • As a matter of fact, all resourced are time dependents.

  50. Money • A vital component of the plan, • The detailed budget must be worked out as a function of time, • Money must be allocated, as a function of time, to project functions & activities.

More Related