Lecture Software process improvement: Lesson 30B - Dr. Ghulam Ahmad Farrukh

Lecture Software process improvement: Lesson 30B provide students with knowledge about: software baselines; the development of software; software benchmarks; baselines collect similar data; baselines collect quantitative;... Please refer to the detailed content of the lecture!

Lecture # 30­B

• A baseline is a milestone in the 

development of software

• Software benchmarks and baselines collect  similar data

• Baselines compare a company against its 

own history for several years in the past

• Baselines collect quantitative and 

topics, including investments, staffing 

levels, development schedules, staff efforts,  costs, quality, and customer satisfaction

• Software baselines are normally used as a  starting points when beginning process 

improvement programs

• Accurate baseline provides a firm 

quantitative basis for productivity, 

schedules, costs, quality, and user 

satisfaction to judge rate of improvement

• Another very common use of baselines is  when outsource agreements include a 

contractual obligation for the vendor to 

improve quality or productivity

• Baselines are technically very challenging  and difficult to create with acceptable 

accuracy

• This is because most companies do not 

routinely collect accurate quality and 

productivity data. In fact most companies 

don’t even collect accurate cost data on how  much they spend on software projects

• In addition to the fact that the effort and 

costs for many activities are incomplete, 

there are several other significant cost 

elements that are seldom recorded at all

• One of the most important missing pieces of  information is the amount of unpaid 

overtime applied to software projects. This 

is very important factor for international 

software comparisons

• Another missing piece of information is the  work that software clients themselves 

perform during development cycles

• Because leakage is so common, initial 

baselines are often very unrealistic

• For example, if a software organization’s 

actual productivity is 5.0 FPs per staff 

months but their cost tracking system only  captures low­level design, coding, and 

testing costs, their apparent productivity 

might look like 15.0 FPs per staff months

• Many software cost tracking systems omit 

requirements, high­level design, project 

management, creation of user manuals and 

documents, and the work of specialists in areas  such as software quality assurance, database 

administration, change control, and 

administrative support

• Sometimes, the activities omitted actually 

• The bottom line is that the baselines are 

very challenging to create well and 

accurately

• If they are going to serve a purpose in 

contracts between outsource vendors and 

clients without leading to litigation, then 

baselines need to be accurate and reliable

Summary

• Software Assessments, Benchmarks, and 

Best Practices by Capers Jones (Chapter 3)