Software Project Management Lecture 9 Dr R Mall

  • Slides: 87
Download presentation
Software Project Management (Lecture 9) Dr. R. Mall 1

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

Organization of this Lecture: z Introduction to Project Planning z Software Cost Estimation y

Organization of this Lecture: z Introduction to Project Planning z Software Cost Estimation y Cost Estimation Models y Software Size Metrics y Empirical Estimation y Heuristic Estimation y COCOMO z Staffing Level Estimation z Effect of Schedule Compression on Cost z Summary 2

Introduction z. Many software projects fail: ydue to faulty project management practices: x. It

Introduction z. Many software projects fail: ydue to faulty project management practices: x. It is important to learn different aspects of software project management. 3

Introduction z. Goal of software project management: yenable a group of engineers to work

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

Responsibility of project managers z Project proposal writing, z Project cost estimation, z Scheduling,

Responsibility of project managers z Project proposal writing, z Project cost estimation, z Scheduling, z Project staffing, z Project monitoring and control, z Software configuration management, z Risk management, z Managerial report writing and presentations, etc. 5

Introduction z. A project manager’s activities are varied. ycan be broadly classified into: xproject

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

Project Planning z. Once a project is found to be feasible, yproject managers undertake

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

Project Planning Activities z. Estimation: y. Effort, cost, resource, and project duration z. Project

Project Planning Activities z. Estimation: y. Effort, cost, resource, and project duration z. Project scheduling: z. Staff organization: ystaffing plans z. Risk handling: yidentification, analysis, and abatement procedures z. Miscellaneous plans: yquality assurance plan, configuration management plan, etc. 8

Project planning z. Requires utmost care and attention --commitments to unrealistic time and resource

Project planning z. Requires 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. 9

Sliding Window Planning z. Involves project planning over several stages: yprotects managers from making

Sliding Window Planning z. Involves project planning over several stages: yprotects managers from making big commitments too early. y. More information becomes available as project progresses. x. Facilitates accurate planning 10

SPMP Document z. After planning is complete: y Document the plans: yin a Software

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

Organization of SPMP Document y. Introduction (Objectives, Major Functions, Performance Issues, Management and Technical

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

Software Cost Estimation z. Determine size of the product. z. From the size estimate,

Software Cost Estimation z. Determine size of the product. z. From the size estimate, ydetermine the effort needed. z. From the effort estimate, ydetermine project duration, and cost. 13

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

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

Software Cost Estimation z. Three main approaches to estimation: y. Empirical y. Heuristic y.

Software Cost Estimation z. Three main approaches to estimation: y. Empirical y. Heuristic y. Analytical 15

Software Cost Estimation Techniques z. Empirical techniques: yan educated guess based on past experience.

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

Software Size Metrics z. LOC (Lines of Code): y. Simplest and most widely used

Software Size Metrics z. LOC (Lines of Code): y. Simplest and most widely used metric. y. Comments and blank lines should not be counted. 17

Disadvantages of Using LOC z. Size can vary with coding style. z. Focuses on

Disadvantages of Using LOC z. Size can vary with coding style. z. Focuses on coding activity alone. z. Correlates poorly with quality and efficiency of code. z. Penalizes higher level programming languages, code reuse, etc. 18

Disadvantages of Using LOC (cont. . . ) z. Measures lexical/textual complexity only. ydoes

Disadvantages of Using LOC (cont. . . ) z. Measures lexical/textual complexity only. ydoes not address the issues of structural or logical complexity. z. Difficult to estimate LOC from problem description. y. So not useful for project planning 19

Function Point Metric z. Overcomes some of the shortcomings of the LOC metric z.

Function Point Metric z. Overcomes some of the shortcomings of the LOC metric z. Proposed by Albrecht in early 80's: y. FP=4 #inputs + 5 #Outputs + 4 #inquiries + 10 #files + 10 #interfaces z Input: y. A set of related inputs is counted as one input. 20

Function Point Metric z Output: y. A set of related outputs is counted as

Function Point Metric z Output: y. A set of related outputs is counted as one output. z Inquiries: y. Each user query type is counted. z Files: y. Files are logically related data and thus can be data structures or physical files. z Interface: y. Data transfer to other systems. 21

Function Point Metric (CONT. ) z. Suffers from a major drawback: ythe size of

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

Function Point Metric (CONT. ) z. Proponents claim: y. FP is language independent. y.

Function Point Metric (CONT. ) z. Proponents claim: y. FP is language independent. y. Size can be easily derived from problem description z. Opponents claim: yit is subjective --- Different people can come up with different estimates for the same problem. 23

Empirical Size Estimation Techniques z. Expert Judgement: y. An euphemism for guess made by

Empirical Size Estimation Techniques z. Expert Judgement: y. An euphemism for guess made by an expert. y. Suffers from individual bias. z. Delphi Estimation: yovercomes some of the problems of expert judgement. 24

Expert judgement z. Experts divide a software product into component units: ye. g. GUI,

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

Delphi Estimation: z. Team of Experts and a coordinator. z. Experts carry out estimation

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

Delphi Estimation: z. Experts re-estimate. z. Experts never meet each other y to discuss

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

Heuristic Estimation Techniques z. Single Variable Model: y. Parameter to be Estimated=C 1(Estimated Characteristic)d

Heuristic Estimation Techniques z. Single Variable Model: y. Parameter to be Estimated=C 1(Estimated Characteristic)d 1 z. Multivariable Model: y. Assumes that the parameter to be estimated depends on more than one characteristic. y. Parameter to be Estimated=C 1(Estimated Characteristic)d 1+ C 2(Estimated Characteristic)d 2+… y. Usually more accurate than single variable models. 28

COCOMO Model z. COCOMO (COnstructive COst MOdel) proposed by Boehm. z. Divides software product

COCOMO Model z. COCOMO (COnstructive COst MOdel) proposed by Boehm. z. Divides software product developments into 3 categories: y. Organic y. Semidetached y. Embedded 29

COCOMO Product classes z. Roughly correspond to: yapplication, utility and system programs respectively. x.

COCOMO Product classes z. Roughly correspond to: yapplication, utility and system programs respectively. x. Data processing and scientific programs are considered to be application programs. x. Compilers, linkers, editors, etc. , are utility programs. x. Operating systems and real-time system programs, etc. are system programs. 30

Elaboration of Product classes z. Organic: y. Relatively small groups xworking to develop well-understood

Elaboration of Product classes z. Organic: y. Relatively small groups xworking to develop well-understood applications. z. Semidetached: y. Project team consists of a mixture of experienced and inexperienced staff. z. Embedded: y. The software is strongly coupled to complex hardware, or real-time systems. 31

COCOMO Model (CONT. ) z. For each of the three product categories: y. From

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

COCOMO Model (CONT. ) z. Software cost estimation is done through three stages: y.

COCOMO Model (CONT. ) z. Software cost estimation is done through three stages: y. Basic COCOMO, y. Intermediate COCOMO, y. Complete COCOMO. 33

Basic COCOMO Model (CONT. ) z. Gives only an approximate estimation: y. Effort =

Basic COCOMO Model (CONT. ) z. Gives only an approximate estimation: y. Effort = a 1 (KLOC)a 2 y. Tdev = b 1 (Effort)b 2 x. KLOC is the estimated kilo lines of source code, xa 1, a 2, b 1, b 2 are constants for different categories of software products, x. Tdev is the estimated time to develop the software in months, x. Effort estimation is obtained in terms of person months (PMs). 34

Development Effort Estimation z. Organic : y Effort = 2. 4 (KLOC)1. 05 PM

Development Effort Estimation z. Organic : y Effort = 2. 4 (KLOC)1. 05 PM z Semi-detached: y. Effort = 3. 0(KLOC)1. 12 PM z Embedded: y. Effort = 3. 6 (KLOC)1. 20 PM 35

Development Time Estimation z. Organic: y. Tdev = 2. 5 (Effort)0. 38 Months z.

Development Time Estimation z. Organic: y. Tdev = 2. 5 (Effort)0. 38 Months z. Semi-detached: y. Tdev = 2. 5 (Effort)0. 35 Months z. Embedded: y. Tdev = 2. 5 (Effort)0. 32 Months 36

Basic COCOMO Model z. Effort is somewhat super -linear in problem size. (CONT. )

Basic COCOMO Model z. Effort is somewhat super -linear in problem size. (CONT. ) ed et Effort m Se d de d e b Em id h ac nic a g Or Size 37

Basic COCOMO Model (CONT. ) z Development time ysublinear function of Dev. Time product

Basic COCOMO Model (CONT. ) z Development time ysublinear function of Dev. Time product size. z When product size increases two times, ydevelopment time does not double. z Time taken: yalmost same for all the three product categories. ed ed h d c a d be emidet m E S 18 Months 14 Months nic a g r O 30 K Size 60 K 38

Basic COCOMO Model (CONT. ) z. Development time does not increase linearly with product

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

Basic COCOMO Model (CONT. ) z. Development time is roughly the same for all

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

Example z The size of an organic software product has been estimated to be

Example z The size of an organic software product has been estimated to be 32, 000 lines of source code. z Effort = 2. 4*(32)1. 05 = 91 PM z Nominal development time = 2. 5*(91)0. 38 = 14 months 41

Intermediate COCOMO z. Basic COCOMO model assumes yeffort and development time depend on product

Intermediate COCOMO z. Basic COCOMO model assumes yeffort and development time depend on product size alone. z. However, several parameters affect effort and development time: x. Reliability requirements x. Availability of CASE tools and modern facilities to the developers x. Size of data to be handled 42

Intermediate COCOMO z. For accurate estimation, ythe effect of all relevant parameters must be

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

Intermediate COCOMO (CONT. ) z. If modern programming practices are used, yinitial estimates are

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

Intermediate COCOMO (CONT. ) z. Rate different parameters on a scale of one to

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

Intermediate COCOMO (CONT. ) z. Cost driver classes: y. Product: Inherent complexity of the

Intermediate COCOMO (CONT. ) z. Cost driver classes: y. Product: Inherent complexity of the product, reliability requirements of the product, etc. y. Computer: Execution time, storage requirements, etc. y. Personnel: Experience of personnel, etc. y. Development Environment: Sophistication of the tools used for software development. 46

Shortcoming of basic and intermediate COCOMO models z. Both models: yconsider a software product

Shortcoming of basic and intermediate COCOMO models z. Both models: yconsider a software product as a single homogeneous entity: y. However, most large systems are made up of several smaller sub-systems. x. Some 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. 47

Complete COCOMO z. Cost of each sub-system is estimated separately. z. Costs of the

Complete COCOMO z. Cost of each sub-system is estimated separately. z. Costs of the sub-systems are added to obtain total cost. z. Reduces the margin of error in the final estimate. 48

Complete COCOMO Example z A Management Information System (MIS) for an organization having offices

Complete COCOMO Example z A Management Information System (MIS) for an organization having offices at several places across the country: y. Database part (semi-detached) y. Graphical User Interface (GUI) part (organic) y. Communication part (embedded) z Costs of the components are estimated separately: ysummed up to give the overall cost of the system. 49

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

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

Halstead's Software Science z. Halstead used a few primitive program parameters ynumber of operators

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

Staffing Level Estimation z. Number of personnel required during any development project: ynot constant.

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

Rayleigh Curve z Rayleigh curve is specified by two parameters: Effort ytd the time

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

Putnam’s Work: z. In 1976, Putnam studied the problem of staffing of software projects:

Putnam’s Work: z. In 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. 54

Putnam’s Work (CONT. ) : z. Putnam analyzed a large number of army projects,

Putnam’s Work (CONT. ) : z. Putnam analyzed a large number of army projects, and derived the expression: L=Ck. K 1/3 td 4/3 y. K is the effort expended and L is the size in KLOC. ytd is the time to develop the software. y. Ck is the state of technology constant xreflects factors that affect programmer productivity. 55

Putnam’s Work (CONT. ) : z. Ck=2 for poor development environment yno methodology, poor

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

Rayleigh Curve z. Very small number of engineers are needed at the beginning of

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

Rayleigh Curve z. Putnam observed that: ythe time at which the Rayleigh curve reaches

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

Rayleigh Curve z. From the Rayleigh curve observe that: yapproximately 40% of the area

Rayleigh Curve z. From 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. 59

Effect of Schedule Change on Cost z. Using the Putnam's expression for L, K=L

Effect of Schedule Change on Cost z. Using the Putnam's expression for L, K=L 3/Ck 3 td 4 Or, K=C 1/td 4 z. For the same product size, C 1=L 3/Ck 3 is a constant. z. Or, K 1/K 2 = td 24/td 14 60

Effect of Schedule Change on Cost (CONT. ) z. Observe: ya relatively small compression

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

Example z. If the estimated development time is 1 year, then in order to

Example z. If 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. y. In other words, xthe relationship between effort and the chronological delivery time is highly nonlinear. 62

Effect of Schedule Change on Cost (CONT. ) z. Putnam model indicates extreme penalty

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

Effect of Schedule Change on Cost (CONT. ) z. Boehm observed: y“There is a

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

Effect of Schedule Change on Cost (CONT. ) z. If a project manager accepts

Effect of Schedule Change on Cost (CONT. ) z. If 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. 65

Jensen Model z. Jensen model is very similar to Putnam model. yattempts to soften

Jensen Model z. Jensen 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. 66

Jensen Model z. Jensen proposed the equation: y. L=Ctetd. K 1/2 y. Where, x.

Jensen Model z. Jensen proposed the equation: y. L=Ctetd. K 1/2 y. Where, x. Cte is the effective technology constant, xtd is the time to develop the software, and x. K is the effort needed to develop the software. 67

Organization Structure z. Functional Organization: y. Engineers are organized into functional groups, e. g.

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

Advantages of Functional Organization z. Specialization z. Ease of staffing z. Good documentation is

Advantages of Functional Organization z. Specialization z. Ease of staffing z. Good documentation is produced ydifferent phases are carried out by different teams of engineers. z. Helps identify errors earlier. 69

Project Organization z. Engineers get assigned to a project for the entire duration of

Project Organization z. Engineers get assigned to a project for the entire duration of the project y. Same set of engineers carry out all the phases z. Advantages: y. Engineers save time on learning details of every project. y. Leads to job rotation 70

Team Structure z. Problems of different complexities and sizes require different team structures: y.

Team Structure z. Problems of different complexities and sizes require different team structures: y. Chief-programmer team y. Democratic team y. Mixed organization 71

Democratic Teams z. Suitable for: ysmall projects requiring less than five or six engineers

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

Democratic Teams z. Democratic organization provides yhigher morale and job satisfaction to the engineers

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

Democratic Teams z. Disadvantage: yteam members may waste a lot time arguing about trivial

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

Chief Programmer Team z. A senior engineer provides technical leadership: ypartitions the task among

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

Chief Programmer Team z. Works well when ythe task is well understood xalso within

Chief Programmer Team z. Works 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. 76

Chief Programmer Team z. Chief programmer team is subject to single point failure: ytoo

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

Mixed Control Team Organization z. Draws upon ideas from both: ydemocratic organization and ychief-programmer

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

Team Organization Democratic Team Chief Programmer team 79

Team Organization Democratic Team Chief Programmer team 79

Mixed team organization 80

Mixed team organization 80

Summary z. We discussed the broad responsibilities of the project manager: y. Project planning

Summary z. We discussed the broad responsibilities of the project manager: y. Project planning y. Project Monitoring and Control 81

Summary z. To estimate software cost: y. Determine size of the product. y. Using

Summary z. To estimate software cost: y. Determine size of the product. y. Using size estimate, xdetermine effort needed. y. From the effort estimate, xdetermine project duration, and cost. 82

Summary (CONT. ) z. Cost estimation techniques: y. Empirical Techniques y. Heuristic Techniques y.

Summary (CONT. ) z. Cost estimation techniques: y. Empirical Techniques y. Heuristic Techniques y. Analytical Techniques z. Empirical techniques: ybased on systematic guesses by experts. x. Expert Judgement x. Delphi Estimation 83

Summary (CONT. ) z. Heuristic techniques: yassume that characteristics of a software product can

Summary (CONT. ) z. Heuristic techniques: yassume that characteristics of a software product can be modeled by a mathematical expression. y. COCOMO z. Analytical techniques: yderive the estimates starting with some basic assumptions: y. Halstead's Software Science 84

Summary (CONT. ) z. The staffing level during the life cycle of a software

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

Summary (CONT. ) z. Relationship between schedule change and effort: yhighly nonlinear. z. Software

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

Summary (CONT. ) z. Project teams can be organized in following ways: y. Chief

Summary (CONT. ) z. Project teams can be organized in following ways: y. Chief programmer: suitable for routine work. y. Democratic: Small teams doing R&D type work y. Mixed: Large projects 87