Critical Feature Method - A Lightweight Web Maintenance Methodology for SMEs

1 Introduction

The global reach and relatively low development cost of Web sites, enabled by rapid advances in Web technologies, makes it attractive for organisations to use Web sites to support business models that would otherwise not have been possible. As a result, Web sites are increasingly becoming an important business platform, especially for small and medium sized enterprises (SMEs). For an SME, it was previously a very expensive option, if not an impossible one, to explore overseas markets through conventional marketing channels. With a Web site, an SME can easily reach global markets. There is evidence suggesting that a Web site is one of the best returns on investment (ROI) results of all Internet applications for SMEs (Telstra 2003). In 2002, 36% of small businesses (defined as businesses employing 1-19 people) and 82% of medium businesses (employing 20-199 people) in Australia used their own Web sites for Internet activities such as promotion for their businesses, procurement, tracking customer orders, providing a customer information database and email marketing (Telstra 2003).

However, using a Web site to conduct business is not without difficulties. For example, security threats from cyber theft and attack have been well documented, denial-of-service attacks are not uncommon, and in early August 2003 thousands of local networks and PCs around the globe were paralysed by a virus called W32.Blaster.Worm. Identity fraud and cyber crimes (such as credit card theft) are also on the increase. Lack of agreement on jurisdiction over the Internet also poses a threat to businesses operating over the Internet. For example, promotion over the Internet could be seen as promoting to everyone who could potentially visit the Web site. As a result, relevant laws from every country in the world could potentially be applicable and hence open up the issue of prosecution within countries other than the intended Web site focus. In practical terms, it is impossible for SMEs to canvas the laws of all countries before conducting business over the Internet. What is important to the SMEs transacting on the Internet is that they should have the capability to make rapid changes to the Web site in response to a security threat or upon requests from foreign jurisdictions while maintaining the functionality of the Web site.

Despite the importance of Web sites to SMEs and the need for rapid response capabilities, most existing methodologies are not well-suited to making rapid changes to an existing system while maintaining the functioning of that system. This paper proposes a lightweight methodology that can be used for site maintenance during emergency situations, recovery post-emergency and normal development of a system. The methodology is based on the experience of the authors in managing Web systems for small Internet companies. Its application can be extended to other types of systems. We begin by reviewing existing methodologies and then describe our proposed approach.

2 Related work: Web systems and existing methodologies

Research has shown that the nature of Web systems is different from conventional software systems in a number of ways that are crucial in terms of the development approach (Lowe 2000b, Overmyer 2000, Lowe et al. 2001c, Lowe et al. 2002a). At a technical level, Web systems typically:

• have a tighter linkage between the business model and the system and information architectures;

• have more open and modularised architectures;

• use technologies that change very rapidly;

• demand effective information design and content management;

• place more emphasis on user interface design;

• are more susceptible to security threats;

• place increased importance on quality attributes in mission-critical applications that are directly accessed by external users.

At an organisational level, Web systems typically:

• face high levels of client uncertainty of the system requirements and in understanding whether a particular design will satisfy their needs;

• have high levels of change in requirements and project scope, largely due to the mutual evolution of the business model and the Web systems;

• have shorter delivery timeframes;

• demand finer-grained evolution and maintenance with an ongoing process of content updating, editorial changes and interface tuning (Lowe et al. 2001c) and are subject to the laws of multiple jurisdictions.

It has been argued within the literature that these characteristics mean the processes for the development and maintenance of Web systems need to be specifically adapted in order to be able to cope with high levels of system volatility and to support making changes rapidly and at very short notice.

Almost all conventional software development models (such as waterfall approaches, prototyping, rapid application development (RAD), incremental development, spiral models, component assembly, concurrent development and NASA model (Eljabiri et al. 2001, Pressman 2000) were originally designed for developing standalone software systems. These models specify the activities, outputs and artefacts at different lifecycle phases. To varying extents, they have been proven to be successful within domains that have stable requirements, but often have difficulties dealing with projects that have high levels of requirement uncertainty (Eckstein 2003), a common feature of Web site development and maintenance (Lowe et al. 2003b).

To cope effectively with high levels of requirement volatility and frequent system change, practitioners have increasingly adopted iterative and agile methodologies in Web development and maintenance. These methodologies include Rational Unified Process (Kruchten 2000), eXtreme Programming (XP) (Beck 2000), Cockburn's Crystal Family, Adaptive Software Development, Scrum, Feature Driven Development, Dynamic System Development Method and Lean Development (Martin 2002). Researchers have proposed new Web development models such as Web OPEN (Haire et al. 2001) and WebMutuality (Lowe et al. 2002b). Common features of these methodologies include an emphasis on communication between client and developers, minimal documentation, iterative development and rapid feedback.

We argue that while agile approaches can cope with system volatility (and in particular client uncertainty), they are not well suited to handling urgent changes. Specifically, agile approaches typically support the identification of specific development increments (e.g. the selection and implementation of specific user stories within XP) and the integration of these into a revised system (e.g. the refactoring process within XP). They do not, however, provide any inherent support for the identification or prioritisation of those existing functionalities which must be maintained during a period of rapid and/or urgent change. For example, assume that there are urgent unforeseen circumstances (such as a security breach) that require changes be made to the existing Web system in the shortest time possible. These demands could be due to security threats or unforeseen legal requirements imposed by overseas jurisdictions. Under such circumstances, the priority is to prevent the threat and comply with the legal requirements first, even at the cost of (temporarily) losing some existing functionalities. The lost functionalities can be restored post the emergency period after further systems maintenance. The normal development cycles start after the lost functions have been restored.

3 Example system and case study

As a specific example of the issues discussed above, we use an actual event with which the authors were involved - with the names and circumstances modified for reasons of confidentiality. An Australian company (which we will call XYZ-Match) specialises in matching investors and businesses seeking investment capital by posting the investment proposals of the seekers on its Web site for a fee. Seeking capital in Australia is regulated by the corporations law of Australia. In addition, the Australian Securities and Investment Commission (ASIC) issued a number of exemptions for raising small capital from rich individuals. XYZ-Match relied on ASIC's exemptions for its operation.

In the period 1995 to 2000 there were no clear rules as to the jurisdiction over online businesses. In 2000 the company received a facsimile from the Securities and Exchange Commission (SEC) of the United States of America alleging the company was in breach of the laws governing capital raising in USA. At that time, the US government decided to take a more proactive stance to capital raising activities on the Internet. In effect, the SEC deems all Web sites conducting capital raising activities that can be viewed by American residents as conducting capital raising activities in the USA and therefore subject to the laws of the USA. The fax sent to XYZ-Match outlined the laws governing capital raising in the USA and demanded that changes be made to the Web system within ten days so that the operations of XYZ-Match comply with the US laws in relation to capital raising. XYZ-Match faced two primary options: to completely ignore SEC's notice; or make changes to comply with SEC demands within a very short period of time. The first option could potentially result in significant costs if the SEC decided to prosecute the company. XYZ-Match decided to adopt the latter option.

After reviewing the relevant legislation, the company came up with a set of changes to achieve the critical features that would make the Web site operations compliant with US law. Nevertheless, due to the very limited time, it was not possible to assess fully the impact of the changes to the whole system. It was clear during that stage of the maintenance that some functionalities would have to be temporarily disabled until the impact of the changes on the system had been fully tested. After ten days' intense effort, XYZ-Match had completed changes to its Web system to comply with the relevant laws in the USA. Contacts were made with the person from SEC in charge of the matter, who informed the company the changes did appear to have satisfied their demands.

Having satisfied SEC, the company then spent another few weeks on restoring key functions that were disabled when making the changes. Patches were developed and tested on the development server to make sure the functions were restored without compromising other functionalities. Once the key functionalities were restored, the normal development and maintenance cycle resumed. The only difference from the cycles before the changes was that the new development and maintenance needed to be developed and tested against the changed system.

The above case demonstrates the ways in which existing methodologies would typically not explicitly accommodate urgent maintenance changes which may temporarily compromise existing functionalities. Below, we describe a lightweight methodology called Critical Feature Method, which deals with urgent maintenance changes and the subsequent restoration of functionality.

4 Critical Feature Method

The Critical Feature Method embraces a set of values that promote development speed and low cost. Consistent with its core values, it adopts a set of practices that makes it distinct from, but complementary with, other methodologies. We begin by introducing the core values of the method. The principles and practices that underpin this methodology are then described and an example provided.

4.1 Core values

The core values of this lightweight method are:

• Communication between the business executives and the developers (to ensure the proposed changes are understood and the required critical functionality is maintained).

• Rapid design coupled with minimal cost in communication and development (to allow rapid responses to urgent changes and emergency situations).

• Simple documentation.

To support the values, the following practices are applied:

• partition maintenance activities into three distinct states which support the management of emergency maintenance;

• close collaboration between the business executives and the developers;

• merge business modelling, requirements gathering and analysis, and design into one pair-prototyping phase;

• adopt an agile design process using paper prototyping and "telephone prototyping";

• replace formal documentation with lightweight matrices.

When dealing with urgent changes during an emergency situation, there is often little or no time available to accommodate the significant documentation requirements of traditional methodologies. Instead, the focus should be on developing workable solutions with minimum disruption to the existing functionalities of the Web system within tight time constraints.

Conventional software development processes typically divide key roles into aspects such as: client/users management; project management; systems analysis; systems design; programming; testing; deployment; quality assurance; document writing; and configuration management. These roles are in turn assigned to project team members. Each member may be assigned one or multiple roles. Clear role definition helps to set the context for communication among team members and the coordination of tasks. Any change request needs to follow a known procedure and needs to be signed off by people assigned with relevant roles such as testing and configuration management. These people in turn need to conduct reviews on the proposed changes. This rigorous change control process is necessary to maintain the quality of a system. However, when all the key roles are vested in a few people, such as the business owner and the chief developer in an SME, such a process can rapidly becomes onerous, particularly where the team size means that solutions or changes can be better handled through face-to-face meetings, teleconferences, paper prototyping and telephone prototyping (introduced below). The division of roles and document-based communication unnecessarily increases the cost of change in such a situation.

Traditionally the arguments against removing the requirements for substantial maintenance documentation have revolved around the potential long-term impact this has on the ability to retain a cohesive system. We argue, however, that in urgent circumstances (which, by definition, should only be short-term) it is more important to ensure system operation and critical functionality, and that the more rigorous documentation needs can be deferred until the process returns to routine maintenance.

The lightweight process proposed here emphasises collaboration between the chief developer and the business executives; tight feedback loops; close involvement of business executives; and rapid design focusing on critical features. Some of these core values are borrowed from existing methodologies. For example, eXtreme Programming utilises an on-site customer to tighten the feedback loop in development, and Joint Application Development (JAD) and Participatory Design (PD) stress greater user involvement and user participation in the development of systems (Bjerknes et al. 1987, August 1991, Carmel et al. 1993). Here, because of time pressures in dealing with urgent changes, there is little time for user feedback. Instead, business executives who understand users' needs are seen as surrogates for the users (albeit only temporarily).

Agile methodologies (Agile Alliance 2001, Martin 2002) and WebMutuality (Lowe 2003) highlight the need for clients and developers to work closely together throughout the project. Such close collaboration is based on the premise that neither the clients nor the developers know clearly about user/client needs at the beginning. Close collaboration not only helps the developers in developing features that satisfy business needs, but also helps the clients to understand the impacts these have on the business domain (Lowe et al. 2003b, Lowe 2003). As suggested by MacCormack (2001), "daily incorporation of new software code and rapid feedback on design changes" and "a team with broad-based experience of shipping multiple projects" are critical to delivering software projects in Internet time.

The nature of SMEs makes the collaboration between the chief developer and the business executives easier. They are often co-located and work closely on a daily basis. In addition to scheduled meetings, they could easily reach one another through informal means outside office hours, which is critical during an emergency. Such close inter-relationships can be utilised fully to reduce the feedback time lag, increase interaction between the two and ultimately develop rapid solutions to the emergency.

In this lightweight Web maintenance methodology, project roles for SMEs are assumed to be vested in two individuals: a business executive and a chief developer. The business executive runs the business and understands user needs. The chief developer is in charge of the Web system and looks after technical issues and usually works closely with the business executive. The chief developer and the business executive usually have frequent meetings (often informally). During these meetings, new business requirements and designs of the system can be discussed and debated between the business executive and the developers. These informal meetings are invaluable to resolving the emergency situation for an SME because both the business executive and the chief developer still have routine tasks and obligations that can not be fully set aside for this emergency situation only.

4.2 Three maintenance states

As demonstrated in the XYZ-Match case, the maintenance process can be partitioned into three distinct states: the Emergency Maintenance state, the Post Emergency state and the Normal Evolution state. This is shown in Figure 1.

4.2.1 Normal Evolution state

A Web site needs to be constantly updated and modified to suit business changes. This natural evolution state has been likened to Web gardening (Lowe 2000a). Most of the time a Web site is in this routine evolution state. In this state, the team could conduct the following activities as part of the maintenance of an existing live Web system:

• Information maintenance: content management and archiving old content.

• Corrective maintenance: correct pre-existing errors in the exploration, design and implementation in all three states.

• Adaptive maintenance: modify the system to adapt to environment changes such as changes in hardware, platform, language, database or upgrading to new technologies.

• Perfective maintenance and refactoring: add or modify features in response to business changes and developers suggestion, refactoring the code.

• Reengineering: replan, redesign, and rebuild the entire Web system in response to changes in business, technologies, system architecture erosion and the creativity of developers.

4.2.2 Emergency Maintenance state

Once an emergency situation arises, the maintenance approach switches to the Emergency Maintenance state. All non-essential activities are suspended immediately to give way to the emergency. Due to the tight coupling between the Web system and the business domain, the business executives work closely with the chief developer to work out critical features that should be considered as a priority. This communication should be done in a timely fashion without resorting to formal documentation.

The time constraints are extremely tight in this maintenance state. The highest priority in this state is to ensure that the critical features are retained or recovered. The changes should be as simple as possible as long as the critical features can be achieved. Reactive maintenance is allowed, which may impact on other functionalities and therefore affect the quality of the system. Inspection and testing could be limited to the features that have been changed in this situation and those critical to the business. A "Critical Feature Matrix" has been proposed to identify and track the features to be tested in this state.

An emergency is by nature unpredictable and therefore could happen at any time. The critical activities during an emergency include making decisions on the business changes, working out corresponding critical features for the systems, implementing the critical features, inspecting and testing, and deploying the changed system online. During an emergency, reactive fire fighting replaces forward planning, timeboxing replaces schedule estimation. The critical features should be met as far as possible within timebox constraints. Some non-critical features of the system may need to be disabled temporarily or abandoned for the critical features to be implemented.

4.2.3 Post Emergency state

Once the emergency has been resolved, the maintenance activities enter the Post Emergency state. The main objective during this state is to restore the functionalities that were disabled or lost during the emergency state. The Web system is thoroughly tested to identify disabled or lost functionalities. The disabled or lost functionalities that are necessary for the business will be restored through further patching. Documentation should again be kept to a minimum in this state. Configuration management may be necessary depending upon the size of the project. Once the functionalities of the system are back to normal, the system goes back to the Normal Evolution state.

4.3. Pair-prototyping for rapid exploration and design

Web systems are constantly changed to adapt to user needs and business changes. This month's Web system could be next month's legacy system. As discussed above, effective collaboration between the business executive and the chief developer enables rapid and simple design that could accelerate the pace of developing effective solutions in an emergency. Such collaboration between the business executive and the chief developer facilitates the developer's understanding of business processes and the executive's understanding of the capabilities and implications of the Web system and its fit with the desired business model. Research indicates that the Web process is more design-driven than traditional processes. Design artefacts play a crucial role in the development of customers' understanding of their needs (Lowe et al. 2002b). As suggested by recent research, business modelling, requirement analysis and design are in one "exploration phase" in a typical Web development process (Lowe et al. 2002b, Lowe 2003).

This methodology proposes a rapid design process that explores technical design and business solutions through pair-prototyping. The design decision affects both Web system design and new business features and solutions. The close, collaborative relationship between the business executive and the chief developer is fully leveraged here to facilitate this rapid design process. Rapid prototyping includes paper prototyping and telephone prototyping, both of which can be applied in either the Emergency Maintenance state and the Post Emergency state. The two prototyping approaches can also be used in the Normal Evolution state in conjunction with white site prototyping and other design methods.

4.3.1 Paper prototyping

Paper prototyping is a face-to-face design approach at any state when the business executive is with the developers. Colour paper sheets are cut into pieces to mimic Web objects. Business scenario analysis and navigation models could be analysed and designed by arranging the sequences of paper pieces, sketching on paper or whiteboard using simple diagrams that both the business executive and the chief developer understand (such as flow charts or sequence diagrams). Architecture design can be mimicked by placing the paper pieces on to a large paper sheet. User interfaces are prototyped by arranging the colour pieces into an A4-size paper sheet. Data and Web object analysis, and content design are merged into interface design and navigation design. Design alternatives are rapidly debated and chosen when manually arranging these paper pieces. Business rules are described by the business executive and are incorporated into the design. The Web system features are explored during the prototyping and debate. The prototyping solutions help the business executive to decide system changes. Usability data are gathered in this process. Once the decision is made, the colour paper pieces are glued on to a large paper sheet. The identified Web system features are manually recorded on the paper sheet or whiteboard, which will be recorded into a Critical Feature Matrix or a Normal Feature Matrix once finalised.

The artefacts of this process include: sketched scenario diagrams; sketched architectural models; paper navigational models; paper prototypes of interfaces; data and Web object definitions; content drafts; and Web system features taking account of current change requests. Data and Web objects discussed here are limited to an external user's view. Any internal data and Web objects (such as databases) and their inter-relationships (such as entity-relationship diagrams) are not discussed at this stage. Not all of the above activities and artefacts are needed in this prototyping process. Business scenario analysis can be merged into navigation design. The design focus is only on the current change requests and critical features.

The informality of this approach reduces substantially the costs in communication, technologies and manpower during the design process and hence supports the core values of this maintenance methodology. The business executive gradually learns and understands the technologies and their impacts on the business model in this daily collaboration process. In return, this makes telephone prototyping possible in an emergency.

4.3.2 Telephone prototyping

In the Emergency Maintenance and Post Emergency states, if the business executive is not approachable via face-to-face communication, telephone prototyping is an effective, simple and quick design approach. Through years of experience in running the business and collaboration with the chief developer, the executive should already have a mental model of the Web system and its business features. In telephone prototyping, mental images replace pieces of paper used in the paper prototyping. The chief developer uses examples of templates, existing Web objects and design patterns that the business executive is familiar with to prototype the Web system via telephone communication with the business executive. During urgent business, change requests, discussions of impacts on existing business processes and mental simulation of the business process in the Web system, are exchanged and debated rapidly via telephone. The design artefacts are recorded on paper or whiteboard.

4.3.3. White site prototyping and other design modelling

Developers typically enjoy cutting-edge technologies and create complex solutions. However, in the Emergency Maintenance and Post Emergency states, developers' focus on achieving the maximum leverage of technologies should give way to simple and easy solutions. New and complex technologies may actually slow the pace and prolong the emergency state.

In the Normal Evolution state,  when the pace is back to normal, the developers could explore the use of new technologies and add more functions to the system. White site prototyping and other design modelling provide creative approaches to Web site development. Various design methods, notations and tools such as RMM (Isakowitz et al. 1995), OOHDM (Schwabe et al. 1998), UML (Baresi et al. 2001), WebML (Ceri et al. 2000), and WebML+ (Lowe et al. 2003a) can be used in this state depending on the nature of the tasks and project team's experience. Whatever the design tools and models, simple designs should be the overriding design rule.

4.4 Critical Feature Matrix and Normal Feature Matrix replace formal documentation

The process models for conventional software development and maintenance define and recommend some formal documentation associated with each defined activity in the software lifecycle. Due to the characteristics of the Web development process, these documents are often not suitable for Web development. Researchers have been clarifying which aspects should be specified, what documentation is meaningful to both clients and developers, and where in the lifecycle should requirements be articulated (Lowe 2000c, Lowe 2001, Lowe et al. 2001b). Some agile methodologies (such as Extreme Programming) recommend only very minimal documentation. For example, throw-away cards of user stories replace formal requirements (Beck 2000).

To deal with the emergency situations effectively in Web maintenance identified above, we propose a "Critical Feature Matrix" and a "Normal Feature Matrix" to replace formal documentations such as development plans, requirements specifications, testing documentation, design specifications and configuration management plans.

In this method, a feature could be informally defined as a requirement, a user story, a use case or a change request, depending on the experience of the business executive and the chief developer, and the company's convention. Features are partitioned into two levels: "business features" and "system features". Business features are "what the Web system should do" from a business user's external view. System features are "what and how the Web system will operate" from an internal perspective. System features are derived from the business features, and are the responsibility of the chief developer.

For example, a business feature could be: "the member registration form should ask questions of a potential member's country of origin, level of income and level of wealth (within levels defined by the laws or regulations governing the business operations). When members log in, the system should be able to tell whether the person is eligible to participate as defined by relevant law or regulations". Accordingly, the chief developer could come up with a design that addresses the business feature in an effective and efficient way. The corresponding system feature is: "the registration form should contain a question asking the country of origin. A drop-down menu containing a standard country list should be made available. The list should also contain an "other" option. If "other" is selected, there will be a follow-up window asking the applicant to fill in the country name manually. A database table containing the code of each country and the corresponding multiple choice questions (about income level and personal wealth) will be established". Etc.

The Critical Feature Matrix contains the critical features, business rules and other constraints that the system must conform with to be operationally effective. Conformance tests and/or inspections should be conducted against these features. Considering the system traceability, other contents of the Critical Feature Matrix could include affected features; designs such as architectural design, business scenario models, navigation designs, user interface prototype, contents, and test designs; test records, defect summaries and actions; and deadlines for this feature to be implemented. Identification and analysis of the above items involves both the business executive and the chief developer. The following items in the matrix only involve the chief developer for implementation traceability: Web objects that need to be created, changed or deleted for a feature; records of Web object inspections both in the development server and production server; notes; and revision history of this feature. Urgent change requests are always the top critical features. Other critical features could be from some categories such as user identification, registration and access control; user monitoring; security; content and data source control; work flow control. Recent research on the WebMutuality Acceptance Model (Lowe 2001) provides a guide to these Web feature categories. The business executive decides which features are critical. Figure 2 is an example of Critical Feature Matrix of XYZ-Match during an emergency situation. It will be explained in the next section.

Non-critical features are not included in the Critical Feature Matrix and are not tested during an emergency situation. They are included in a Normal Feature Matrix to guide the development effort during the Post Emergency state and the Normal Evolution state. Both the Critical Feature Matrix and the Normal Feature Matrix could be sketched manually first during an emergency situation and documented later once the emergency state has passed. In theory, these two matrices together cover the entire features set of the Web system. The Critical Feature Matrix focuses the attention of the team during the Emergency Maintenance state, while the Normal Feature Matrix is used during the Post Emergency state and the Normal Evolution state.

5 Case study: application of the Critical Feature Matrix

This section illustrates a Critical Feature Matrix (see Figure 2) using the example of the XYZ-Match system (described in section 3) undergoing maintenance during an emergency state. When entering this state, the emergency requirement was to implement changes to make the Web system comply with the legislation and regulations governing private placement in the United States. This key requirement is documented in the column of the matrix labelled "Business rules and other constraints". The relevant business feature was then identified based on the business rules.

The system features were subsequently identified through a series of rapid design activities including business scenario analysis, navigation design, interface prototyping and content design. The rapid design started with business scenario analysis, which identifies and analyses usage by users in different groups using an activity diagram. The paper sheet of this business scenario diagram was attached to the Critical Feature Matrix under the column "business scenario". The changes to the architecture were identified during the business scenario analysis. The architectural design was limited to the information architecture and merged into the navigation design. Hence the column under "architecture" was blank.

The navigation design was completed based on the business scenario diagram and was attached to the column "navigation model". To save time, the user interfaces were prototyped using white site prototyping instead of paper prototyping, because some containers of these white site prototypes can be copied to code directly to become part of the real system. The content design was fitted into the navigation diagram and the interface prototyping. Draft contents were sketched on a paper sheet or directly typed into the interface prototypes by the business executive.

In the subsequent implementation stage, the chief developer made phone calls to the business executive to email the precise contents to the developer or fill in some contents via the content management module that is part of the Web system.

The data definition and analysis activities were merged into this user interface prototyping: data were directly entered into the form container in form-field areas and also recorded in the column "content/data". Later, during database design stage, the chief developer copied these data fields from the source code of the white site prototype to the database. The interfaces were attached to the matrix under the column "user interface".

The above design artefacts were enough for this feature. The system features are derived from these design artefacts and would be recorded in the column "System Features" once the emergency has passed. In this lightweight methodology, deriving and recording the system features are unnecessary in emergency situations. The design artefacts have replaced the functions of these system features which are mainly used for post emergency and normal states. Quality has its context (Lowe 2001). In this emergency state, the highest quality requirement for the system was to meet the critical feature. The business executive made the decision to disable or change the impacted features. The names of identified impacted features were recorded under the column "Affected Business Features" and "Affected System Features". The deadline was estimated, negotiated and added into the column "Deadline".

The chief developer began implementation by identifying the Web objects that would be created and changed for this feature. Detailed designs were merged into the implementation stage. The Web object names were recorded in the column "web object name". The paths of these Web objects in the system were recorded in the column "path". The category of these Web objects - such as file, database, multimedia, server or commercial package - was recorded in the column "Category". The version was in the column "version".

Before testing, a Web object inspection activity was conducted. The results were recorded in the column "inspection-development server" and "inspection-production server". The test was designed using a test flow graph. Each test step was numbered using the numbers assigned to each item in design artefacts and Web objects. The test flow graph and the Pass/Fail records were in the column "Test Flow & Pass/Fail". The defects summary was recorded in the column "Defect Summary & Action". Defects were immediately fixed without any delay. When information was needed from the business executive and the business executive was not on site, a phone call to the business executive was made immediately. When the defect was caused by design, the design was reviewed via telephone. Telephone prototyping was conducted. The design diagrams were modified. The comments and revision history were recorded in the column "Notes and revision history".

The final acceptance test on the production server was conducted and accepted by SEC.

6 Conclusion and future work

A lightweight Web maintenance methodology has been proposed to effectively handle emergency situations that are common to Web systems. Web maintenance is analysed and classified into three distinct states. The proposed process can be integrated with the normal evolution of Web systems. The methodology is underpinned by a set of core values that emphasise collaboration between the business executives and the chief developer; minimal feedback loop; and rapid design focusing on critical features. Two rapid prototyping approaches have proposed. The Critical Feature Matrix and Normal Feature Matrix have been introduced as a simple tool to replace onerous conventional documentation without compromising engineering rigor.

This methodology is based on the authors' experience in Web systems development and has been illustrated using a case study. We believe the methodology could be extended to other types of software systems. Further research is needed to enhance the methodology and identify its applicability to other types of systems. Further empirical studies to evaluate the effectiveness of this approach are also needed.