Software Project Management1 Organization of this Lecture: • Introduction to Project Planning • Software Cost Estimation – Cost Estimation Models – Software Size Metrics – Empirical Estimation – Heuristic Estimation – COCOMO • Staffing Level Estimation 2 Introduction • Goal of software project management: – Enable developers to work efficiently towards successful completion of a software project. 3 Responsibility of project managers • • • • • • • Project proposal writing, Project cost estimation, Scheduling, Project staffing, Project monitoring and control, Risk management, Managerial report writing and presentations. 4 • project monitoring and control. 5 .Introduction • A project manager’s activities can be broadly classified into: • project planning. – project managers undertake project planning.Project Planning • Once a project is found to be feasible. 6 . 7 .Project Planning Activities • Estimation: – Effort. resource. and project duration • Project scheduling: • Staff organization: – staffing plans • Risk handling: – identification. cost. assessment and containment. Project planning • Requires utmost care and attention --commitments to unrealistic time and resource estimates result in: – – – – unexpected delay customer dissatisfaction poor quality work project failure 8 . SPMP Document • After planning is complete: – Document the plans: – in a Software Project Management Plan(SPMP) document. 9 . Organization of SPMP Document – – – – – – Introduction Project Estimates Project Resources Schedules Risk Management Plan Project Tracking and Control Plan 10 . 11 . • From the effort estimate.Software Cost Estimation • Determine size of the product. • From the size estimate. – determine project duration and cost. – determine the effort needed. Software Cost Estimation Effort Estimation Cost Estimation Project Staffing Size Estimation Duration Estimation Scheduling 12 . Software Cost Estimation • Three main approaches to estimation: – Empirical – Heuristic – Analytical 13 . • Analytical techniques: – derive the required results starting from certain simple assumptions. 14 . • Heuristic techniques: – the parameters to be estimated can be expressed in terms of some mathematical expression.Software Cost Estimation Techniques • Empirical techniques: – an educated guess based on past experience. Software Cost Estimation Techniques • Empirical techniques: – Expert Judgement Technique. 15 . – Delphi Cost Estimation. • Analytical techniques: – Halstead’s Software Science. • Heuristic techniques: – COCOMO. 16 . Comments and blank lines should not be counted.Software Size Metrics LOC (Lines of Code): Simplest and popular metric. 17 . • Penalizes higher level programming languages. • Focuses on coding activity alone. etc. code reuse.Disadvantages of Using LOC • Size can vary with coding style. • Correlates poorly with quality and efficiency of code. (cont..Disadvantages of Using LOC • Difficult to estimate LOC from problem specification..) 18 . 19 . • Delphi Estimation: – overcomes some of the problems of expert judgement.Empirical Size Estimation Techniques • Expert Judgement: – An expert makes an educated guess of the problem size. – Suffers from individual bias. Expert judgement • Experts divide a software product into component units: – e. 20 . GUI. database module.g. data communication module. • Add up the guesses for each of the components. etc. Delphi Estimation: • Team of Experts and a coordinator. • Experts carry out estimation independently. 21 . Heuristic Estimation Techniques COCOMO 22 . • Divides software product developments into 3 categories: – Organic – Semidetached – Embedded 23 .COCOMO Model • COCOMO (COnstructive COst MOdel) proposed by Boehm. • Embedded: – The software is strongly coupled to real-time systems. 24 .Elaboration of Product classes • Organic: – Relatively small groups • working to develop well-understood applications. • Semidetached: – Project team consists of a mixture of experienced and inexperienced staff. 25 . Boehm provides equations to predict: • effort in Person-Months • project duration in Months • Boehm obtained these equations: – examined historical data collected from a large number of actual projects.COCOMO Model (CONT.) • For each of the three product categories: – From size estimation (in KLOC). 26 . – Complete COCOMO.) • Software cost estimation is done through three stages: – Basic COCOMO. – Intermediate COCOMO.COCOMO Model (CONT. .Basic COCOMO A static single-valued model that computes software development effort (and cost) as a function of program size expressed in lines of code. Intermediate COCOMO Computes software development effort as a function of program size and a set of "cost drivers“. Complete COCOMO Incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, ...) of the software engineering process. Basic COCOMO Model Gives only an approximate estimation: Effort = a1 * (KLOC)a2 Tdev = b1 * (Effort)b2 30 Development Effort Estimation • Organic : – Effort = 2.4 (KLOC)1.05 PM • Semi-detached: – Effort = 3.0(KLOC)1.12 PM • Embedded: – Effort = 3.6 (KLOC)1.20PM 31 35 Months • Embedded: – Tdev = 2.32 Months 32 .5 (Effort)0.38 Months • Semi-detached: – Tdev = 2.5 (Effort)0.Development Time Estimation • Organic: – Tdev = 2.5 (Effort)0. Basic COCOMO Model (CONT.) Effort Size 33 . ) 18 Months 14 Months 30K 60K Size 34 . Time (CONT.Basic COCOMO Model Dev. ) • Development time does not increase linearly with product size.Basic COCOMO Model (CONT. 35 . Development time. If the average salary of software developers is Rs. 15000 per month. Find out the Effort.Example • The size of an organic software product has been estimated to be 32. 36 .000 lines of source code. then determine the cost to develop the product. Solution • Effort = 2. 13.5 x (91)0.65.05 = 91 PM • Tdev = 2.4 x (32)1.38 = 14 months • Cost = 91 x 15000= Rs.000 37 . Find out the effort. 38 .Example • The size of a semi-detached software product has been estimated to be 33. development time and recommended number of people for the product.360 lines of source code. 39 . • However.Intermediate COCOMO • Basic COCOMO model assumes – effort and development time depend on product size alone. several parameters affect effort and development time: • Software reliability • Software complexity • Programmer capability. etc. Intermediate COCOMO • For accurate estimation. – the effect of all relevant parameters must be considered: – Intermediate COCOMO model recognizes this fact: • refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers. 40 . 41 . • multiply cost driver values with the estimate obtained using the Basic COCOMO.Intermediate COCOMO • Rate different parameters on a scale of 1 to 3: – Depending on these ratings. Intermediate COCOMO • Cost driver classes: – Product: Complexity of the product. reliability of the product. – Development Environment: Sophistication of the tools used for software development. etc. etc. etc. – Personnel: Experience of personnel. storage requirements. – Computer: Execution time. 42 . 88. Find out the Effort. 1.40 product. If the multiplying factors for reliability are 0. 43 .00.Example • The size of an organic software product has been estimated to be 45. Development time.75. 1. 1.15. 0.000 lines of source code. Shortcoming of Basic and Intermediate COCOMO models • Both models: – consider a software product as a single homogeneous entity: – However. 44 . • for some the reliability requirements may be high. • Some sub-systems may be considered as organic type. and so on. etc. some may be considered embedded. most large systems are made up of several smaller sub-systems. Complete COCOMO • Cost of each sub-system is estimated separately. • Costs of the sub-systems are added to obtain total cost. 45 . • Reduces the margin of error in the final estimate. 46 .Complete COCOMO Example • A Management Information System (MIS) for an organization having offices at several places across the country: – Database part (semi-detached) – GUI part (organic) – Communication part (embedded) • Costs of the components are estimated separately: – summed up to give the overall cost of the system. – development time. 47 .Halstead's Software Science • An analytical technique to estimate: – size. – development effort. Halstead's Software Science Halstead used a few primitive program parameters number of operators and operands 48 . (η=η1+η2) Program volume. Effort.Halstead's Software Science Derived expressions for: Program length. 49 . Language level. (N=N1+N2) Program vocabulary. (V=Nlog2η) Potential minimum volume. and Development time. Halstead's Software Science Operators??? Operands??? 50 . &a. c. b. avg .Halstead's Software Science Let us consider the following C program: main() { int a. printf(“avg= %d”. scanf(“%d %d %d”.&b. } 51 . avg).&c). avg=(a+b+c)/3. +.Halstead's Software Science Operators: main. &. 3. avg=%d. (η2=11) 52 . (). a+b+c. {}.. printf.. . b. =. &b. scanf. &c. /. c. . avg. %d%d%d. (η1=12) Operands: a. int. &a. 53 . Program vocabulary. Program volume.Halstead's Software Science Determine: Program length. and observed: – Rayleigh curve represents the number of full-time personnel required at any time. • Norden in 1958 analyzed many R&D projects. 54 .Staffing Level Estimation • Number of personnel required during any development project: – not constant. Rayleigh Curve Effort td Time L=f(K.Rayleigh Curve Rayleigh curve is specified by two parameters: td the time at which the curve reaches its maximum K the total area under the curve. td) 55 . – found that the Rayleigh-Norden curve • relates the number of delivered lines of code to effort and development time.Putnam’s Work: • In 1976. 56 . Putnam studied the problem of staffing of software projects: – observed that the level of effort required in software development efforts has a similar envelope. Ck is the state of technology constant reflects factors that affect programmer productivity. and derived the expression: L=CkK1/3td4/3 K is the effort expended and L is the size in KLOC.) : Putnam analyzed a large number of army projects. td is the time to develop the software.Putnam’s Work (CONT. 57 . Putnam’s Work (CONT. poor documentation. • Ck=8 for good software development environment – software engineering principles used • Ck=11 for an excellent environment 58 .) : • Ck=2 for poor development environment – no methodology. etc. and review. 59 . – number of engineers slowly increases and reaches a peak. • As the project progresses: – more detailed work is required.Rayleigh Curve • Very small number of engineers are needed at the beginning of a project – carry out planning and specification. – After system testing.Rayleigh Curve • Putnam observed that: – the time at which the Rayleigh curve reaches its maximum value • corresponds to system testing and product release. • the number of project staff falls till product installation and delivery. 60 . Rayleigh Curve • From the Rayleigh curve observe that: – approximately 40% of the area under the Rayleigh curve is to the left of td – and 60% to the right. 61 . Effect of Schedule Change on Cost Using the Putnam's expression for L. Or. K=L3/Ck3td4 Or. K1/K2 = td24/td14 62 . K=C1/td4 For the same product size. C1=L3/Ck3 is a constant. ) Also. observe: benefits can be gained by using fewer people over a somewhat longer time span.Effect of Schedule Change on Cost Observe: a relatively small compression in delivery schedule can result in substantial penalty on human effort. 63 . (CONT. then in order to develop the product in 6 months. 64 . • the relationship between effort and the chronological delivery time is highly nonlinear. – the total effort and hence the cost increases 16 times. – In other words.Example • If the estimated development time is 1 year. • Putnam estimation model works reasonably well for very large systems.Effect of Schedule Change on Cost (CONT. 65 . – but seriously overestimates the effort for medium and small systems.) • Putnam model indicates extreme penalty for schedule compression – and extreme reward for expanding the schedule. Effect of Schedule Change on Cost • Boehm observed: (CONT.” – This limit occurs roughly at 75% of the nominal time estimate.) – “There is a limit beyond which the schedule of a software project cannot be reduced by buying any more personnel or equipment. 66 . Effect of Schedule Change on Cost • If a project manager accepts a customer demand to compress the development time by more than 25% – very unlikely to succeed. • every project has only a limited amount of parallel activities • sequential activities cannot be speeded up by hiring any number of additional engineers. • many engineers have to sit idle. (CONT.) 67 . – attempts to soften the effect of schedule compression on effort – makes it applicable to smaller and medium sized projects. 68 .Jensen Model • Jensen model is very similar to Putnam model. and • K is the effort needed to develop the software.Jensen Model • Jensen proposed the equation: – L=CtetdK1/2 – Where. 69 . • Cte is the effective technology constant. • td is the time to develop the software. g. testing. coding. e. maintenance.Organization Structure • Functional Organization: – Engineers are organized into functional groups. – Engineers from functional groups get assigned to different projects 70 . etc. • specification. design. 71 .Advantages of Functional Organization • Specialization • Ease of staffing • Good documentation is produced – different phases are carried out by different teams of engineers. • Helps identify errors earlier. Project Organization • Engineers get assigned to a project for the entire duration of the project – Same set of engineers carry out all the phases • Advantages: – Engineers save time on learning details of every project. – Leads to job rotation 72 . Team Structure • Problems of different complexities and sizes require different team structures: – Chief-programmer team – Democratic team – Mixed organization 73 . Democratic Teams Suitable for: small projects requiring less than five or six engineers research-oriented projects A manager provides administrative leadership: at different times different members of the group provide technical leadership. 74 . – a group of engineers can invent better solutions than a single individual. • Suitable for less understood problems. 75 .Democratic Teams • Democratic organization provides – higher morale and job satisfaction to the engineers – therefore leads to less employee turnover. Democratic Teams • Disadvantage: – team members may waste a lot time arguing about trivial points: • absence of any authority in the team. 76 . – verifies and integrates the products developed by the members. 77 .Chief Programmer Team • A senior engineer provides technical leadership: – partitions the task among the team members. Chief Programmer Team • Works well when – the task is well understood • also within the intellectual grasp of a single individual. – importance of early completion outweighs other factors • team morale. etc. 78 . personal development. Chief Programmer Team • Chief programmer team is subject to single point failure: – too much responsibility and authority is assigned to the chief programmer. 79 . Mixed Control Team Organization • Draws upon ideas from both: – democratic organization and – chief-programmer team organization. • Suitable for large organizations. 80 . • Communication is limited – to a small group that is most likely to benefit from it. Team Organization Democratic Team Chief Programmer team 81 . Mixed team organization 82 . – Democratic: Small teams doing R&D type work – Mixed: Large projects 83 .) • Project teams can be organized in following ways: – Chief programmer: suitable for routine work.Summary (CONT.