1 / 63

Estimation – Software Projects

Estimation – Software Projects. project planning - what to do project control make sure it’s done right estimation of detailed system design. Planning Process. determine requirements from objectives specify work activities plan project organization develop schedule

hpitts
Download Presentation

Estimation – Software Projects

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. Estimation – Software Projects project planning- what to do project controlmake sure it’s done right estimationof 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. 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

  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 activity predecessor time A2 identify req’d info A1 10 days A31 basic software A2 3 days A32 data access req’d A2 1 day A33 vendor software A2 1 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 • testingis the activity most difficult to predict • planning 1/3 of project • coding 1/6 of project • component testing 1/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

  24. programmer productivity • there is wide variation in productivity between good and fair programmers • Brute force failures • costly OS/360 TSS • slow Exec 8 SAGE • inefficient Scope 6600 • nonintegrated systems Multics

  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 • surgeon chief programmer • copilot share thinking, evaluation • administrator boring details • editor references, documentation • secretaries (2) • program clerk technical records • toolsmith editing, debugging • tester develop test cases • language lawyer expert 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 • COST minimization • TIME minimization • 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 input x 3 x 4 x 6 external output x 4 x 5 x 7 logical internal file x 7 x 10 x 15 ext interface file x 5 x 7 x 10 external inquiry x 3 x 4 x 6 add up, get total unadjusted function points

  42. Albrecht Technical Complexity Adjustment 14 general application characteristics data communications on-line update distributed functions complex processing performance re-useability heavily used configuration installation ease transaction rate operational ease on-line data entry multiple sites end user efficiency facilitate change not present = 0 average influence = 3 insignificant influence = 1 significant influence = 4 moderate influence = 2 strong 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 = WI x # input data element types + WE x # entity types referenced + WO 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: WI 0.58 WE 1.66 WO 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 SLOC Albrecht Mk II FPA accepted standard no yes yes clarity potentially some subjective objective structured? no no yes easy to use? yes no no automatable? yes no yes use for estimating? sometimes yes yes

More Related