Sizing E-commerce

by: Tony Rollo

Introduction

If you’re not doing e-business you will not be doing business soon. This sound bite probably overstates the importance of e-commerce in our current economies. However the many businesses in the UK and Europe regard it as the guiding principle of their current strategic planning. Furthermore they realize that they are well behind the developments in the US and are trying to catch up and if possible overtake them. These are not dot COM companies many of whose volatile growth and subsequent decline has caused so much turbulence in the financial markets of the US and Europe. The companies currently producing Internet applications at an ever-increasing pace are the major players in our economies.

The consequence of the frenzied rush to develop e-commerce applications has resulted in a demand for size data for such applications for purposes of productivity comparison, submission to benchmarks and of course estimation. The initial attempt to use sizing methods such as IFPUG and MKII Function Point Analysis has had a mixed results.

The Sizing Problem

First let us consider a simple basic web site – in this case the SMS web site (URL www.gifpa.co.uk or www.software-measurement.com

Figure 1

Considering this site we see that it is essentially a tree structure that we navigate until arriving at the information we require. Let us look at the ‘reading room’ when clicking on the pictogram of the reading room we are transferred to the following page

Figure 2

In order to size this web application in IFPUG function points we need to discover what files are being used by the application so let us consider the ILF’s. Now IFPUG requires an ILF to be:

• A group of data that is logically related and user recognizable
• Maintained by an elementary process of the application.

Now the data contained in the Web site – book details in this example – are obviously a logically related group of data and reconisable as such by a user. However there is no provision for a user to update this data – no elementary process exists.

What about an EIF perhaps that’s what the data is in this case. An EIF is

• A group of data that is logically related and user recognizable
• The group of data is external to and referenced by the application
• The group of data is NOT maintained by the application
• The group of data is maintained in another application as an ILF

Looking at the SMS web site the data is definitely part of the application its not maintained by it and it is not an ILF anywhere else.

This is an impasse; with no files there can be no function points. However on the IFPUG Web site there is a white paper on counting web sites. The white paper suggests that we regard files as:

• The logical group of data is either an ILF or an EIF
• Depending upon how and were the web site is maintained
• And providing that a user using available tools maintains the data

The SMS web site has data, which look like files. The developer updates the data. So whichever of the definitions of a file that you care to use there are no ILFs or EIFs. It can be argued that the data is updated at the behest of the user so it could be treated as EIFs, maintained in whatever tool is used to construct the web site. The files can be treated as EIFs but in truth it’s a bit of a fudge.

Using the fudge approach what is the result, well there are 11 EIF’s all simple. The transactional function types are just queries and there are 27 of them again all simple. Hence the size of the SMS web site in IFPUG (ish) FP’s is:

Size = 11x 5 + 27 x 3 = 136 FP’s

The SMS site is a very simple site and many of the current developments provide the site user with some interactive functionality. This seems more promising as there might be some ILFs being updated by the interaction. Consider the following site development.

A high street bank seeing that the internet banks have captured a quite large market share in their first couple of years decides that it will provide its customers with web site access. The bank hopes that this will result in a lowering of their costs and the retention if not increase in their own market share. The outline architecture of the Banks IT systems that are affected is given in Fig 3 below

Figure 3

The bank system initially is required to provide the ability for users to examine any of their accounts, Current, Saving, Credit card, Mortgage and so on. A customer may have any number of savings accounts. Customers must also be able to set up and modify regular payments into another of their accounts, they must also be able to make individual transfers to an account which is not their own and be able to vary direct debit (DD) payments if the DD is set up to allow this. These functions are a sub set of those provided by the ATM machines operated by the bank and also via the telephone banking operated by the call centre. The Internet banking sub system is to be constructed by an independent company. The bank requires the application to be sized in order to assess the value for money they are receiving.

In attempting to size the application it is soon realized that the developers are not providing any files or file access. Indeed looking at the architecture diagram we see that we are sizing just the portion below:

Figure 4

Now from Fig 4 you see that when the customer logs on to the banks main web site they provide a customer name and password this is validated and then the customer name and customer number are stored on the main web site and are available to the internet banking application. So the only file that is available is this small EIF.

We cannot really take the view that the customer and account files are EIFs because IFPUG 4.1 defines a user as ‘any person or thing that communicates with the application’ so as the Internet Banking system communicates via the infrastructure architecture then it follows that the core banking and customer care applications as users of the web site. In addition the developers of the Internet application clearly do not access the files so they would be given credit for work they do not carry out. This would give a misleading size measure that would be too large. A similar objection is true of MKII FPA, as of course the developers do not access the customer entity of the accounts entities

There is a new Functional Sizing Measure (FSM) known as COSMIC-FFP. This FSM is specifically devised to deal with real-time, embedded and infrastructure applications which are not well served by the existing methods of IFPUG or MKII.

For a full explanation of COSMIC please refer to the COSMIC manual available in a variety of languages at www.lrgl.uqam.ca

COSMIC views a complex of software ssyems and subsystems as being arranged in layers. The first thing to establish is which of these layers contain the software items being sized.

FIG 5 is an explanation of the layering and shows the layer in which the Java Sever application lies

Figure 5

Now having established where the Java server sits. It is important to remember that when we considering its functionality it should be viewed from the point of view of its user, which in this case is the human user sitting at home with their browser. So the browser is the user – there is no concern with browser functionality indeed there is no need to know which browser might be used.

COSMIC requires us to identify all the function processes – these are the equivalent of the MKII logical function. We see from the specification given above that the function processes are:

1. View account list
2. View specified account
3. View Regular Payments
4. View specified regular payment
5. Modify regular payment
6. Create regular payment
7. View DD List
8. View specific DD
9. Amend DD
10. Transfer Funds to another account

Examining just one of these functions in detail –View account list function.

Figure 6

Fig 6. Illustrates the functional process

COSMIC requires the identification of the data movements: Entry (to the process); exits (from the process); read (from persistent store) and writes (to persistent store). In the chosen example there is no write – the function merely retrieves data in order to display it. The read of the customer number is from the main web site ‘log on’ data that is persisted. The convention in COSMIC is that entry and exit are moves of data across the application boundary to the user or client level. And reads and writes are from the layer below or server level. The reasoning is that the user has no knowledge of the underlying architecture and cannot distinguish between an actual read of data from a file and the retrieval of a data from a communications infrastructure. The important point to note is that by adopting the approach and conventions of COSMIC-FFP we are able to size the individual functional requirements of the application. The complete sizing of the application is presented on the SMS web site.

Conclusion

The paper has demonstrated that in certain circumstances the sizing of e-commerce applications is difficult using IFPUG function Points. Whilst this has not been explored a similar difficulty arises when using MKII function Points. The new sizing method COSMIC-FFP however allows us to size the web site, without compromising the rules of the method. Incidentally COSMIC would also allow the sizing of the message broker, which would be extremely difficult in FPA as there will be no or very few files/entities ii being a communications switch. It should be noted that if we had been considering the development of a complete banking system to operate across the internet then we could have sized this in either MKII or IFPUG as of course we would then be developing the complete system including the file/entity accesses. However if we were to develop an infrastructure similar to the one in our example we would not have a mechanism for sizing the infrastructure elements such as the message broker or the java page server, unless we use COSMIC. COSMIC is an ideal sizing method for all modern software development techniques. It is especially useful in the complex infrastructure environments employed by many organisations today.