Presentation is loading. Please wait.

Presentation is loading. Please wait.

Estimation – Software Projects project planning - what to do project control make sure it’s done right estimation of detailed system design.

Similar presentations

Presentation on theme: "Estimation – Software Projects project planning - what to do project control make sure it’s done right estimation of detailed system design."— Presentation transcript:

1 Estimation – Software Projects 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 unique

3 Determine Requirements Specify work activities STATEMENT OF WORK: –product descriptions –constraints –schedule requirements –budget limits –roles & responsibilities

4 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

5 Work Breakdown Structure

6 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

7 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

8 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

9 Work Packages chunk of required work relatively small cost and short duration include –summary of work –inputs required (predecessors) –manager responsible –product specifications –resources required (including budget, dates) –deliverables

10 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

11 Work Packages need to identify start and finish events for each work package related tasks without definable end results (overhead & management; inspection; maintenance) should be included as task-oriented work packages for COST purposes

12 Project Organization identify resources required by work package RESPONSIBILITY MATRIX –which functions do what work packages –cost account structure start & finish date budget responsibilities

13 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

14 Scheduling BASIS for –RESOURCE ALLOCATION –ESTIMATED COST –plan for monitoring & control EVENTS or MILESTONES –when activity completed (or started) –INTERFACE EVENT when responsibility passes

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

16 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

17 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

18 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

19 Software Estimation The Mythical Man-Month: Essays on Software Engineering Frederick P. Brooks, Jr. (U N. Carolina) Addison-Wesley: 1975

20 Programming Products Program –usable by author Programming System –usable by anyone Programming Product –tested, documented, maintained –3 times the effort of a program Programming System Product

21 causes of project failure LACK OF CALENDAR TIME the most common –estimating techniques are poor –assume that effort = progress you can’t just throw people at a problem –poor monitoring of progress SCHEDULING –tendency to assume all will go well

22 impact of adding people partitionable project –marginal contribution declines non-partitionable project –no benefit at all from adding people complex interactions must separately coordinate each task with all others –first few have declining marginal contribution –after some number, adding people slows down project

23 Software Project Activities testing is the activity most difficult to predict –planning1/3 of project –coding1/6 of project –component testing1/4 of project –system testing1/4 of project most projects are on schedule UNTIL TESTING Brooks’s Law: Adding manpower to a late project makes it later

24 programmer productivity there is wide variation in productivity between good and fair programmers Brute force failures –costlyOS/360TSS –slowExec 8SAGE –inefficientScope 6600 –nonintegrated systemsMultics

25 impact of adding programmers if a 200 person project has its best 25 people as managers –fire the 175 –make the 25 managers programmers shouldn’t have more than 10 people on a team OS/360 had 1000 working on it, 5000 man-years small teams infeasible; use surgical teams

26 surgical team surgeonchief programmer copilotshare thinking, evaluation administratorboring details editorreferences, documentation secretaries (2) program clerktechnical records toolsmithediting, debugging testerdevelop test cases language lawyerexpert on language

27 conceptual integrity better to reflect one set of design ideas than to add independent and uncoordinated features & improvements purpose of programming system is to make computer easy to use simplicity & straightforwardness come from conceptual integrity

28 conceptual integrity example OS/360 –architect manager: said his 10 person team could write specifications in 10 months (3 months late) –control program manager: his 150 people could get it done in 7 months, & if his people didn’t do this, they would have nothing to do –architect manager: control program people would take 10 months, do a poor job –Brooks gave to control program group –took 10 months, plus added year to debugging

29 estimating programming time duration is exponential (bigger jobs take more than proportionally longer) –analogous to sprint 100 yards, running 1 mile effort = K x (number of instructions) 1.5 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

30 programming estimation the more interactions, the less productivity –interaction = coordination with others high level languages increase productivity –now tools should almost eliminate the programming component, but there are other activities (the more unpredictable ones)

31 (prototyping) in most projects, the first system built is barely usable PLAN THE SYSTEM FOR CHANGE –modularization –subroutining –interfaces –documentation of interfaces –high-level languages

32 software estimation Charles R. Symons Software Sizing and Estimating: Mk II FPA Wiley [1991]

33 software production cycle DESIGN DEVELOPMENT productionnot hard MAINTENANCE recognized as a difficult task

34 software production cycle SYSTEM SIZE a variable in –DESIGN –DEVELOPMENT –MAINTENANCE components of system size –amount of information processed –technical requirements –performance drivers (objectives)

35 objectives COSTminimization TIMEminimization QUALITYassure that product performs to specifications

36 size measures source lines of code + concrete measure - what lines? - logical or physical? - housekeeping? - different across languages most commonly used some economy of scale

37 Albrecht’s Function Point Analysis Method AIMS –consistent measure –meaningful to end user function points should be easier to understand than lines of code –rules easy to apply –Can estimate from requirements specification –independent of technology used

38 Albrecht’s system count –external user inputs –enquiries –outputs –master files delivered (internal & external) get points for every useful activity function points= information processing size x technical complexity adjustment

39 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

40 Albrecht complexity

41 Albrecht functional multipliers SIMPLE AVERAGE COMPLEX 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

42 Albrecht Technical Complexity Adjustment 14 general application characteristics data communicationson-line updatedistributed functions complex processingperformancere-useability 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))

43 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

44 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

45 logical transactions logical transaction = –unique input/process/output combination triggered by unique event of interest to the user –or need to retrieve information create a customer update an account enquiry produce monthly summary report

46 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

47 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

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

49 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

50 comparison SLOCAlbrechtMk II FPA accepted standard noyesyes claritypotentiallysome subjectiveobjective structured?nonoyes easy to use?yesnono automatable?yesnoyes use for estimating?sometimesyesyes

51 Estimation Example SLOC Function Point

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

53 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

54 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

55 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= ___

56 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

57 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

58 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

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

60 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

61 Scheduling “Coding is 90% finished half of the coding time” “Debugging is 99% complete most of the time” MILESTONES: concrete events studies of government projects estimates carefully updated every 2 weeks before activity starts rarely change during activity, overestimates drop underestimates don’t change until into activity

62 Control When delay is first noticed, the tendency is to not report it STATUS INFORMATION what is going on ACTION INFORMATION learning this causes something to be done KEY: know when which case applies

63 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

Download ppt "Estimation – Software Projects project planning - what to do project control make sure it’s done right estimation of detailed system design."

Similar presentations

Ads by Google