1. 1 Software Project Management (Lecture 9) Dr. R. Mall

2. 2 Organization of this Lecture: zIntroduction to Project Planning zSoftware Cost Estimation yCost Estimation Models ySoftware Size Metrics yEmpirical Estimation yHeuristic Estimation yCOCOMO zStaffing Level Estimation zEffect of Schedule Compression on Cost zSummary

3. 3 Introduction zMany software projects fail: ydue to faulty project management practices: xIt is important to learn different aspects of software project management.

4. 4 Introduction zGoal of software project management: yenable a group of engineers to work efficiently towards successful completion of a software project.

5. 5 Responsibility of project managers zProject proposal writing, zProject cost estimation, zScheduling, zProject staffing, zProject monitoring and control, zSoftware configuration management, zRisk management, zManagerial report writing and presentations, etc.

6. 6 Introduction zA project manager’s activities are varied. ycan be broadly classified into: xproject planning, xproject monitoring and control activities.

7. 7 Project Planning zOnce a project is found to be feasible, yproject managers undertake project planning.

8. 8 Project Planning Activities zEstimation: yEffort, cost, resource, and project duration zProject scheduling: zStaff organization: ystaffing plans zRisk handling: yidentification, analysis, and abatement procedures zMiscellaneous plans: yquality assurance plan, configuration management plan, etc.

9. 9 Project planning zRequires utmost care and attention --- commitments to unrealistic time and resource estimates result in: yirritating delays. ycustomer dissatisfaction yadverse affect on team morale xpoor quality work yproject failure.

10. 10 Sliding Window Planning zInvolves project planning over several stages: yprotects managers from making big commitments too early. yMore information becomes available as project progresses. xFacilitates accurate planning

11. 11 SPMP Document zAfter planning is complete: y Document the plans: yin a Software Project Management Plan(SPMP) document.

12. 12 Organization of SPMP Document yIntroduction (Objectives,Major Functions,Performance Issues,Management and Technical Constraints) yProject Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project Duration Estimates) yProject Resources Plan (People,Hardware and Software,Special Resources) ySchedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT Chart Representation) yRisk Management Plan (Risk Analysis,Risk Identification,Risk Estimation, Abatement Procedures) yProject Tracking and Control Plan yMiscellaneous Plans (Process Tailoring,Quality Assurance)

13. 13 Software Cost Estimation zDetermine size of the product. zFrom the size estimate, ydetermine the effort needed. zFrom the effort estimate, ydetermine project duration, and cost.

14. 14 Size Estimation Effort Estimation Cost Estimation Duration Estimation Staffing Estimation Scheduling Software Cost Estimation

15. 15 Software Cost Estimation zThree main approaches to estimation: yEmpirical yHeuristic yAnalytical

16. 16 Software Cost Estimation Techniques zEmpirical techniques: yan educated guess based on past experience. zHeuristic techniques: yassume that the characteristics to be estimated can be expressed in terms of some mathematical expression. zAnalytical techniques: yderive the required results starting from certain simple assumptions.

17. 17 Software Size Metrics zLOC (Lines of Code): ySimplest and most widely used metric. yComments and blank lines should not be counted.

18. 18 Disadvantages of Using LOC zSize can vary with coding style. zFocuses on coding activity alone. zCorrelates poorly with quality and efficiency of code. zPenalizes higher level programming languages, code reuse, etc.

19. 19 Disadvantages of Using LOC (cont...) zMeasures lexical/textual complexity only. ydoes not address the issues of structural or logical complexity. zDifficult to estimate LOC from problem description. ySo not useful for project planning

20. 20 Function Point Metric zOvercomes some of the shortcomings of the LOC metric zProposed by Albrecht in early 80's: yFP=4 #inputs + 5 #Outputs + 4 #inquiries + 10 #files + 10 #interfaces zInput: yA set of related inputs is counted as one input.

21. 21 Function Point Metric zOutput: yA set of related outputs is counted as one output. zInquiries: yEach user query type is counted. zFiles: yFiles are logically related data and thus can be data structures or physical files. zInterface: yData transfer to other systems.

22. 22 Function Point Metric (CONT.) zSuffers from a major drawback: ythe size of a function is considered to be independent of its complexity. zExtend function point metric: y Feature Point metric: yconsiders an extra parameter: xAlgorithm Complexity.

23. 23 Function Point Metric (CONT.) zProponents claim: yFP is language independent. ySize can be easily derived from problem description zOpponents claim: yit is subjective --- Different people can come up with different estimates for the same problem.

24. 24 Empirical Size Estimation Techniques zExpert Judgement: yAn euphemism for guess made by an expert. ySuffers from individual bias. zDelphi Estimation: yovercomes some of the problems of expert judgement.

25. 25 Expert judgement zExperts divide a software product into component units: ye.g. GUI, database module, data communication module, billing module, etc. zAdd up the guesses for each of the components.

26. 26 Delphi Estimation: zTeam of Experts and a coordinator. zExperts carry out estimation independently: ymention the rationale behind their estimation. ycoordinator notes down any extraordinary rationale: xcirculates among experts.

27. 27 Delphi Estimation: zExperts re-estimate. zExperts never meet each other y to discuss their viewpoints.

28. 28 Heuristic Estimation Techniques zSingle Variable Model: yParameter to be Estimated=C1(Estimated Characteristic)d1 zMultivariable Model: yAssumes that the parameter to be estimated depends on more than one characteristic. yParameter to be Estimated=C1(Estimated Characteristic)d1+ C2(Estimated Characteristic)d2+… yUsually more accurate than single variable models.

29. 29 COCOMO Model zCOCOMO (COnstructive COst MOdel) proposed by Boehm. zDivides software product developments into 3 categories: yOrganic ySemidetached yEmbedded

30. 30 COCOMO Product classes zRoughly correspond to: yapplication, utility and system programs respectively. xData processing and scientific programs are considered to be application programs. xCompilers, linkers, editors, etc., are utility programs. xOperating systems and real-time system programs, etc. are system programs.

31. 31 Elaboration of Product classes zOrganic: yRelatively small groups xworking to develop well-understood applications. zSemidetached: yProject team consists of a mixture of experienced and inexperienced staff. zEmbedded: yThe software is strongly coupled to complex hardware, or real-time systems.

32. 32 COCOMO Model (CONT.) zFor each of the three product categories: yFrom size estimation (in KLOC), Boehm provides equations to predict: xproject duration in months xeffort in programmer-months zBoehm obtained these equations: yexamined historical data collected from a large number of actual projects.

33. 33 COCOMO Model (CONT.) zSoftware cost estimation is done through three stages: yBasic COCOMO, yIntermediate COCOMO, yComplete COCOMO.

34. 34 Basic COCOMO Model (CONT.) zGives only an approximate estimation: yEffort = a1 (KLOC) a2 yTdev = b1 (Effort) b2 xKLOC is the estimated kilo lines of source code, xa1,a2,b1,b2 are constants for different categories of software products, xTdev is the estimated time to develop the software in months, xEffort estimation is obtained in terms of person months (PMs).

35. 35 Development Effort Estimation zOrganic : y Effort = 2.4 (KLOC)1.05 PM z Semi-detached: yEffort = 3.0(KLOC)1.12 PM z Embedded: yEffort = 3.6 (KLOC)1.20PM

36. 36 Development Time Estimation zOrganic: yTdev = 2.5 (Effort)0.38 Months zSemi-detached: yTdev = 2.5 (Effort)0.35 Months zEmbedded: yTdev = 2.5 (Effort)0.32 Months

37. 37 Basic COCOMO Model (CONT.)  Effort is somewhat super-linear in problem size. Effort Size Embedded Semidetached Organic

38. 38 Basic COCOMO Model (CONT.) zDevelopment time ysublinear function of product size. zWhen product size increases two times, ydevelopment time does not double. zTime taken: yalmost same for all the three product categories. Size Dev. Time Embedded Semidetached Organic 60K 18 Months 14 Months 30K

39. 39 Basic COCOMO Model (CONT.) zDevelopment time does not increase linearly with product size: yFor larger products more parallel activities can be identified: xcan be carried out simultaneously by a number of engineers.

40. 40 Basic COCOMO Model (CONT.) zDevelopment time is roughly the same for all the three categories of products: yFor example, a 60 KLOC program can be developed in approximately 18 months xregardless of whether it is of organic, semi- detached, or embedded type. yThere is more scope for parallel activities for system and application programs, xthan utility programs.

41. 41 Example zThe size of an organic software product has been estimated to be 32,000 lines of source code. zEffort = 2.4*(32) 1.05 = 91 PM zNominal development time = 2.5*(91) 0.38 = 14 months

42. 42 Intermediate COCOMO zBasic COCOMO model assumes yeffort and development time depend on product size alone. zHowever, several parameters affect effort and development time: xReliability requirements xAvailability of CASE tools and modern facilities to the developers xSize of data to be handled

43. 43 Intermediate COCOMO zFor accurate estimation, ythe effect of all relevant parameters must be considered: yIntermediate COCOMO model recognizes this fact: xrefines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers).

44. 44 Intermediate COCOMO (CONT.) zIf modern programming practices are used, yinitial estimates are scaled downwards. zIf there are stringent reliability requirements on the product : yinitial estimate is scaled upwards.

45. 45 Intermediate COCOMO (CONT.) zRate different parameters on a scale of one to three: yDepending on these ratings, xmultiply cost driver values with the estimate obtained using the basic COCOMO.

46. 46 Intermediate COCOMO (CONT.) zCost driver classes: yProduct: Inherent complexity of the product, reliability requirements of the product, etc. yComputer: Execution time, storage requirements, etc. yPersonnel: Experience of personnel, etc. yDevelopment Environment: Sophistication of the tools used for software development.

47. 47 Shortcoming of basic and intermediate COCOMO models zBoth models: yconsider a software product as a single homogeneous entity: yHowever, most large systems are made up of several smaller sub-systems. xSome sub-systems may be considered as organic type, some may be considered embedded, etc. xfor some the reliability requirements may be high, and so on.

48. 48 Complete COCOMO zCost of each sub-system is estimated separately. zCosts of the sub-systems are added to obtain total cost. zReduces the margin of error in the final estimate.

49. 49 Complete COCOMO Example zA Management Information System (MIS) for an organization having offices at several places across the country: yDatabase part (semi-detached) yGraphical User Interface (GUI) part (organic) yCommunication part (embedded) zCosts of the components are estimated separately: ysummed up to give the overall cost of the system.

50. 50 Halstead's Software Science zAn analytical technique to estimate: ysize, ydevelopment effort, ydevelopment time.

51. 51 Halstead's Software Science zHalstead used a few primitive program parameters ynumber of operators and operands zDerived expressions for: yover all program length, ypotential minimum volume yactual volume, ylanguage level, yeffort, and ydevelopment time.

52. 52 Staffing Level Estimation zNumber of personnel required during any development project: ynot constant. zNorden in 1958 analyzed many R&D projects, and observed: yRayleigh curve represents the number of full-time personnel required at any time.

53. 53 Rayleigh Curve zRayleigh curve is specified by two parameters: ytd the time at which the curve reaches its maximum yK the total area under the curve. zL=f(K, td) Effort Time td Rayleigh Curve

54. 54 Putnam’s Work: zIn 1976, Putnam studied the problem of staffing of software projects: yobserved that the level of effort required in software development efforts has a similar envelope. yfound that the Rayleigh-Norden curve xrelates the number of delivered lines of code to effort and development time.

55. 55 Putnam’s Work (CONT.) : zPutnam analyzed a large number of army projects, and derived the expression: L=CkK1/3td4/3 yK is the effort expended and L is the size in KLOC. ytd is the time to develop the software. yCk is the state of technology constant xreflects factors that affect programmer productivity.

56. 56 Putnam’s Work (CONT.) : zCk=2 for poor development environment yno methodology, poor documentation, and review, etc. zCk=8 for good software development environment ysoftware engineering principles used zCk=11 for an excellent environment

57. 57 Rayleigh Curve zVery small number of engineers are needed at the beginning of a project y carry out planning and specification. zAs the project progresses: ymore detailed work is required, ynumber of engineers slowly increases and reaches a peak.

58. 58 Rayleigh Curve zPutnam observed that: ythe time at which the Rayleigh curve reaches its maximum value xcorresponds to system testing and product release. yAfter system testing, xthe number of project staff falls till product installation and delivery.

59. 59 Rayleigh Curve zFrom the Rayleigh curve observe that: yapproximately 40% of the area under the Rayleigh curve is to the left of td yand 60% to the right.

60. 60 Effect of Schedule Change on Cost zUsing the Putnam's expression for L, K=L3/Ck3td4 Or, K=C1/td4 zFor the same product size, C1=L3/Ck3 is a constant. K1/K2 = td24/td14 zOr, K1/K2 = td24/td14

61. 61 Effect of Schedule Change on Cost (CONT.) zObserve: ya relatively small compression in delivery schedule xcan result in substantial penalty on human effort. zAlso, observe: ybenefits can be gained by using fewer people over a somewhat longer time span.

62. 62 Example zIf the estimated development time is 1 year, then in order to develop the product in 6 months, ythe total effort and hence the cost increases 16 times. yIn other words, xthe relationship between effort and the chronological delivery time is highly nonlinear.

63. 63 Effect of Schedule Change on Cost (CONT.) zPutnam model indicates extreme penalty for schedule compression yand extreme reward for expanding the schedule. zPutnam estimation model works reasonably well for very large systems, ybut seriously overestimates the effort for medium and small systems.

64. 64 Effect of Schedule Change on Cost (CONT.) zBoehm observed: y“There is a limit beyond which the schedule of a software project cannot be reduced by buying any more personnel or equipment.” yThis limit occurs roughly at 75% of the nominal time estimate.

65. 65 Effect of Schedule Change on Cost (CONT.) zIf a project manager accepts a customer demand to compress the development time by more than 25% yvery unlikely to succeed. xevery project has only a limited amount of parallel activities xsequential activities cannot be speeded up by hiring any number of additional engineers. xmany engineers have to sit idle.

66. 66 Jensen Model zJensen model is very similar to Putnam model. yattempts to soften the effect of schedule compression on effort ymakes it applicable to smaller and medium sized projects.

67. 67 Jensen Model zJensen proposed the equation: yL=CtetdK1/2 yWhere, xCte is the effective technology constant, xtd is the time to develop the software, and xK is the effort needed to develop the software.

68. 68 Organization Structure zFunctional Organization: yEngineers are organized into functional groups, e.g. xspecification, design, coding, testing, maintenance, etc. yEngineers from functional groups get assigned to different projects

69. 69 Advantages of Functional Organization zSpecialization zEase of staffing zGood documentation is produced ydifferent phases are carried out by different teams of engineers. zHelps identify errors earlier.

70. 70 Project Organization zEngineers get assigned to a project for the entire duration of the project ySame set of engineers carry out all the phases zAdvantages: yEngineers save time on learning details of every project. yLeads to job rotation

71. 71 Team Structure zProblems of different complexities and sizes require different team structures: yChief-programmer team yDemocratic team yMixed organization

72. 72 Democratic Teams zSuitable for: ysmall projects requiring less than five or six engineers yresearch-oriented projects zA manager provides administrative leadership: yat different times different members of the group provide technical leadership.

73. 73 Democratic Teams zDemocratic organization provides yhigher morale and job satisfaction to the engineers y therefore leads to less employee turnover. zSuitable for less understood problems, ya group of engineers can invent better solutions than a single individual.

74. 74 Democratic Teams zDisadvantage: yteam members may waste a lot time arguing about trivial points: xabsence of any authority in the team.

75. 75 Chief Programmer Team zA senior engineer provides technical leadership: ypartitions the task among the team members. yverifies and integrates the products developed by the members.

76. 76 Chief Programmer Team zWorks well when ythe task is well understood xalso within the intellectual grasp of a single individual, yimportance of early completion outweighs other factors xteam morale, personal development, etc.

77. 77 Chief Programmer Team zChief programmer team is subject to single point failure: ytoo much responsibility and authority is assigned to the chief programmer.

78. 78 Mixed Control Team Organization zDraws upon ideas from both: ydemocratic organization and ychief-programmer team organization. zCommunication is limited yto a small group that is most likely to benefit from it. zSuitable for large organizations.

79. 79 Team Organization Chief Programmer team Democratic Team

80. 80 Mixed team organization

81. 81 Summary zWe discussed the broad responsibilities of the project manager: yProject planning yProject Monitoring and Control

82. 82 Summary zTo estimate software cost: yDetermine size of the product. yUsing size estimate, xdetermine effort needed. yFrom the effort estimate, xdetermine project duration, and cost.

83. 83 Summary (CONT.) zCost estimation techniques: yEmpirical Techniques yHeuristic Techniques yAnalytical Techniques zEmpirical techniques: ybased on systematic guesses by experts. xExpert Judgement xDelphi Estimation

84. 84 Summary (CONT.) zHeuristic techniques: yassume that characteristics of a software product can be modeled by a mathematical expression. yCOCOMO zAnalytical techniques: yderive the estimates starting with some basic assumptions: yHalstead's Software Science

85. 85 Summary (CONT.) zThe staffing level during the life cycle of a software product development: yfollows Rayleigh curve ymaximum number of engineers required during testing.

86. 86 Summary (CONT.) zRelationship between schedule change and effort: yhighly nonlinear. zSoftware organizations are usually organized in: yfunctional format yproject format

87. 87 Summary (CONT.) zProject teams can be organized in following ways: yChief programmer: suitable for routine work. yDemocratic: Small teams doing R&D type work yMixed: Large projects