A Novel Lifecycle Model for Web-based Application Development in ...

International Journal of Automation and Computing

7(3), August 2010, 389-398 DOI: 10.1007/s11633-010-0519-3

A Novel Lifecycle Model for Web-based Application Development in Small and Medium Enterprises Wei Huang1

Ru Li2 1

Carsten Maple1

Hong-Ji Yang3

David Foskett2

Vince Cleaver2

Department of Computer Science and Technology, University of Bedfordshire, Luton LU1 3JU, UK 2 3

Exxcom Ltd, Kingsmede House, Bedfordshire SG17 5DB, UK

Software Technology Research Laboratory, De Montfort University, Leicester LE1 9BH, UK

Abstract: Software engineering0 s lifecycle models have proven to be very important for traditional software development. However, can these models be applied to the development of Web-based applications as well? In recent years, Web-based applications have become more and more complicated and a lot of efforts have been placed on introducing new technologies such as J2EE, PhP, and .NET, etc., which have been universally accepted as the development technologies for Web-based applications. However, there is no universally accepted process model for the development of Web-based applications. Moreover, shaping the process model for small medium-sized enterprises (SMEs), which have limited resources, has been relatively neglected. Based on our previous work, this paper presents an expanded lifecycle process model for the development of Web-based applications in SMEs. It consists of three sets of processes, i.e., requirement processes, development processes, and evolution processes. Particularly, the post-delivery evolution processes are important to SMEs to develop and maintain quality web applications with limited resources and time. Keywords:

1

Web, development of Web-based applications, lifecycle models, small medium-sized enterprises (SMEs).

Introduction

With advancements in the Internet in the past decade, the world wide Web (WWW) has become the dominant platform for ubiquitously accessible information and applications of any kind. The Web has gone far beyond presenting static information and Web-based applications have become increasingly complex and sophisticated. However, the complexity of Web-based applications is often neglected by many IT managers and developers. The development of Web-based applications still remains ad-hoc due to the ease of use of tools, relatively error tolerant development environment[1] and fast changing Web technologies and user requirements. The common approach for Web-based applications development, especially in small medium-sized enterprises (SMEs) is still “sufficient for now”[1] with continuous improvements when new requirements become needed. SMEs cannot afford the cost and risks of applying a rigorous standard software development process with limited development and management resources. Because more and more critical applications are migrating to the Web, the current approach has become increasingly infeasible for the development of Web-based applications. The current approach often fail or is facing the possibility of major failures[1] due to the strong temptations to just “build it now and fix it later” to meet the deadline. Existing literature shows that the primary causes of failures for the development of Web-based applications are flawed designs, unorganised development processes and poor management of development efforts[2] . It has become clear that a systematic development process needs to be followed for robust Web-based applications development and Manuscript received October 30, 2008; revised December 11, 2009

the construction and evolution of Web-based applications require support such as those available for traditional software applications through lifecycle process models. However, a good lifecycle model for Web-based application development should not simply copy traditional software engineering lifecycle process models and it is rather a sibling to the traditional software engineering lifecycle process models due to the unique characteristics of the Web. Although process models of Web-based applications development have received some attention[3] , hardly any has focussed on SMEs. Economic realities force SMEs to continuously adapt to shifting environments and to use a shorter development lifecycle to get the product out onto market more quickly. Moreover, small business often changes as the development proceeds so making a straight path to an end product is often unrealistic. This paper proposes a systematic and effective lifecycle process model for Web-based applications development in SMEs, which has been applied in a recent real-world project in an SME in the UK to prove its feasibility. The rest of the paper is structured as follows. Section 2 reviews the current situation on the development of Webbased applications and the needs of using systematic development lifecycle models for Web-based applications in general as well as in SMEs. Section 3 analyses what would make a good lifecycle process model for the development of Web-based applications in SMEs and why traditional software development lifecycle models are not good enough. Section 4 proposes a lifecycle process model for the development of Web-based applications in SMEs, which include three sets of processes to address the challenges. Section 5 illustrates a case study on applying the proposed lifecycle model to an SME in the UK. Finally, Section 6 draws our conclusions.

390

2 2.1

International Journal of Automation and Computing 7(3), August 2010

Analysis on Web-based applications The Web and Web-based applications

The Web is unique in its ability to handle all types of information from text and graphics to voice and video and it provides a more effective way to exchange data and information to meet globalisation0 s needs. The Web environment is characterised by millions of websites and thousands of Webbased applications. The number of websites has grown dramatically from 100 to over 45 million (see Fig. 1) and the Web has become the dominant platform for accessing all kinds of applications which are widely distributed across the Internet. The numbers will continue to grow rapidly as more and more countries and organisations adapt to the Web. The Web has changed our lives and work at every level, and this trend has just started.

suggested that a given application could be in more than one category[9] . Web-based applications have become much more complicated and sophisticated, from showing static information to involving sophisticated interactions between users and the database in real time, due to the nature and rapid growth and evolution of the Web, the boom in the Web and Web-related technologies, the commercialisation of the Web and the desire or need to migrate legacy/existing systems to the Web environment[10] . Moreover, as the wireless technologies and portable computing and communication devices have evolved, a new wave of mobile Web-based applications is rapidly emerging. Canali et al.[11] argued that mobile web-enabled services place unprecedented strains on the server infrastructure of the content provider and proposed resource management strategies to reduce the response time. Wei et al.[12] also proposed a semantic webbased enterprise information platform for mobile commerce. But what makes Web-based applications different to traditional software applications?

2.2

Fig. 1 Growth of websites[4] (websites = number of Web servers)

Web-based applications are not just web pages. Several researches have attempted to define Web-based applications. Ceri et al.[5] defined Web-based applications as “complex systems, based on a variety of hardware and software components, protocols, languages, interfaces, and standards”. Conallen[6] defined Web-based applications as “a Web system (Web server, network, HTTP, browser) in which the user input (navigation and data input) affects the state of the business. Gellersen and Gaedke[7] defined Webbased applications as any software application that depends on the Web for its correct execution. Koch and Kraus[8] defined Web-based applications as “Web information systems that tend to be used to integrate and streamline business processes across organisations (customers, agents, suppliers, others) and geographical borders”. As the scope and complexity of current Web-based applications vary widely, it is difficult to come to a standard definition of Web-based applications. Ginige groups Web-based applications based on their functionality into seven categories in Table 1 and Table 1

Web-based applications versus traditional software applications

There is a growing literature that compares Web-based applications and traditional software applications[13] . We summarise these differences as follows: 1) Multi-disciplinary development team Web-based applications require the collaboration of larger teams of people with diverse expertise compared to traditional software applications. An ideal team would consist of web interface designer, content writer, webmasters, graphical designer, usability engineers, tester, network experts, database administrator, and human computer interaction specialist. 2) Diverse requirements Apart from the functional and non-functional requirements in the traditional software applications, navigational, content, personalisation, structuring, access, aesthetic, marketing, database design, network security, and network performance requirements are also needed to be considered in the Web-based applications. 3) Substantial content Web-based applications contain substantial published contents, which can be in the form of images, text, audio and multimedia, so it is important to maximise the effectiveness and efficiency on applying content presentation formats as well as to catch up with the rapidly changing technologies of contents presentation.

Categories of Web-based applications based on functionality

Category

Examples

Informational

Online newspapers, newsletters, service manuals

Interactive

Registration forms, customised information presentation, online games, online learning, digital library

Transactional

Electronic shopping, online banking

Workflow

Online planning and scheduling system, inventory management, status monitoring

Collaborative work environments

Distributed authoring system, collaborative design tools

Online communities market places

Chart groups, online auctions, picture sharing, online radio show

Web portals

Electronic shopping malls, online intermediaries

W. Huang et al. / A Novel Lifecycle Model for Web-based Application Development in · · ·

4) Technology visibility Compared to the technology in traditional software applications, the technology of Web-based applications is much more visible to the users due to the distributed nature of the Web, the rapidly changing nature of the underlying technologies, and the lightweight component-based structure of most Web-based systems[9] . This implies that the link between the business architecture and the technical design of the system may be much tighter than for traditional software applications, and errors and down time in Web-based applications are often not tolerated. 5) Diverse users Web-based applications are used by many unknown users with different background and experience across the internet. Therefore, user interface design in Web-based applications needs to consider much wider issues, such as culture, aesthetic, than traditional software applications. 6) Multiple stakeholders Unlike traditional software applications, a diverse range of users, people who maintain web systems, the organisation using web systems, and system developers are involved. 7) Short development cycle Because of the dynamic business environment, fast changing Web technologies and users/customers0 requirements, Web application projects usually have shorter development cycles required than traditional software applications. 8) Integration with Database A database is usually integrated with Web-based applications and a well designed database structure is fundamental to the performance, stability, and level of maintenance of the Web-based applications. 9) Level of abstraction Web-based applications are based on low-level technologies that do not provide high-level abstractions for reuse. The lack of a suitable abstraction makes it really different from the well used object-oriented concept in traditional software applications. Deshpande et al.[14] also identified some major unique characteristics of Web-based applications from the aspect of user, availability, content, and storage system. They are summarised in Table 2. Table 2

Characteristics of Web-based applications

Aspect

Characteristics

User

Various Various Various Various

Availability

Universally accessed Accessibility Including people with disabilities

Content

“Content is king” Substantial published content Complex navigational model Complex data design Many computational modules

Storage systems

Databases

abilities (i.e., learnability) abilities in using a computer ethnic groups cultural backgrounds

File systems Multimedia storage devices

391

Each characteristic of Web-based applications identified above alone might look insignificant, but combining them will make Web-based applications as unique software applications. Not only the characteristics of Web-based applications matter, but also the size of the applications matters. In the next section, we will compare the differences between SMEs and big companies in terms of Web-based applications development.

2.3

SMEs versus big companies

The definition of SMEs that is currently in use in the European union (EU) was adopted with Commission Recommendation 96/280/EC[15] . SMEs are defined as companies that have less than 250 employees, and have either an annual turnover not exceeding European currency unit (ECU) 40 million, or an annual balance-sheet total not exceeding ECU 27 million[15] . In the IT industry, compared to bigger companies, smaller companies have to deal with the issue of resource constraints more often than their larger counterparts. SMEs do not have sufficient funds to finance secondary aspects of their main activity (i.e., development process/tools evaluation, management evaluation) as opposed to larger companies that have more resources and higher economies of scale to search for innovations in the development process and tools. Also, they do not have enough resources to create their own research and development (R&D) group, so their information about the latest technology is slower than the large companies and they are more sensitive to risks. Considering the structure and constraints, SMEs should be the first to follow a systematic development lifecycle process. But normally, the developers do not like to follow any process model, which could be too constrained and time consuming to apply, plus there is a lack of management to control the development process in SMEs. They tend to hesitate to move onto a new technology, system or method for development process due to the unknown costs and risks. All these factors can account for a less comprehensive development lifecycle process model for Web-based applications development in SMEs. In the next subsection, we will review the current problems of Webbased applications development in SMEs.

2.4

Problems of Web-based applications development in SMEs

Web-based applications have a very short history compared to traditional software applications, and they can be treated as the sibling of traditional software applications, with their unique characteristics on top of traditional software applications0 quality. According to the criteria of a good software application and unique characteristics of Web-based applications, quality Web-based applications need to have 1) Good usability, 2) Efficient navigation, 3) Good accessibility, 4) Easy to scale, 5) High maintainability, 6) High compatibility and interoperability, 7) High security and reliability, and

392


8) High performance. The complexity of Web-based applications in SMEs as well as in big companies has grown significantly, but currently, most Web developers, especially in SMEs, often use ad-hoc, hacker-style approaches[16] and pay little attention to usability, accessibility, maintainability, and scalability. Little consideration has been paid to those very important attributes of quality Web-based applications listed above. Many researchers in the field have raised serious concerns[13, 14] about the deployment and management of Web-based applications. When Web-based applications continue to expand, it will have a high probability of low performance and/or failure. A survey on Web-based applications development by the cutter consortium highlighted the following existing problems[14] : 1) 2) 3) 4) 5)

84 % 79 % 63 % 53 % 52 %

delivered systems did not meet business needs, schedule delays of the projects, projects exceeded the budget, did not have the required functionality, and deliverables were poor quality.

As the growth of the Web has had a significant impact on the world ranging from our daily lives to government sectors, Web-based applications0 standard and quality becomes more critical. When the Web and Web-based applications keep growing, a Web crisis may be caused without a systematic approach for Web-based applications development[17] , and it could be more serious and widespread than the traditional software crisis[18] . To address these concerns and challenges, many researches suggest the need for a more disciplined and systematic approach for Web-based applications development.

2.5

The need of an engineering approach for Web-based applications

The current ad-hoc approach towards Web-based applications development may sooner or later cause Web crises. Because of the fast growth of these applications and the obvious commercial impacts of failure to deliver effective solutions, an engineering approach for Web-based applications is essential. There have been numerous attempts to identify the important success factors and to use engineering approaches to build process models to address specific concerns[7] . The term software engineering was popularised during the 1968 NATO software engineering conference by its chairman Bauer, and has been in widespread use since. The IEEE definition of Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software[19] . Will software engineering techniques and methodologies be suitable for Web-based applications development? There are two general opinions on this question. One opinion states that software engineering is still applicable to Web-based applications as Web-based application is a natural evolution of traditional software applications, although it is a distributed system[19] . On the other hand, many Web-based application development researchers oppose this view, and state that from a

software engineering perspective the Web is a new application platform. The implementation model that the Web is based on makes it difficult to apply classic process models to its applications development and, even more, to the evolution of Web-based applications[14] . Web engineering was first proposed in the first international workshop on Web engineering in 1998 as a new emerging discipline, rather than adapted from software engineering[14] . Based on the IEEE software engineering definition, Web engineering is now defined by experienced researchers in the field, as “the application of systematic, disciplined, and quantifiable approaches to development, operation, and maintenance of Web-based information systems”[14] . Since Web engineering was first used in 1998, there are many debates on the differences between Web engineering and software engineering[14] . There is significant evidence that Web-based applications development has particular characteristics that differentiate them from traditional software application development. Pressman[19] said that Web engineering was not a perfect “clone” of software engineering but it borrowed many software engineering0 s fundamental concepts and principles, emphasising the same technical and management activities[20] . Therefore, in this paper, we take the middle view of the two opinions on the engineering approach for Web-based applications. We consider that an engineering approach to Web-based application development can be viewed as an adapted or extended form of software engineering to meet various unique characteristics of Web-based applications.

2.6

Scope of discussion

An engineering discipline for software applications development is concerned with all aspects of software production, and it encompasses a variety of concepts, principles, knowledge, tools, models, and methods, for example, the object-oriented (OO) technologies, unified modelling language (UML), pattern methods, etc. Software development lifecycle is also one of the major aspects, which incorporates software requirement analysis, design, construction, testing, and maintenance. Software lifecycle incorporates activities of tracking source code as it goes through various stages throughout its life, and most of the existing proposed Web application development lifecycle models come from the ideas of traditional software development lifecycle, which usually covers the following five stages[6, 7, 9, 10] : 1) Requirements analysis answers “what” the system is. 2) Conceptual design focuses on identifying abstract types of components, relationships, and functions. 3) Prototyping and validation specifies the system features, processes, and behaviours in a very detailed way so that a prototype can be generated. 4) Implementation this stage implements the prototype into actual product. 5) Evaluation and maintenance keeps the system up to date. An effective lifecycle process model can improve productivity and quality of the software development. This paper will focus on the lifecycle process model for Web-based applications development. The next section reviews existing lifecycle process models and evaluates their feasibility for Web-based applications development in SMEs.

393


3

Analysis on lifecycle models

As traditional software systems become big and complex, a number of development lifecycle models have been created to manage the process[20, 21] . We will first review some most discussed lifecycle process models used in traditional software applications, and then assess their feasibility for Web-based applications development in SMEs.

3.1

are defined and implemented in smaller chunks as the system evolves[22, 23] . Each iteration contains all the necessary software development activities. This model also introduces risk management into the lifecycle (see Fig. 3). The radial dimension represents the updated cost and the angular dimension represents the progress through the spiral. Each section of the spiral corresponds to one stage of the development.

Traditional software lifecycle models

A software lifecycle model is a structure imposed on the development of a software product. It aims to improve productivity and quality of the software development by systematising and formalising the seemingly unruly task of developing software[19] . There are two kinds of lifecycle models: sequential and iterative. 3.1.1 Sequential model — waterfall model In 1970, Royce proposed what is presently referred to as the waterfall model as an initial concept, a model which he argued was flawed[19] . He then modified the initial model with feedback from each phase influencing subsequent phases into an iterative model, which is similar to many iterative lifecycle models. Waterfall model is a framework for software development in which development proceeds sequentially through a series of phases, which are requirement, design, implementation, verification, and maintenance. Fig. 2 illustrates the phases of the waterfall model with feedback[19] .

Fig. 3

3.1.3

Fig. 2

The waterfall model with feedback

The problem with the waterfall model is that each phase relies on the preceding phase that needs to be completed before moving on. Once the analysis phase is finished, the software system will be designed and the work will be documented. This phase is followed by project planning and budget creation. Once it is approved, the system is developed, tested, and released to become live. This approach leads to a great degree of inflexibility when developing complicated projects with frequently changing requirements, as the nature of the model makes it difficult to change or modify the developed phases once they are completed. 3.1.2 Iterative models — the spiral model The spiral model0 s idea is based on evolutionary development. The details of the entire system are not designed at first. Only the highest priority features are defined and implemented and then feedback from users is monitored with this knowledge. More features with lower priorities

The spiral model

Agile software development

Agile methods are a family of development processes/lifecycle models, not a single approach for software development. The principle of agile development process is that at regular intervals, the team reflects on how to become more effective from feedback, and then adjust its behaviour accordingly. Among all the agile software development methods, extreme programming (XP) is well-known to develop software faster and incrementally, and can improve software quality through iterative feedback and by practicing pair programming and test driven development[24] . XP is defined as a light-weight methodology and its focus is on coding, testing, and user feedback. This methodology emphasises customer involvement throughout the software development, so communication and feedback are important. Its efforts basically are in the later stages of the software lifecycle and its requirement engineering (so-called story cards) and risk management are not so strong. Although XP is quite often used by small software developing teams, the required intensive customer involvement in XP is difficult to achieve in practice for Web projects in IT SMEs. 3.1.4

Software maintenance and evolution

Sommerville[25] proposed a model for software evolution (see Fig. 4). The model describes two phases: maintenance phase where changes are made at code level or close to code level while evolution phase involves modifying requirements and system level and the whole development process is redeployed. Though the two-phase approach is useful, carrying out every task in the process can be resource consuming and may not be suitable for SMEs.

394


Fig. 4

3.2

Sommerville0 s[22] evolution model

Why a new lifecycle model for Webbased applications in SMEs?

Can we just apply any of the above most used lifecycle models in Web-based applications development in SMEs? To answer this question, we need to first analyse the requirements for a Web-based applications development lifecycle process model in SMEs, and then evaluate whether the existing lifecycle process models can be directly applied. 3.2.1 Requirements for Web-based applications development lifecycle model in SMEs Apart from the characteristics of Web-based applications in general, for example, not enough requirement, diversity of users and sophisticated user interactions, it has been suggested that company size is a factor that could influence its development process[26] . SMEs have limited resources and therefore cannot afford too expensive documentation and only minimal management control and customer help are available. Here are some issues that need to be considered for Web-based applications development in SMEs: 1) Semi-formal project process and little documentation control, 2) Minimum design, quick prototype, and acceptance testing, 3) Backtracking needed when requirements are changed, 4) Developers with wide range of skills but lack of specialists in each area, 5) Lack of resources, 6) Tight budget and short deadline, and 7) Risk of failing to meet the deadline when using complicated development lifecycle models. A good lifecycle model for Web-based applications development in SMEs has to deal with all issues discussed above in a progressive and iterative way to meet the fast changing environment and business needs. This can be summarised as that a Web-based applications development lifecycle for SMEs needs to support 1) iteration, 2) risk minimisation, 3) immediate response, 4) no administrative overhead, 5) change management, and 6) fast development. 3.2.2 What existing software engineering lifecycle models cannot do? The sequential (i.e., waterfall) and iterative (i.e., spiral and agile) lifecycle models have proved to be good for traditional software development, but how would they fit into Web-based applications development in SMEs?

In practice, the sequential model supports easy to control and systematic approach but it is too restricted for a Webbased applications development that continuously adapt to shifting environments and applications are subject to constant adjustment. Iterative process models use evolutional approach, which gives flexibility for Web-based applications development, especially in SMEs, to fit into today0 s fast changing development environments and technology. Web-based applications are usually installed on a central server and modifications are instantly available to all users for testing, which will not generate much testing environment set up overhead through the iterative process. A major concern of an iterative process model is how to decide ending the iteration. Too much iteration can bring down the effectiveness, while with too few iterations the process can degenerate into a “build it now and fix it later” approach. A full iterative process is too complicated for SMEs to adapt as they usually lack comprehensive management control. Web-based applications development lifecycle in SMEs not only needs to be fast, low-risk, flexible, and easy to manage, but also needs to have specific activities that will consider the scalability and maintainability, and have the ability to respond to continual changes. Therefore, a lifecycle model compromising sequential and iterative processes is required.

4

A novel lifecycle model for development of Web-based applications in SMEs

To ensure a systematic yet flexible lifecycle model to be used in SMEs, the proposed lifecycle model is founded on the fundamentals of software engineering0 s iterative lifecycle model, where development teams are encouraged to adapt and improve their working practices iteratively, and the sequential lifecycle model, where tasks are preceded by the completion of previous tasks. Fig. 5 presents an expanded lifecycle model from our previous work[27] . The expanded lifecycle model will still consist three sets of activities and will emphasise that the lifecycle includes post-delivery processes, which will further enhance the chance for SMEs to develop and maintain quality web applications within limited resources and time.

4.1

Requirement processes

In Fig. 5, the set of activities of the requirement processes include business requirements, project risk analysis and planning. At this stage, the project manager considers how to compromise on functionality and performance to meet the deadline with the limited resources available in the SME, decides the number of phases for a project and produces a detailed plan for each phase. In business requirements, not only business requirements, functionality requirements, performance requirements, the development and final product environment are decided but also future changes are considered to be inevitable and rooms are reserved.


Fig. 5

The proposed web-based application development lifecycle for SMEs

In project risk analysis, the risks, such as unrealistic schedules, misunderstanding of requirements, frequently changing requirements, underestimated complexity of nonfunctional requirements, new technologies, low scalability and reusability for web-based application development are specifically addressed. In planning, high-level planning aspects such as abstract types of components, relationships, and functions are identified and resources assigned to them, and then a list of phases and their priorities are identified. For each phase, tasks needed to implement it are identified with timeslots scheduled, i.e., the phase with the top priority will go through the following iterative development processes first, and the phase with lower priority will enter the following processes in a queue.

4.2

395

Development processes

The development processes handle the list of phases identified in the above planning process. In order to make the code reusable, easy to scale, easy to maintain and robust, we apply specific phase risk analysis for each phase to produce a detailed design including interfaces, components, data structure, etc. When coding and phase testing have been completed, the whole system is tested by people who are not involved in the development process. After that, the system is ready to deploy. In risk analysis phase, the risk for a phase will be first explicitly analysed in detail, resulting in a list of potential risks, including possible non-functional requirements, impact on the existing system, maintainability and reusability. Then, it will be discussed with other developers and the person who is in charge of the project in an informal way. An alternative method to develop certain key functions and structure might be compared and discussed among the developers. The feedback from the previous stage will be assessed. In Design, a detailed design for each function including structure, interfaces design, components, data structure, navigation, and presentation will be produced, including the externally visible properties of software components and the relationships between them. In coding, the obtained completed design is coded by one to two developers. In test and evaluation, a test document for functional and non-functional testing is produced first based on the requirements. After all the tests to the identified phases are

completed, people who have not been involved in the development process will carry out a testing to the whole system, to evaluate the system0 s compliance with its specified functional requirements. Testing is focussed on modification of a released system for the purpose of maintenance where “side effect” must be checked properly. Test and evaluation activities are usually limited to internal assessments, but customer inputs are also addressed if an evaluation version was released during the iteration.

4.3

Evolution processes

A considerable expansion has been done to our work in [27] for the evolution processes. Evolution processes start when the developed application is deployed. Evolution is to modify an existing product after it has been released. Its main purpose is to modify an application at code or near-code (i.e., some designs) level to address the demand of small changes. It happens very frequently for Web-based applications due to the fast changing environment and the diversity of users/customers. They are lightweight iterative processes based on users/customers0 demands and may go many times to release up-to-date versions. They are within a small scale and will not fundamentally change the product. However, more and more small changes, i.e., evolution, may eventually lead to the re-consideration of fundamental business requirements: is it necessary to change them as well? It may trigger the running of the whole lifecycle again. SMEs should treat it as one possibility and decide based on the individual project against its cost, time, and benefits. Evolution processes include deployment, maintenance, and evolution. In deployment, after being tested and evaluated, the Web-based application is deployed on the live server and then customers would be able to use the developed systems straightaway. Maintenance is to describe activities that address “local” demands at code or near-code levels, which is applied for less complicated work due to the limited time and management control in SMEs, i.e., to enable software to be “repaired” quickly so that the software can provide better services. In Fig. 5, it can be seen that maintenance relates to design, coding, test, and deployment. They are lightweight iterative processes based on users/customers0 demands and may go many times but will not fundamentally change the web-based application. Meanwhile, evolution branches out from the maintenance

396


step, at which a decision is made whether to “repair” or to “evolve or re-engineer” the existing application. If phasing a software system is the last resort of solving a problem, deciding to conduct evolution will be the second last resort, as this will trigger the whole lifecycle including business requirements analysis and project risk analysis. There is a cost implication for going through evolution, as this may take a much longer time to bring the application back to service. SMEs should treat it as an option. This process is only conducted when it is determined that the original key requirements, planning and/or design of the software system is no longer suitable for providing services, and it can be done within the allowed cost and time scale. It can be seen in Fig. 5 that evolution is connected to other processes by dots as it is optional for SMEs, and it may trigger the running of the whole lifecycle again.

5

Case study

Exxcom Ltd is a small British IT company supplying managed services in telecommunication utilisation and cost reporting for large international organisations. The company started in 1997 to build different Web-based reporting suites which are presented on its live servers via the Internet for their clients. It started with less sophisticated functions, and then the reporting suites grew very fast to become much more complex and sophisticated. Since the existing reporting suites were developed by the ad-hoc approach and “fixed it for now” for any problem, the reporting suites are more and more difficult for maintenance and evolution. Our real-world project was to apply the proposed model for the development of a new reporting system as an add-on of the existing reporting suites. Particularly, a specific focus was on the evolution processes based on our work in [27]. It is called Web-based trunk group summary reporting system to manage telephone lines utilisation. It converts the collected telephone trunk information from clients0 sites into an interactive online report, including switching between graphical representation and tabular representation and full drill down through layers of data. Considering the sensitive nature of information relating to company0 s business and our previous work in [27], we only need to discuss some important steps, but we ensure that the information presented here is still enough to provide the whole picture of the case study.

5.1

Requirement processes

Requirement processes include business requirements, project risk analysis and planning. The main purpose is to agree on a set of realistic requirements, analyse project risks, and then break the project into small self contained phases with deadlines[27] . In business requirements, it is revealed that time allowed for the project is 6 months; data will be displayed and be loaded into the database by an existing program loader; different levels of data are required for reporting; report can be drilled down to different levels; report will be displayed in two formats: tabular and graphical; reports can be emailed to clients and graphical reports can be produced in PDF format; printer friendly report page with graphs; the new

reporting service is part of Exxitel, which is one of the existing reporting suites; and the report frame will be shared with the other reports in Exxitel reporting suites. A commercial graphical tool is needed to help the graphical report development due to the time limitation. Project risk analysis addresses potential risks to get a more accurate estimation of resources required for the project so as to minimise the project costs in the long term. The identified risks for the case study are as follows[27] : 1) Evaluating appropriate graphical packages and pick the most suitable tool that can meet all the functional requirements and potential future requirements. 2) Performance of the graphical tool when generating a huge report. 3) System architecture design which gives flexibility to add new functions in. 4) Performance to convert graphs generated by the graphical tool into PDF format. 5) Graphical tool0 s compatibility with existing server settings. In planning, a high level specification of the project was produced. A number of phases and a variety of tasks for the project are identified with estimated timescale and priority. Because of the time constraint and the complexity of the project, it was decided that three iterations were needed and details are given in the next sub-section. It is also very important to get feedback from the client.

5.2

Development processes

The processes include three iterations with a focus on technical solutions to ensure a quality implementation and to support future maintenance. The main tasks handled during the iterative processes are presented as follows[27] . The first iteration is the selection of graphical tools which include phase risk analysis — to identify both functional and non-functional requirements, potential functions and issues for future expansion, and the budget for graphical tool; design — to make some mock ups of the presentation and user interactions of the graph to meet the functional requirements; coding — to mock up the designs using potential tools; test and evaluation — to test the mock ups against functions and non-functional requirements and decide on the best three versions of the mock ups. Clients also provide their feedback to help the design of the graphs. The second iteration is for tabular report development which includes phase risk analysis — project will share some components with other reports; design — to make the user interface consistent with existing reports in the same package; coding — to make code as generic as possible; test and evaluation — to check whether the result tells what we want where clients0 feedback is sought for to help with testing. The third iteration is the graphical report development which includes phase risk analysis — how is the look and feel of the graph; how many graphs can be generated in one report; how fast can the graph be converted in PDF format; design — drill-down function is designed; coding — to make sure the code is easier to expand and maintain, and to make the graphical package reusable; test and evaluation — the performance and functions of the graphical report are tested and clients0 feedback is sought for as well.

397


After every phase in the development processes was completed, the system as a whole was tested. The company0 s technical manager, who was not involved in the above development process, carried out the testing and typical cases were designed and tested at this stage. After the outcome was satisfied, the system was ready to be deployed.

5.3

Evolution processes

Evolution processes start when the developed application was deployed onto a live server for clients to use. Following the deployment of the system, maintenance starts and it involves the modification of the system based on clients0 demands and feedback so as to correct defects and upgrade the system, which involves making small changes instead of fundamental changes to the application. It usually addresses demands at code or near-code levels, considering the limited time and management control in SMEs, in order to enable the whole system to be repaired and/or upgraded quickly. Within the 6 months project time, although some small changes were made, no big changes on original key requirements and planning were identified or required to run the whole lifecycle again. By the time this project was completed, a new reporting system was added into the existing Web-based reporting suites in the company. Following the proposed lifecycle model, the project developed the trunk group summary reporting system that operates very well. The proposed systematic but flexible approach has benefited the maintenance as well as development. At the moment, maintenance for other reporting systems at Exxcom is very expensive because they were not developed in a systematic way and the structure is not very clear. When other developers make changes they may violate the architecture as they are unaware of the underlying architecture intent. Compared to them, this project followed the proposed lifecycle model and generated a system that is well accepted by clients.

6

Conclusions and future work

It is a typical case that a Web-based application development project in an SME has a small budget, few resources, and tight deadline and is bound to continuously change to meet the changing/growing requirements. Hence, many developers use “sufficient for now” as guideline for quick development, but the developed application system is difficult to maintain, expand, and reuse. In the long term, system maintenance will take much longer time than using a systematic development approach at the beginning. A systematic approach of the Web-based applications development in SMEs, with consideration of scalability and reusability, could save a lot of resources and money in the long term for SMEs. This paper proposes a new lifecycle process model for Web-based applications development in SMEs. Although the proposed lifecycle process model includes characteristics from the traditional software development lifecycle process model, the combination and sequence of applying these characteristics are unique and therefore represent a novel approach to Web-based applications development in SMEs. The proposed model includes requirement processes, which

are sequential, and development and evolution processes, which are iterative. It reduces complexity of iterative efforts for high-level stages which involve a lot of management control such as business requirements, risk analysis, and planning, and use some iterative processes mainly in design, coding, test, and evaluation to meet the fast changing Web application requirements. Another lightweight iterative process is applied for software maintenance and evolution. The model achieves a better balance between demands for resources and quality of the software product. The proposed lifecycle process model has been applied to a real-world project in an IT SME. The current result is very satisfying due to the proposed systematic but flexible lifecycle process model. The project product has been released on time, and the system0 s architecture is very organised which leaves enough room for future evolution and can be easily integrated into other systems. It has shown the potential to shape the way how Web-based applications development can be done with a systematic engineering approach in an SME. The lifecycle process model is proposed to be a generic process for SMEs0 Web-based applications development although a number of variants are expected in the future to suit different application cases[28, 29] depending on the nature of projects.

References [1] D. Lowe, W. Hall. Hypermedia & The Web: An Engineering Approach, New York, NY, USA: John Wiley & Sons, 1999. [2] I. Sommerville. Software Addison-Wesley, 2000.

Engineering,

6th

Edition,

[3] M. Epner. Poor Project Management Number-one Problem of Outsourced E-projects, Research Briefs, Cutter Consortium, November 7, 2000. [4] R. H. Zakon. Hobbes0 Internet Timeline. [Online], Available: www.zakon.org/robert/internet/time line/Count WWW-log.gif, March, 2009. [5] S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera. Designing Data-intensive Web Applications, Morgan Kaufmann Publishers, 2003. [6] J. Conallen. Building Web Applications with UML, Harlow, UK: Addison-Wesley Longman, 1999. [7] H. W. Gellersen, M. Gaedke. Object oriented web application development. IEEE Internet Computing, vol. 3, no. 1, pp. 60–68, 1999. [8] A. Knapp, N. Koch, G. Zhang. Modeling the structure of web applications with argouwe. In Proceedings of the 4th International Conference on Web Engineering, Lecture Notes in Computer Science, Spinger, vol. 3140, pp. 771–772, 2004. [9] A. Ginige, S. Murugesan. Web engineering: An introduction. IEEE Multimedia, vol. 8, no. 1, pp. 14–18, 2001. [10] Y. Deshpande, S. Hansen. Web engineering: Creating a discipline among disciplines. IEEE Multimedia, vol. 8, no. 2 pp. 82–87, 2002. [11] C. Canali, M. Colajanni, R. Lancellotti. Resource management strategies for mobile web-based services. In Proceedings of IEEE International Conference on Wireless and Mobile Computing, Networking & Communication, pp. 172– 177, 2008.

398


[12] Z. Wei, M. Kang, W. Zhou. A semantic web-based enterprise information integration platform for mobile commerce. In Proceedings of International Conference on Management of e-Commerce and e-Government, IEEE, pp. 57– 60, 2008. [13] S. Casteleyn, P. Plessers, O. D. Troyer. Modelling and tools: Generating semantic annotations during the web design process. In Proceedings of the 6th International Conference on Web Engineering, ACM, pp. 91–92, 2006 [14] Y. Deshpande, S. Murugesan, A. Ginige, S. Hansen, D. Schwabe, M. Gaedke, B. White. Web engineering. Journal of Web Engineering, vol. 1, no. 1, pp. 3–17, 2002. [15] EU Commission Recommendation 96/280/EC, [Online], Available: www.eur-lex.europa.eu, March, 2009. [16] D. Berry. Academic Legitimacy of the Software Engineering Discipline, SEI Technical Report CMU/SEI-92-TR-34, Camegie Mellon University, USA, 1992. [17] N. Zelnick. Nifty technology and nonconformance: The Web in crisis. Computer, vol. 31 , no. 10, pp. 115–116 and 119, 1998. [18] W. W. Gibbs. Software0 s chronical crisis. Scientific American, vol. 271, no. 3, pp. 72–81, 1994. [19] R. S. Pressman. Software Engineering – A Practitioner0 s Approach, 5th Edition, McGraw-Hill, 2003. [20] R. S. Pressman. Can internet-based applications be engineered? IEEE Software, vol. 15, no. 5, pp. 104–109, 1998. [21] IEEE, IEEE Standard Glossary of Software Engineering Terminology, 1990. [22] B. Boehm. A spiral model of software development and enhancement. Computer, vol. 21, no. 5, pp. 61–72, 1988. [23] D. Phillips. People, process, and product. American Programmer, vol. 8, no. 1, pp. 15–20, 1995. [24] K. Beck. Extreme Programming Explained: Embrace Change, Reading, Massachusetts, USA: Addison-Wesley, 2000. [25] I. Sommerville. Software Engineering, 7th Edition, Addison Wesley, 2004. ´ del Br´ıo, B. Junquera. A review of the literature on en[26] J. A vironmental innovation management in SMEs: Implications for public policies, Technovation, vol. 23, no. 12, pp. 939– 948, 2003. [27] W. Huang, R. Li, C. Maple, H. J. Yang, D. Foskett, V. Cleaver. Web applications development lifecycle for small and medium-sized enterprises (SMEs). In Proceedings of the 8th International Conference on Quality Software, Oxford, UK, pp. 247–252, 2008. [28] J. Z. Li, Z. P. Zhang, B. Qiao, H. J. Yang. A component mining approach to incubate grid services in object-oriented legacy systems. International Journal of Automation and Computing, vol. 3, no. 1, pp. 47–55, 2006.

[29] Z. Zhang, D. D. Zhou, H. J. Yang, S. C. Zhong. A service composition approach based on sequence mining for migrating e-learning legacy system to SOA. International Journal of Automation and Computing. (to be published)

Wei Huang received the B. Sc. and M. Sc. degrees from South China University of Technology, PRC, and the Ph. D. degree at Loughborough University, UK. He worked as a research fellow at the University of Nottingham for three years before he joined the University of Bedfordshire, UK in 2004. He is currently a senior lecturer in the Department of Computer Science and Technology at the University of Bedfordshire. He is also a member of the British Computer Society (MBCS) and a fellow of the Higher Education Academy in the UK. His research interests include planning and scheduling, optimisation techniques, software, and web engineering. E-mail: [email protected] Carsten Maple received the Ph. D. degree at the University of Leicester, UK, and joined the University of Bedfordshire, UK in March 1998 as a lecturer. He is then made senior lecturer in September 1998 and was promoted to professor of applicable computing in 2004. He became head of the Centre for Research in Distributed Technologies in June 2003 and he became head of the Department of Computer Science and Technology in September 2004. He serves as an editor and/or co-editor in a number of academic journals or conference proceedings such as Journal of Applied Informatics and Proceedings of the International Conference on Information Visualisation. He has chaired conferences such as International Conference Parallel Computing in Electrical Engineering in 2010. He is an elected member of the Council of Professors and Heads of Computing (CPHC) Committee. His research interests include distributed system, information security, and optimisation techniques. E-mail: [email protected] Hong-Ji Yang received the B. Sc. and M. Phil. degrees from Jilin University in 1982 and 1985, respectively, and the Ph. D. degree from Durham University, UK in 1994. Currently, he is a professor at the Software Technology Research Laboratory, Faculty of Technology, De Montfort University, UK and leads the Software Evolution and Reengineering Group. He served as a program co-chair at IEEE International Conference on Software Maintenance in 1999 and the program chair at IEEE Computer Software and Application Conference in 2002. His research interests include software engineering and pervasive computing. E-mail: [email protected] (Corresponding author)