Calling the Shot

1. Calling the Shot Presented by Peter Lane

2. How long will a system programming job take? How effort is needed? How would you estimate? 1. Coding is only one-sixth (or so) of the problem, and the errors in its estimate or in the ratios involving planning time, component test, and system testing. 2. One must say that data for building isolated small programs are not applicable to programming systems products.

3. Ex: Sackman, Erickson and Grant are make a program that averages 3200 words. The average code + debug time took about 178 hours for a single programmer, which would extrapolate to give an annual productivity of 35,800 statements per year. Meanwhile, a program half that size took less than one-fourth as long, and extrapolated productivity was nearly 80,000 statements per year. Adding the time constraints of planning, documentation, testing, system integration and training are needed in these estimations.

4. The linear extrapolations of the previous two sprint figures are meaningless. They suggest, however, that effort goes as a power of size even when no communication is involved. Effort = (constant) X (number of instructions)^1.5

5. Several studies and estimated techniques of productivity have been made. Portman Data Charles Portman, manager of ICL’s software Division, Computer Equipment Organization (Northwest) at Manchester, found his programming teams missing schedules by about one-half – each job was taking approximately twice as long as estimated. He then asked them to keep careful daily logs of time usage. These showed that the estimated error could be entirely accounted for by the fact that his team were only using 50% of working week actually programming and debugging. The rest of the time was used for machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, etc. All in all, estimates made an unrealistic assumption about the number of technical work hours per man-year.

6. Aron’s Data Joel Aron, manager of Systems Technology at IBM in Gaithersburg, Maryland, studied programmer productivity when working on nine large systems (25 programmers and 30,000 instructions). He divides the systems according to interactions among programmers. Very few instructions 10,000 instructions per man-year Some interactions 5,000 Many interactions 1,500 The man-years do not include support and system test activities; just design & programming.

7. Harr’s Data John Harr, manager for the Bell Telephone Laboratories’ Electronic Switching systems, reports his experiences. The first two jobs are basically control programs; the second two are debugged words per man-year (including programming, component & system tests). It’s not clear how much effort in the different fields is included. It is uncertain which is the cause & which is effect for the results for the two types of programs

8. OS/360 Data In IBM OS/360 experience, productivities in range of 600-800 debugged instructions per man-year were experienced by control program groups. Productivities in the 2000-3000 debugged instructions per man-year were achieved by language translator groups. These include planning, coding component test, system test and some support activities. Similar to Harr’s data. Corbato’s Data Corbatopf MIT’s project MAC reports a mean productivity of 1200 lines of debugged PL/I statements per man-year on the MULTICS system (between 1 and 2 million words) A similar (if not better) result to the other data’s. However Corbato’s is measured in lines rather than words (each statement corresponds to three to five words of code).

9. Conclusion- It is difficult to estimate the amount of effort needed and produced when programming software.-There are many known and unknown factors to include when estimating-Several studies of productivity have been made; each with similar yet different results. Any Questions?