Developing an e-Commerce site.

In this feature we are not considering business and strategic planning or financing explicitly--even though they are vitally important. Instead, we are assuming that these activities have been (are being) completed satisfactorily and that you have the money, resources and authority to plan and implement your e-Commerce or e-Business capabilities. However, it is worth saying that such capabilities should be aligned with the organisation's strategic objectives. For instance, if you have a strategic objective to develop revenue streams from traditional brick-and-mortar activities, and an e-Commerce route to market undermines that effort, the project is misaligned and potentially detrimental to the company.

Initially we offer some insight into the likely methodological approaches that could help in the development of online applications, and begin by conceptualising the process of developing information systems by looking at life cycles, before exploring the salient issues surrounding methodologies.

The System Development Life Cycle

System development life cycles and system life cycles are not the same thing! Considering the system (or product) life cycle first, Figure 1 shows how an information system (or a product such as a car, mobile phone, TV) grows in terms of the value it provides and/or the use that is made of it. At some point the system matures, but then its use/value starts to decline until it is no more.

[FIGURE 1 OMITTED]

The system development life cycle occurs during the growth (birth) phase of the system's overall life cycle, and takes account of the major activities that go into developing an information system. While there are numerous models for the development life cycle, one popular example is the waterfall model (see Figure 2). This illustrates the five major activities associated with:

* analysing the requirements for the system (e.g. speaking to stakeholders such as customers and users, looking at existing or competing systems, studying existing business documents and processes, assessing the feasibility of certain options);

* specifying its design (e.g. deciding on technologies, producing diagrams and documents that describe the software's operation, components and interfaces);

* implementing that design (e.g. writing and testing the code);

* integrating the system with users and other systems (e.g. installing the software on machines, training users, fixing unforeseen problems);

* maintenance (back-up, feature and technological enhancement, bug fixes, etc.). This final maintenance activity extends into the maturity and declining regions of the system lifecycle.

[FIGURE 2 OMITTED]

Note that the figure intentionally shows how these major phases happen in series, but do overlap to some extent.

The waterfall model is one of a number of development life cycle models. An alternative being the spiral model where the cycle of setting objectives, managing risk, development of prototypes and planning repeats in a spiral of activity. Another approach is to make as many activities as concurrent as possible so that specification, development and validation all happen in parallel and inform each other.

To some extent the development life cycle you use will be influenced by your organisational structure, your past experience, and the methodologies you adopt. Whilst development life cycles are interesting and useful, in as far as they make us think about our practice as professionals, they still lack much of the detail we need to help us create an information system such as a Web-based application. In order to achieve this we need a methodology.

Methodologies

A methodology adopted to develop an information system (such as an e-Commerce application) is an explicit standard process used to analyse, design, implement and maintain that system. It helps us structure our thinking and actions, and provides advice on what steps to take next. It often consists of phases and sub-phases to help manage our projects and will reflect some form of development life cycle. For instance, during the requirements phase of a development life cycle, the methodology might specify various sub-phases such as feasibility study, user modelling and data modelling, the notations for diagrams describing different views of the system, standard forms to help communication and control, key reviews at certain points, etc.

At one extreme, methodologies are criticised for being followed blindly by some people in organisations to the detriment of efficiency, quality and innovation. Since the methodology may say something has to be done in such a way, no matter how ridiculous, this may be given a specific context, it can justify inappropriate action and obviate the responsibility of the professional system developer to act sensibly or creatively.

However, used responsibly, methodologies provide system developers with a standard--and therefore widely understood, consistent and controllable--approach to tackling the often complex projects For instance, if you are a member of a team working on a software project and you are suddenly reallocated to another team working on a different project, it should be possible for you to find out what the project is about, what has been achieved, and what has still to be achieved, since you already know the methodology being followed There are many system development methodologies around. They range from those with a mainly technical focus to the more socio-technical that try to take account of the vagaries and inconsistencies of the human stakeholders in the project. On another dimension, there are those methodologies that tend towards high degrees of product quality and heavy demands in documentation and testing (some would call these approaches bureaucratic--although necessarily so if we consider safety-critical applications) versus those that are more pragmatic and informal (such methodologies are often termed agile or lightweigh). Many organisations even have their own in-house methodology cherry-picked from the various popular standards.

At this stage in the evolution of Web application development there does not seem to be a dominant methodology to adopt, or indeed one that is particularly well suited to this genre of system. However, there are a number of forces at play that may influence your choice. For instance, the speed with which you realise a working solution may be paramount, the degree of user acceptance of the resulting system could well be high and the requirements specification might be in a state of flux. In order to achieve the goals of speed and acceptability, you may also want to re-use existing system templates, applications and configurations. To adapt to changing requirements you could adopt an iterative approach.

With this in mind, a methodology that is gaining some credibility is Rapid Application Development (RAD).

Rapid Application Development

Rapid Application Development (RAD) has its roots in the spiral system development life cycle and claims to be able to reduce significantly the development time of a system. However, producing an artefact quickly usually means something else has to go.

Compromise

Consider Figure 3. Imagine the project is initially represented by the number '1', but it could occupy any point within the triangle. The closer the project is to 'Time', the less time the project will take to complete; the closer it is to 'Cost', the less it will cost; and the closer the project is to 'Quality', the higher will be the systems quality. In practice, we use the term quality here to describe the extent to which the system satisfies the user requirements in terms of functionality, errors, documentation, etc.

[FIGURE 3 OMITTED]

For Point '1' we can have a fast, low-cost project producing a low-quality outcome. Point '2' gives us a good system quickly, but may result in higher costs. Point '3' in the solution space of Figure 3 results in a high-quality, cost-effective deliverable that takes a long time to realise. In other words, there is no such thing as a free lunch or, put another way, '[You can have it] quick, cheap or good--pick any two' (anon). Whether you accept this rather negative position or not, it does illustrate the point that, if we shrink the time frame of a software development project, something normally has to be compromised. With RAD, it is generally accepted that the customer must be willing to compromise on some of their requirements. RAD exponents believe that it is possible to get a customer to accept a product that only has about 80% of the required functionality if it can be produced in 20% of the time--the 80/20 principle. This is particularly true if the 80% complete product has addressed the most important requirements. Thus RAD projects tend to exist around position '1' of Figure 3 (perhaps even tending towards the 'Time' apex) and compromise quality in an effort to speed up the process of system development.

Another aspect of compromising quality comes from the informality of project deliverables. In a heavyweight methodology, we might expect lengthy documents and extensive plans to be formally tabled and signed off at review meetings. This approach is beneficial in ensuring the delivered product is scalable, demonstrates programming standards, provides interface consistency and addresses maintainability considerations. In RAD, such formal documentation is less in evidence as teams concentrate on producing the code instead. With the formality of a heavyweight methodology, it might be some time before the customer sees a working prototype, but an agile approach such as RAD emphasises the early and evolving production of prototypes, enabling frequent consultation with users. If requirements are constantly changing, each iteration can capture and prioritise feature development.

Re-use and Outsourcing

Since RAD is attempting to contract the development lead time, any re-use of existing functionality is certainly preferable over writing code from scratch. For this reason, it is common for RAD projects to adopt libraries of functions and APIs (Application Programming Interfaces) wherever possible. In fact, customising third-party proprietary products and the use of productivity enhancers such as CASE (Computer-Aided Software Engineering) tools figure large in the world of RAD.

As such, developers may have to ask themselves the question, 'Is it quicker to build or to buy?'. You may want to host some or all (or none) of the applications and data yourself You may want to sub-contract aspects of the development that you are not expert in, e.g. graphic design.

The Skills Gap

Returning now to methodologies per se, it is tempting to assume that a project team can be formed and the project begins. However, as we have just hinted, a common problem encountered is a lack of the kinds of skills readily available to tackle the new technologies. This risk has become particularly evident in e-Commerce projects, where an organisation has existing IT development personnel that have been successfully undertaking in-house projects, using well known and understood hardware and software technologies, for some time. The change to new object-oriented languages and client-server architectures, as well as considering interoperability issues, page interfaces and site structure, has caught some off-guard and led to unexpected and excessive time and cost over-runs. Indeed, the fact that the applications' interfaces are now viewable by the public at large, and not just internal users, can impact significantly on estimated development efforts since browser compatibility, brand image and security become important. If it has been decided that in-house development is preferable, the partial solution to the skills gap lies in training the technologists in the required technologies--such as Web server administration, programming paradigms and languages, development methodologies, graphic design, database design, CASE tools, etc. Whilst the developers can (and do) learn on the job, that learning time is not productive project time and will erode the promises made about delivery dates. However, on the job learning is crucial after formal training. During this phase, developers become more proficient and consistent in their art and can better hit the productivity estimates their managers require.

Metrics 

The issue of estimating how long development activities take is a perennial problem. Previous experience in estimating traditional projects is almost certainly useless for e-Commerce and e-Business projects. Even after training, technologists will still be learning their new skills. For this reason, it may be preferable to undertake small, non-critical Web-based projects to determine some metrics in order to estimate the effort involved in future projects. For instance, metrics might inform the estimator of the person hours involved in:

* Interviewing users, creating storyboards and producing paper-based prototypes.

* Creating a static Web page or a dynamic Web page using certain specific technologies.

* Building a database query or schema.

* Configuring a middleware product to provide an interface or service.

* Setting up a Web server.

* Writing a class with a certain number of methods in a certain language.

* Executing a usability trail.

Without metrics, estimation would become guesstimation and the dates you give your customers become meaningless. Therefore, it is vital to have an idea how long certain activities take.

However, having arrived at an initial set of metrics it is important to realise that these need to be reviewed after every project. Estimates of effort are exactly that--estimates. They are unlikely ever to be 100% accurate when compared to how much effort was actually required. Sometimes they might be optimistic, at other times pessimistic. As people, technology, the nature of the projects and the influences from the external environment change, so will the metrics.

Having mentioned the problems of estimating task effort, a pragmatic technique often employed in development projects, including those following a RAD approach, is timeboxing. Here, a feature of the system may have a number of requirements associated with it. Some requirements will be high priority and others of a lower priority. In timeboxing, the project manager will allocate a fixed period in which the feature is to be developed, tackling the high priority tasks first. If this period ends and some of the lower priority requirements have not been realised, then so be it. We now have a mechanism to implement features by pushing through the most important requirements first, yet we are able to manage time ruthlessly. Of course, as we have already mentioned, this requires the customer to be able to compromise--something that may not always be possible.

As an aside, it is interesting to note the related concept of moneyboxing, where a feature is allocated a fixed sum of money. Once that money is used up, development of the feature stops. This may be useful when there are limited funds available.

Other Methodologies

RAD is just one of many methodologies available. There are numerous other distinct and related ones.

We have seen how methodologies relate to life cycles and have raised a number of issues surrounding the application of such methodologies. However, choose the wrong one and the project will almost certainly falter. Use the correct one inappropriately and the project may also falter. Consequently, and with reference to Maslow's quote, our chosen methodology should be a helpful tool in system development and not a millstone stifling worthwhile action, or a scapegoat when things go wrong Whilst the emphasis has been on so-called agile methodologies, it is important to realise that less adaptable, more formal approaches do exist and are successful. Indeed, the nature of any methodology you eventually find yourself following will be a product of the context in which the project is being executed.

From:Internet Technology and e-Commerce Alison Cawsey & Rick Dewar Palgrave Macmillan ISBN 0-333-98999-6

References:

(1.0) Avison, D and Shah, H (1997) The Information Systems Development Life Cycle, McGraw-Hill.

(2.0) Eaglestone, B and Ridley, M (2001) Web Database Systems, McGraw-Hill.

(3.0) Kerr, M (200 1) Tips and Tricks for Website Managers, Aslib.

(4.0) Lowe, D and Hall, W (1999) Hypermedia and the Web, Wiley (Chapters 7, 8 and 9).

(5.0) Turban, E, King, D, Lee, J, Warkentin, M and Chung, HM (2002) Electronic Commerce 2002: Managerial Perspective, Prentice Hall, NJ (Chapter 16).

(6.0) Turban, E, Lee, J, King, D and Chung, HM (1999) Electronic Commerce : A Managerial Perspective, Prentice Hall, NJ (Chapter 9).