Abbreviation For Ioe In Software Project Management

PM Milestone Project Management Templates

PM Milestone 7000 Project Management Templates

Get Instant Access

One definition of a successful project is that the system is delivered 'on time and within budget and with the required quality', which implies that targets are set and the project leader then tries to meet those targets. This assumes that the targets are reasonable - the possibility of a project leaders achieving record levels of productivity from the team, but still not meeting a deadline because of incorrect initial estimates is not recognized. Realistic estimates are therefore crucial to the project leader.

What sorts of problem might a project leader such as Amanda, who is in charge of the IOE Maintenance Group Accounts project, encounter when trying to do estimates? Estimating the effort required to implement software is notoriously difficult. Some of the difficulties of estimating are inherent in the very nature of software, especially its complexity and invisibility. In addition the intensely human activities that make up system development cannot be treated in a purely mechanistic way. Other difficulties include:

In Chapter 1, the special characteristics of software identified by Brooks, i.e. complexity, conformity, changeability and invisibility, were discussed.

• Novel applications of software With traditional engineering projects, it is often the case that the system to be created is similar to one constructed previously but for a different customer or in a different location. The estimates for such a project can therefore be based on previous experience. With software, in most major projects the product will in some way be unique and will therefore be clouded with doubts and uncertainties.

• Changing technology For example, at IOE the original maintenance billing system might have been written in Cobol, while the new extension for group accounts that Amanda is directing might be developed using an application building environment such as that provided by Oracle.

• Lack of homogeneity of project experience As we will see, effective estimating should be based on information about how past projects have performed. It is surprising how many organizations do not make this data available to staff. Amanda might also find that even where the previous project data is available, it might not be that useful.

Table 5.1 is a set of figures recorded for actual projects carried out by the same organization.

Table 5.1 Some project data - effort in work months (as percentage of total effort in brackets)

The figures are taken from DesiSn Codin8 Testing

Table 5.1 Some project data - effort in work months (as percentage of total effort in brackets)

The figures are taken from DesiSn Codin8 Testing

B. A. Kitchenham and N.

Project

wm

(%)

wm

(%)

wm

(%)

wm

SLOC

R.Taylor'Software Project

a

3.9

(23)

5.3

(32)

1A

(44)

16.7

6050

Development Cost

b

2.7

(12)

13.4

(59)

6.5

(26)

22.6

8363

Estimation' in Journal of

c

3.5

(11)

26.8

(83)

1.9

(6)

32.2

13334

Systems and Software

0.8

2.4

0.7

3.9

5942

1985 (5).

d

(21)

(62)

(18)

The abbreviation SLOC

e

1.8

(10)

7.7

(44)

7.8

(45)

17.3

3315

stands for 'source lines of

f

19.0

(28)

29.7

(44)

19.0

(28)

67.7

38988

code'. SLOC is one way of

g

2.!

(21)

7.4

(74)

0.5

(5)

10.1

38614

indicating the size of a

h

1.3

(7)

12.7

(66)

5.3

(27)

19.3

12762

system.

• i

8.5

(14)

22.7

(38)

28.2

(47)

59.5

26500

Exercise 5.1 Calculate the productivity (that is, SLOC per work month) of each of the projects in Table 5.1 and also for the organization as a whole. If the project leaders for projects a and d had correctly estimated the source number of lines of code (SLOC) and then used the average productivity of the organization to calculate the effort needed to complete the projects, how far out would their estimates have been from the actual effort?

It would be very difficult on the basis of this information to advise a project manager about what sort of productivity to expect, or about the probable distribution of effort among the phases of design, coding and testing that could be expected from a new project.

There have been some attempts to set up industry-wide databases of past projects. However, this data seems to be of limited use to estimators as there are uncertainties in the way that various terms can be interpreted. For example, what exactly is meant by the term 'testing'? Does it cover the activity of the software developer when debugging code? Does 'design' include drawing up program structure diagrams or does this come under the heading of 'programming'?

Subjective nature of estimating Some research shows that people tend to under-estimate the difficulty of small tasks and over-estimate that of large ones. In the world of software development this is perhaps justifiable, as large projects are usually disproportionately more complex and more difficult than smaller ones.

Political implications Different groups within an organization have different objectives. The IOE information systems development managers might, for example, want to see as many systems as possible implemented and will therefore put pressure on estimators to reduce cost estimates. As Amanda is responsible for the development of the maintenance group accounts subsystem, she might be concerned that the project does not exceed its budget and is not delivered late, because this will reflect badly on herself. She might therefore try to increase the estimates. One suggestion is that all estimates should be carried out within an organization by a specialist estimating group, independent of both the users and the project team. Not all agree with this, as staff involved in a project are more likely to be committed to targets where they have participated in formulating them.

The possibility of the different groups with stakes in a project having different and possibly conflicting objectives was discussed in Chapter 1.

5.2 Where are estimates done?

Estimates are carried out at various stages of a software project. At each stage, the reasons for the estimate and the methods used will vary.

Strategic planning The costs of computerizing potential applications as well as Chapter 3 discusses the benefits of doing so might need to be estimated to help decide what priority to strategic planning in some give to each project. Such estimates might also influence the numbers of various detail, types of development staff to be recruited by the organization.

Feasibility study This ascertains that the benefits of the potential system will justify the costs.

System specification Most system development methodologies usefully distinguish between the definition of the users' requirements and the design that documents how those requirements are to be fulfilled. The effort needed to implement different design proposals will need to be estimated. Estimates at the design stage will also confirm that the feasibility study is still valid, taking into account all that has been learnt during detailed requirements analysis.

The estimate at this stage cannot be based only on the user requirement: some kind of technical plan is also needed - see Chapter 4.

• as the project proceeds, so the accuracy of the estimates should improve as knowledge about the nature of the project increases;

• conventional wisdom is that at the beginning of the project the user requirement (that is, a logical model of the required system) is of paramount importance and that premature consideration of the physical implementation is to be avoided. In order to do an estimate, however, the estimator will have to speculate about this physical implementation, for instance about the number of software modules to be written.

To set estimating into the context of the Step Wise framework (Figure 5.1) presented in Chapter 1, re-estimating might take place at almost any step, but specific provision is made for it at Step 3, 'Analyse project characteristics', where a relatively high-level estimate will be produced, and in Step 5 for each individual activity. As Steps 5-8 are repeated at progressively lower levels, so estimates will be done at a finer degree of detail. As we will see later in this chapter, different methods of estimating are needed at these different planning steps.

Evaluation of suppliers proposals In the case of the IOE maintenance group accounts subsystem, for example, IOE might consider putting the actual system-building out to tender. Staff in the software houses that are considering a bid would need to scrutinize the system specification and produce estimates on which to base proposals. Amanda might still be required to carry out her own estimate to help judge the bids received. IOE might wish to question a proposal that seems too low: they might wonder, for example, whether the proposer had properly understood the requirements. If, on the other hand, the bids seem too high, they might reconsider in-house development.

Project planning As the planning and implementation of the project progresses to greater levels of detail, more detailed estimates of smaller work components will be made. As well as confirming the earlier and more broad-brush estimates, these will help answer questions about, for example, when staff will have completed particular tasks and be available for new activities. Two general points can be made here:

Was this article helpful?

+1 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

Post a comment