1. Chapter 7: Estimation project planning - what to do project control make sure it’s done right estimation of detailed system design

2. Planning Process determine requirements from objectives specify work activities plan project organization develop schedule develop resource plan and budget establish control mechanisms each project is unique

3. Set objectives and Requirements –Project objectives are set early –Determine requirements –Statement of Work, which contain product description, constraints, schedule requirements, budget limit, and roles of project participants. See figure 7.1 for example of SOW

4. SOW Is a formal document that captures and defines the work activities, deliverables, and timeline a vendor must execute in performance of specified work for a client Areas that are typically addressed by a SOW are as follows: Purpose: Why are we doing this project? Scope of Work: This describes roughly the work to be done in detail. Work: This describes where the work is to be performed. Period of Performance: such as start and finish time, number of hours Deliverables Schedule: This part lists the specific deliverables, describing what is due and when. Applicable Standards: This describes any industry specific standards that need to be adhered to in fulfilling the contract. Acceptance Criteria: This specifies how the buyer or receiver of goods will determine if the product or service is acceptable. Special Requirements: This specifies any special hardware or software, requirements. Type of Contract/Payment Schedule. Miscellaneous: There are many items that do not form part of the main negotiations but are nonetheless very important to the project.

5. Identify Specific work to be Done Specify work activities STATEMENT OF WORK: –product descriptions –constraints –schedule requirements –budget limits –roles & responsibilities

6. WORK DEFINITION once objectives set, TRANSLATE INTO WORK ELEMENTS what needs to be done –easy to overlook some, or duplicate WORK BREAKDOWN STRUCTURE –divide project into major work categories Subdivide.” Running a project without a WBS is like going to a strange land without a roadmap”

7. How Do you eat an elephant? – Just One slice at a time……

8. Work Breakdown Structure is a deliverable oriented decomposition of a project into smaller components.

9. WBS example

10. Work Breakdown Structure level 1 - overall project level 2 - category –major project sub element level 3 - task –Sub element of category level x - subtask level bottom - WORK PACKAGE –specific activity, summary of work to be done is the work Package.

11. Detailed Task List WBS can be focused on –PRODUCT –FUNCTION –etc. when work packages identified, –estimate requirements by resource –WHAT IS NEEDED –WHEN –WHAT MUST PRECEDE

12. Work Breakdown Structure needs to be checked, approved provides –good definition of work –how long it will take –resources required –estimated costs planning & control –assignments, budget, basis for control

13. Work Packages( for Tasks) A Work Package is a deliverable or work component at the lowest level of its WBS branch. Is the basic building block of a work breakdown structure. It can be considered as a sub-project. It is composed of one or several tasks. Is a subset of a project that can be assigned to a specific party for execution. It is the lowest level of the WBS where both the cost and the duration can be reliably estimated. chunk of required work relatively small cost and short duration includes –summary of work –inputs required (predecessors) –manager responsible –product specifications –resources required (including budget, dates) –deliverables

14. list of work packages (activities) system design activitypredecessortime A2 identify req’d infoA110 days A31 basic softwareA23 days A32 data access req’dA21 day A33 vendor softwareA21 day

15. How is a Work Package Organized? A work package is not a separate function or data object in the Project System. You can create a work package according to your needs using a WBS element or an activity. Work packages can be on any level in the work breakdown structure and are characterized by: Start and finish dates Texts describing the work to be performed Responsible cost centers Cost centers carrying out the project related tasks without definable end results (overhead & management; inspection; maintenance) should be included as task-oriented work packages for COST purposes

16. Plan Project Organization Identify resources required by work package RESPONSIBILITY MATRIX –Which functions do what work packages –Cost account structure start & finish date budget responsibilities

17. Project Management System lists activities on one axis lists people on other axis shows who is –primarily responsible –also involved –has approval authority –must be notified

18. Develop the Schedule BASIS for –RESOURCE ALLOCATION –ESTIMATED COST –plan for monitoring & control EVENTS or MILESTONES –when activity completed (or started) –INTERFACE EVENT when responsibility passes

19. Kinds of Schedules project schedules –project master schedule - top management –overview rather than detail task schedules –specific activities required –more detail

20. quotes Work expands to fill the time available for its completion - Parkinson's law The key is not to prioritize what's on your schedule, but to schedule your priorities. The only reason I'm coming out here tomorrow is the schedule says I have to.. If you don’t plan, it doesn’t work. If you do plan, it doesn’t work either. Why plan! The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.failure

21. Develop Resource Plans & Budgets Activities often compete for the same resources –hire more –reschedule Resource plans show critical resource schedules –bottlenecks around which schedule is built

22. Charts visual aids Gantt Charts –plan - activities by time (work in outline) –implement - fill in as work done –doesn’t show relationships well –very good at seeing where things are (IF ACCURATE) Expense Charts - cumulatively graph $ spent

23. Control Points Includes –milestones, at completion of sub component or phase, to keep each element of the organization informed of what is going on. –checkpoint reviews, held at the conclusion of each phase to determine whether or not to proceed with the rest of the project. –status review meetings, gather cost, quality, and schedule information. –staff meetings, regularly held to maintain communication.

24. Recap Planning - key to accurate bidding need to know what it will cost in order to know how to price need to know resources required, complex projects take a long time MIS projects –activities, predecessor relations, resource use

25. Software Estimation

26. Tips for estimating Avoid the entire project estimation trap, you can not estimate the project with any degree of accuracy. The schedule is the one way the project will not proceed. Use date range estimate, “ well based on the 3 minutes if information you’ve told me about the project. It looks like we could deliver something in Q2 of next year”. Remember that an estimate is an approximation- a guess. The bigger the guess the more error you will have Many software people are optimistic. Tasks they take longer that you think they will

27. Tips for estimating It is easier to estimate smaller chunk of work. If you have given a project deadline, you do need to estimate anything al all. Timebox phases (build the system by feature) if you have an over constrained project. Estimating with multitasking. You don’t. you can’t. don’t even try it. In multitasking you guarantee that your project will be late. Estimating using inch-pebbles (one to two days tasks that either done or not done) wherever possible.

28. Programming Products ( scale of project size) Program, A program is what we all have developed. It's simple piece of software that is useful to the programmer and/to some set of users who are directly involved in defining its requirements. Programming System, are programs intended to be reused as parts of larger systems. It is a code usable by anyone Programming Product, In theory, all commercial applications and mature bespoke (custom-made) applications are programming products. It is a code that tested, documented, maintained, ready to be marketed. Programming System Product, It has all the behavior of both a programming product and a programming system. It is useful to a wide range of users and can be effectively extended and/or embedded for the creation of larger systems. It involved a continual effort of development team over time. Microsoft office suite and Microsoft Project.

29. Scale of project size effort

30. causes of project failure According to Brooks First, techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well. Second, estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. Third, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering. Fourth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like putting off a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster. Fifth, Scheduling tendency to assume all will go well

31. impact of adding people partitionable project –Independent activities, adding more people will help but not at a proportional rate. non-partitionable project –Activities are inter-related and need to be coordinated, no benefit at all from adding people, this is true for most of IS project. complex interactions - must separately coordinate each task with all others –first few have declining marginal contribution –after some number, adding people slows down project

32. software project activities testing is the activity most difficult to predict –planning 1/3 of project –coding1/6 of project –component testing1/4 of project –system testing 1/4 of project most projects are on schedule UNTIL TESTING Brooks’s Law: Adding manpower to a late project makes it later

33. programmer productivity There is wide variation in productivity between good and fair programmers The concept of surgical team was proposed. A surgical team assigned to specific system task, and should not consist of more than 10 people.

34. Estimate types Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value. Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value. Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value. Budget estimate, Early in the planning phase, top down estimate, -10 percent to + 25percent. Definitive estimate, late in the planning phase (?), bottom up estimate, -5 percent to +10 percent.

35. Software Estimation Methods Estimated cost Software estimation is very difficult. The of one real software project was reported to vary by almost 800% using 12 different software estimation models duration is exponential (bigger jobs take more than proportionally longer) –analogous to run 100 meters, running 1 kilometer. one manager noted programming taking twice as long as estimate –only getting 20 hours of work/week –machine down, divert to emergencies, meetings, paperwork, sick

36. Quotes…. Failure is not an option. As always, victory finds a hundred fathers but defeat is always an orphan. Sweat plus sacrifice equals success. A life without mistakes is a mistake within itself. To give anything less than your best is to sacrifice the gift.

37. Source lines of code (SLOC) SLOC is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced. There are two major types of SLOC measures: physical and logical.

38. Disadvantages of SLOC SLOC is particularly ineffective at comparing programs written in different languages unless adjustment factors are applied to normalize languages, also skilled developers may be able to develop the same functionality with far less code,

39. Line of Code Operation AvgEffort/ month Budget/ 1000 Doc/ page ErrorsDefectPeople LOC 20,543 333611,194201524 KLOC1.60615,67358,1229.7842.5310.195

40. Albrecht’s Function Point Analysis Method This is a top-down method that was devised by Allan Albrecht when he worked for IBM. Albrecht was investigating programming productivity and needed some way to quantify the functional size of programs independently of the programming languages in which they had been coded. He developed the idea of function points Function Point Analysis has been proven as a reliable method for measuring the size of computer software AIMS –consistent measure –meaningful to end user function points should be easier to understand than lines of code –rules easy to apply –Can estimate based on requirements specification –independent of technology used

41. Albrecht’s System count –External user inputs –External outputs –Logical internal file –External interface file types –External inquiry types get points for every useful activity function points= information processing size x technical complexity adjustment

42. Albrecht’s System complexity tables –data elements referenced 1-4 5-15 16 or more –file types referenced 0 or 1 2 3 or more table of SIMPLE, AVERAGE, COMPLEX

43. Albrecht complexity

44. Albrecht functional multipliers SIMPLEAVERAGECOMPLEX external inputx 3x 4x 6 external outputx 4x 5x 7 logical internal filex 7x 10x 15 ext interface filex 5x 7x 10 external inquiryx 3x 4x 6 add up, get total unadjusted function points

45. Albrecht Technical Complexity Adjustment 14 general application characteristics data communicationson-line updatedistributed functions processing performancere-usability heavily used configurationinstallation easetransaction rate operational easeon-line data entrymultiple sites end user efficiencyfacilitate change not present= 0average influence= 3 insignificant influence= 1significant influence= 4 moderate influence= 2strong influence= 5 TCA = 0.65+(0.01x(total degree of influence)) Estimate effort = Total * TCA.

46. Symons’ complaints Albrecht method –alternative counting practices –weights used are questionable –large systems under-weighted (XEROX 1985: rapid drop in productivity with increasing system size) –range of points too narrow but MUCH BETTER THAN SLOC

47. Mk II Function Point Analysis modification of Albrecht use same Technical Complexity Adjustment extend general application characteristics to 19 or more weights adjusted Information Processing Size changed the most

48. logical transactions Most Entities in the system are going to have at least 5 transactions: Create, Read, Update, Delete, and List (CRUDL) logical transaction = –unique input/process/output combination triggered by unique event of interest to the user –or need to retrieve information create a customer read update an account delete List, produce monthly summary report

49. unadjusted function points UFPs =W I x # input data element types +W E x # entity types referenced +W O x # output data element types weights determined by calibration determine UFPs for system by adding UFPs for all system logical transactions assumes work directly proportional to # of data elements; size of process proportional to # data entries; weights meaningful, obtainable

50. complexity adjustment Albrecht’s method with 2 modifications: –extend general application list to 19 interfaces to other applications special security features direct access requirement for third parties special user training facilities documentation requirements TCA = 0.65 + C x (total degree of influence) where C is obtained by calibration

51. calibration by CALIBRATION Symons means fit the company’s data industry averages: W I 0.58 W E 1.66 W O 0.26

52. Mk II FPA summary obtain general understanding of the system construct a model of primary entities identify logical transactions score degree of influence of all 19 general application characteristics (plus client specific) obtain total project work-hours, calibrate calculate function points

53. Constructive Cost Model (COCOMOs) Is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity The model uses a basic formula with parameters that are derived from historical project data and current as well as future project characteristics. References to this model typically call it COCOMO 81. In 1995 COCOMO II was developed and finally published in 2000 in the book Software Cost Estimation with COCOMO II. COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern software development projects. It provides more support for modern software development processes and an updated project database. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development, code reusability, and the use of off-the-shelf software components.software development processes

54. Constructive Cost Model (COCOMOs) Computes software development effort based on program size. COCOMO formulas: - small simple software project build by small team person months = 2.4 * KLOC**1.05 = E Duration (months) = 2.5 * E** 0.38 - Intermediate software project size and complexity, build by team with mixed experience person months = 3.0 * KLOC**1.12 = E Duration (months) = 2.5 * E** 0.35 - Software project build under rigid conditions person months = 3.6 * KLOC**1.2 = E Duration (months) = 2.5 * E** 0.32

55. Quotes…. Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful If you are going to do something, do it right or do not do it at all. Failing to prepare is preparing to fail. The sin is not falling down, but staying down. I haven’t failed; I’ve found ten thousand ways that don’t work. Success is not the destination, it’s the journey. Experience is the name that everyone gives to his mistakes.

56. Quotes….. He who never fell never climbed Failures are divided into two classes: those who thought and never did, and those who did and never thought. On Negotiating Never allow a person to tell you no who doesn't have the power to say yes. On Teamwork If you always blame others for your mistakes, you will never improve.

57. Estimation Example SLOC Function Point

58. Source Lines of Code NEED DATABASE of past experience AVERAGESeffort33 months cost$361 (thousand) documentation1194 pages errors201 defects52 people4 KLOC20.543

59. Implementing LOC Estimate structured lines of code10,000 averages proportional to LOC 10/20.543 = 0.487 effort33 months  0.487 =16 cost$361 thou  0.487 =$177,000 documentation1194 pages  0.487 = 581 pp. errors201  0.487 =98 defects52  0.487 = 25 people4  0.487 =2 people

60. Function Point Calculation 1 - get count-total number of features times complexity 2 - get F i rate 14 factors (0-5), total 3 - FP = count-total  [0.65 + 0.01   F i ] 4 - multiply historical averages (623) per FP by this FP

61. 1 - get count total Complexity Weighting simple average complexproduct # user inputs__  3 + __  4 + __  6= ___ # user outputs__  4 + __  5 + __  7= ___ # user inquiries__  3 + __  4 + __  6= ___ # files__  7 + __  10+__  15= ___ # external interfaces__  5 + __  7 + __  10= ___

62. 1 - get count-total Bank accounts record system involving 36 user inputssimple complexity 5 user outputsaverage complexity 20 user inquiriessimple complexity 40 files accessedsimple complexity 3 external interfacesaverage complexity

63. 1 - get count-total Complexity Weighting simple average complexproduct 36 user inputs36  3 + __  4 + __  6= 108 5 user outputs__  4 + 5  5 + __  7= 25 20 user inquiries20  3 + __  4 + __  6= 60 40 files40  7 + __  10+__  15= 280 3 external interfaces__  5 + 3  7 + __  10= 21 TOTAL 494

64. 2 - get F i F1require reliable backup & recovery?Significant 4 F2data communications required?Moderate 2 F3distributed processing functions?Significant 4 F4performance critical?Average 3 F5run on existing, heavily utilized environment?Essential 5 F6require on-line data entry?Essential 5 F7on-line data entry from multiple operations?Incidental 1 F8master files updated on-line?No influence 0 F9inputs, outputs, files, or inquiries complex?Incidental 1 F10 internal processing complex?Incidental 1 F11 code designed to be reusable?Average 3 F12conversion and installation included in the design?Average 3 F13system designed for multiple installations in different orgs?No influence 0 F14application designed to facilitate change and ease of use?No influence 0  = 32

65. 3- Calculate FP FP = count-total  [0.65 + 0.01   F i ] = 494  [0.65 + 0.01  32 ] = 479.18

66. 4- Multiply by Historical Estimated FP479.18 averages proportional to avg 479.18/623 = 0.77 effort33 months  0.77 =25.4 cost$361 thou  0.77 =$278,000 documentation1194 pages  0.77 = 918 pp. errors201  0.77 =155 defects52  0.77 = 40 people4  0.77 =3 people

67. Summary Estimation of duration & cost key to sound project decision making Estimating software development very difficult –Can improve by Keeping records Using productivity-enhancing methods Use more off-the-shelf software –Estimation methods can become accurate if systematically applied