Embed Size (px)
Citation preview
A Comparison of Methodologies For Web-Based Development Jonathan Hyman
BSc Information Systems Session: 2001/2002
2
Summary
In this project I aim to investigate if two traditional development methodologies and two web
development methodologies are suitable for the development of a web-based system. The
methodologies used are SSADM (Structured Systems Analysis and Design Methodology),
ETHICS (Effective Technical and Human Implementation of Computer-based Systems), RUP
(Rational Unified Process), and OOHDM (Object-Oriented Hypermedia Design
Methodology). To do this firstly there is an examination into the exact meaning of the term
web-based, then to identify the characteristics of a web-based and traditional system. An
evaluation criterion is then created, based on the varying characteristics. This criteria is then
applied to gain an understanding of the strengths and weaknesses of each of the
methodologies.
3
Acknowledgements
I would like to thank Dr. Lydia Lau, my supervisor for giving me advise throughout the year,
and Martyn Clark for giving me advice on how to write this report.
4
Contents Page
Page Number
1.0 Introduction
1.1 Reasons for choosing the Project 1
1.2 Aim/Objectives/Minimum Requirements 2
1.3 Approach 2
1.4 Schedule 4
2.0 Background Research
2.1 What is a Web-Based Information System? 5
2.2 Traditional Information systems 10
2.3 What are the Differences between Web-Based and Traditional
Information Systems? 11
2.4 What are the Similarities between Web-based and Traditional
Information Systems? 13
2.5 Methodologies
2.5.1 What is a Methodology? 14
2.5.2 SSADM 15
2.5.3 ETHICS 16
2.5.4 RUP 17
2.5.5 OOHDM 18
3.0 Evaluation of the Traditional Methodologies
3.1 Evaluation Criteria 20
3.2 SSADM 21
3.3 ETHICS 27
3.4 Summary 30
4.0 Evaluation of the Web-Based Methodologies
4.1 Evaluation Criteria 32
4.2 RUP 33
4.3 OOHDM 37
4.4 Summary 40
5.0 Conclusion and Findings
5.1 Comparison of the Methodologies 42
5.2 Are the Traditional Methodologies useful for Web-Based
5
Development? 44
5.3 Are the Web-Based Methodologies useful for Web-Based
Development? 44
6.0 Project Evaluation
6.1 Criteria for Evaluation 45
6.2 Evaluation of the Solution 45
References 47
Appendix A 49
6
1.0 Introduction
1.1 Reasons for choosing the Project
Currently there are millions of web-based applications floating around cyberspace. They all
contain a variety of information and enable asynchronous communication. Yet unfortunately
the methodologies that are specifically for the development of web-based systems seem to be
a mixture of checklists and �ad-hoc approaches� (Lowe et al, 1999, p. xvi), which have no
formal �evaluation or measurement techniques� (Lowe et al, 1999 p. xvi). Web-based
development is currently at the stage traditional software engineering was thirty years ago.
The focus is primarily looking at �implementation and performance issues� (Lowe et al, 1999,
p. xvi) with little or no emphasis on the modelling or management processes, leading to many
systems failing or being abandoned.
Web-developers tend to focus on the technical issues of development, because as a
community the industry is not yet mature enough to understand what makes an effective
development method (Lowe, 1999). As proved by the traditional development organisations it
takes a number of years to develop a fully comprehensive methodology suitable for a range of
projects. Even now when using a methodology, one would most likely have to adjust the
methodology to fit one�s own needs.
With the majority of traditional information systems development, in-house methodologies
are used rather than commercial ones. �The most predominant reason for this is that they are
too cumbersome� (Lang et al, 2000, p.5). It is a shock that other reasons such as cost, and
difficulty to use appear much lower down in Lang�s research, than what is previously
explained. Users of methodologies tended to identify that they were not suited to the real
world. This shows that the majority of methodologies are only partly effective in the job they
are supposed to do. Therefore it is unclear whether methodologies are indeed useful in
developing systems.
Although web-development has no standard framework or a general understanding of what is
involved, various approaches have appeared on the market. �These vary from design check �
lists, to experts pontificating on how to approach various aspects of design; to formalised and
structured design methodologies� (Lowe, 1999, p.9). These have tended to be a mixture of
ideas on conceptual and navigational design, with little or no reference to processes or any of
techniques, such as project management that have recently appeared in traditional approaches.
�No methodology has emerged to cater the needs for a systematic and methodological
approach to complex and dynamic web application development� (Enguix et al, 1999, p.1).
7
This project is therefore focusing on the idea that these methodologies are not suitable for
web-development, and tries to understand what makes a good methodology? What are the
different types of methodologies used? What defines a web-based information system, and
what makes it different from a traditional system? �Are traditional roles, methods, and
techniques relevant in the development of web-based systems� (Ruppel et al, p.1, 2000)? Plus
are these methodologies useful for the development of web-based systems?
1.2 Aim
To evaluate four different methodologies for use in web-based application development, and
to evaluate the criteria for their evaluation. Plus to answer the question, are they useful for the
development of web applications?
Objectives
• Select and study several methodologies covering traditional methodologies.
• Identify what is meant by web-based.
• Identify and study at least one methodology specifically developed for web-based
development.
• Identify the characteristics of a web-based system.
• Formulate a criterion for evaluating the chosen methodology for building a web-
based application.
• Compare the strengths and weaknesses of the methodologies.
Minimum Requirements
• A section within the report of background research into each of the chosen
methodologies.
• Written criteria for the evaluation of the methodologies.
• A written comparison of at least three methodologies.
1.3 Approach
To undertake this project there needs to be a thoroughly researched approach of how to
achieve the best possible out come. Firstly it is necessary to understand what is meant by a
web-based system, and why it is so important to distinguish the differences between
traditional and web-based systems. It will therefore be possible to comprehend what is needed
in an effective methodology for their development.
8
Then a sample of methodologies to study will be taken. These will be SSADM (Structured
Systems Analysis and Design Methodology), ETHICS (Effective Technical and Human
Implementation of Computer-based Systems), RUP (Rational Unified Process), and OOHDM
(Object-Oriented Hypermedia Design Methodology). They have been chosen for their
variation, focusing on different ways of developing systems.
Firstly SSADM is a structured approach focusing on systems functions with a large amount of
documentation. It was developed in the eighties by a section of the UK�s civil service for use
by the government (Eva, 1992, p.3).
ETHICS is a soft approach to systems development concentrating on the people aspects. It
differs from SSADM in its relaxed attitude, not providing exact guidelines for development,
but advice on the method proposed with the user making up their own mind on the level of
documentation used (Mumford, 1995).
The RUP provides a methodology for specific use with web-based development. It is an
extension of its �software development process� (Jacobson et al, 1999, p.xviii) incorporating
the object-oriented techniques used in the original process (Jacobson et al, 1999).
Finally OOHDM has been chosen because of its development specifically for web-based
systems. It is one of many methodologies used to aid users with web-based design (Rossi et
al, 1998).
These methodologies offer a varying approach to system development. It will be the purpose
of this project to evaluate them all for their usefulness in the development of web-based
applications. To carry this out effectively, a criterion will be used based on the characteristics
of what constitutes a web-based application. Information will be gathered from a wide range
of sources in order to conclude with a well-balanced and unbiased opinion of their use.
The conclusion will include a comparison of the methodologies comparing their performance
to the others. Answering questions such as were the ones specifically for web-based
development more useful that the traditional methodologies or vice-versa. How can they be
improved, and are these methodologies really suitable for web-based application
development?
9
1.4 Schedule
1.4.1 Plan
1) Decide on the methodologies to investigate.
2) Investigate the characteristics of traditional and web-based systems.
3) Determine the similarities and differences between traditional and web-based systems
4) Study the methodologies.
5) Determine a set of criterion to evaluate the suitability of traditional methodologies.
6) Evaluate the traditional methodologies.
7) Determine a set of criterion to evaluate the web-based methodologies.
8) Evaluate the web-based methodologies.
9) Summarise the findings.
10) Develop a conclusion.
11) Evaluate the project.
10
2.0 Background Research
2.1 What is a Web-Based Information System?
For the purpose of a project of this type it is necessary to understand what is meant by the
term web-based information system.
According to Iskowitz et al a web-based information system encompasses these kinds of
system:
• Web presence sites that are marketing tools designed to reach consumers outside the
firm.
• Electronic commerce systems that supports consumer interaction, such as online
shopping.
• Extranets that support business-to-business communication.�
(Iskowitz et al, 1998, p.78)
For this project the focus will be on systems that communicate through the Internet, not
including systems running on a local area network.
The above systems are characterised by their:
• �User-interfaces
• Purpose
• Users
• Multimedia contents�
• Design (Lowe, 1999)
• Security (Conallen, 1999)
• Software (University of Aberdeen, 2001)
• Development Cycles (Rational Software Corporation, 2000)
These will now each be discussed in subsections.
2.1.1 User-Interfaces
�User Interfaces provide the mechanism by which users interact with an application and make
use of their underlying functionality� (Lowe et al, 1999, p.147). Much of what goes into an
interface is designed by an artist with cognitive concerns, it is important to understand user
perceptions and attitudes when navigating through an application. Many applications that
have good content, fail because of inadequate interfaces.
All interfaces are viewed through a browser at the client end of the application, which for
example would be Microsoft Internet Explorer or Netscape Navigator. It is usually necessary
for the designers to ensure that their interfaces can be viewed using each browser. It would
cause problems if the interface could be viewed through one browser but not the others.
11
�Should your software fail, so too could your business� (Rational Software Corporation,
2000, p.4).
It is also important to keep and attract interest from a variety of users. The interface plays an
imperative part in doing this, especially when on the World Wide Web users are �only a click
away from the competitor� (Clemmensen, 2001, p.2).
2.1.2 Purpose
A web-based application can be used for a variety of means, as is much diversity when
browsing the WWW. The following table is a classification of websites taken from Vindbjerg
(2001), (Clemmensen, 2001, p.4):
Purpose Description
Contents Sites which spread information, for which the primary responsibility is
to secure quality and actuality in this information.
Transactions Sites characterised by the possibility for the user to make or activate
more or less physical movements.
Branding Sites which are very expressive and user oriented and for which
recognisability and consistency between the site and other media is of
primary importance.
Service Sites for which it is important to create and keep a user relation.
Entertainment Sites offering only entertainment, often sub sites of other sites.
Table 2.1.2: purpose of websites (based on Vindbjerg, 2001) taken
from (Clemmensen, 2001, p.4).
It is quite probable that most sites will be a mixture of these, yet when designing an interface
it is necessary to have one of these purposes in mind. It is important therefore for the
application to �deliver a message between server and client, rather than just passing simple
information� (Clemmensen, 2001, p.4). This ensures the application will include two-way
communication, with an improved amount of functionality (Clemmensen, 2001).
2.1.3 Users
Depending on the type of web-application that is being developed will determine its� users.
When mentioning inter-organisational systems such as intranets the users are determined by
their �organisational relationship: their tasks and department� (Clemmensen, 2001, p.5). For
open websites it is not possible to single out a set of users, there tends to be target audiences
in the context of when a business is trying to target a specific group to sell their product or
12
service. These users are known as �surfers� which the organisation wish to become users, in
the sense that they will incur some sort business relationship with the server organisation.
(Conger, 1998)
When thinking about websites that have a �branding� (table 2.1.2) purpose it is important to
remember that users will only us the website if they find it immediately rewarding�
(Clemmensen, 2001, p.5), therefore they are not required to use the system. User attraction is
achieved by good interface design and by varying degrees of marketing. (Conallen, 1999)
2.1.4 Multimedia Content
The majority of web applications tend to use some sort of multimedia media elements. An
entirely text based system would not produce the desired effect needed to attract the interest
of potential users, if that was the purpose of the application.
The majority of applications will include one or more of the following media functions:
�graphics, pictures, animations, video, audio, or even virtual reality� (Clemmensen, 2001,
p.5). Impression is a very important and the effect of multimedia elements can influence a
users impression. This therefore is an influential aspect of web-application design.
(Clemmensen, 2001)
2.1.5 Design
There is great importance on the design of web-based applications. Firstly there are many
guidelines in practice regarding the design of user interfaces. The Rational Corporation has a
widely used set, which includes procedures for the designer to define:
• �The mood of the site
• How users will be accessing the site
• The browsers the users will be using
• The use of frames
• Colour limitations� (Rational Corporation, 2000, p.3)
Others areas that need extensive design include the navigation of the web application, which
done poorly usually results as a turn off for users. (Rational Corporation, 2000) The users
information needs require special attention in order to �provide access and navigation
mechanisms that will enable different users to quickly easily find the information they are
looking for.� (Lowe, 1999, p.279)
Other design requirements include a conceptual design to fully comprehend the functional
needs. The design is a model of the application domain, in the object-oriented way of
developing.
13
2.1.6 Security
Much has been made recently regarding the safety of web-applications and the possibility of
criminal hackers. Technology such as encryption and firewalls are an increasing occurrence to
support web applications. Password-protected pages that use encryption as their main weapon
against hackers tend to �address issues of transmitting or accessing sensitive information
(such as credit card details)� (Lowe, 1999, p.75). Encryption is a process whereby a
mathematical algorithm is used to �describe how a piece of data is to be encrypted� (Whyte,
2001, p.243).
A firewall �cuts down the amount of access points open to a potential attacker and patrols
these rigorously� (Whyte, 2001, p.240). This type of security is very applicable to all types of
web system in order to preserve �confidentiality and privacy, availability (their ability to
provide a service), and authority and accountability� (Whyte, 2001, p.227).
2.1.7 Software
The web browser is currently the preferred software to access online information. Any type of
information within a web application can be viewed through a web browser and it the job of
the developers to ensure this is true for their system. A single piece of software for accessing
information enables many forms of cross-referencing and linking. It provides excellent
opportunities for users to be able to manage their information sources at the information level
rather than the computer systems level. (Lowe, 1999, p.509) (University of Aberdeen, 2001)
2.1.8 Development Cycles
With the massive explosion of the web in the late nineties many developers became over
excited by the prospect of cashing in on the webs boom. By developing too quickly they
ignored some very important engineering principles and ended up with poorly design systems.
Without �compelling user interfaces, as well as robust architectures (see section 2.1.9.3)�
(Rational Corporation, 2000, p.7) users will become impatient and move to another site that
may belong to a competitor.
Without sound software engineering principles there is always the greater possibility of
failure. Software engineering focuses on �quality, driving toward solutions iteratively while
reducing risk, and a concentration on flexible architectures� (Rational Corporation, 2000,
p.7). The following processes used by the Rational Corporation would support sound
engineering within a web application context:
14
2.1.8.1 Develop Iteratively
This is based around the approach of continuous discovery whilst developing. There is a need
within web development for short rapid cycles because web technology is rapidly getting
more powerful, and there is always a need to stay ahead of the competition.
2.1.8.2 Manage Requirements
Web application requirements can change frequently, based on market trends and tastes. It is
imperative to be able to keep up to date with them, and alter the development life cycle
according.
2.1.8.3 Component Architectures
Architecture is the structure of the components of the system, the way they integrate and the
instruments by which they interact. Component architectures can adapt to the changes
experienced within web-based development. The architecture can also be bought from
software development companies, which may be an advantage, as they would already include
all the functionality needed, for a successful system.
2.1.8.4 Verify Quality
�Web applications are intended for public exposure� (Rational Corporation, 2000, p.8),
failure is a very high price to pay. Many systems are re-released frequently, testing early is
very important to prevent the risk of failing and customer rejection.
2.1.8.5 Control Changes
Modification is an integral part of the development life cycle. �Controlling changes in this
continuous development and deployment environment is essential� (Rational Corporation,
2000, p.8). Change management is a vigorous and significant section of the life cycle and to
ignore this, is a policy to fail.
(Taken from Rational Corporation, 2000, p.7-8)
15
2.1.9 Characteristics of a Web-Based Information System
In conclusion to the explanation above these are the characteristics that are the focus of this
project.
• User Interfaces: web-based systems have specifically designed interfaces for ease of
use, plus they must have the ability to keep users interested.
• Purpose: they have the ability to behave in a number of ways i.e. transactions,
branding etc.
• Users: being part of a specific target audience identifies them, yet they are not
required to use the system.
• Multimedia Contents: The application may utilise several types of multimedia
contents.
• Design: Must include interface design, conceptual and navigational models.
• Security: Must use some type of Internet security such as encryption.
• Software: web-based systems use web browsers to access online information.
• Development Cycles: software engineering practices geared towards web engineering
are used for its development.
2.2 Traditional Information Systems
For the purpose of this project a traditional system has certain distinct categorised types:
• Transaction processing systems, process the individual transactions of a business, the
day-to-day operations of the organisation.
• Decision-support systems aids the decision maker, it is designed to aid the managers
ability to make effective decisions.
• Experts systems simulate the role of the human expert, to diagnose the reasons for
failure in a business of technical process.
• Office automation systems, such as word processing voice mail, etc.
(Avison et al, 1995, p.4-5)
Whereas these systems would tend to involve online activities such as email processing and
the use of a web browser, they are not online systems. This means they are not accessible
online and do not involve the use of any Internet working activities such e-commerce
transactions, or an online trading system such as that as used by the London Stock Exchange.
16
2.3 What are the Differences between Web-Based Systems and Traditional Systems?
Web-based systems have a lot of similarities with the older traditional systems. Many of the
development techniques are the same, yet there are some major differences between the
characteristics of the two types of system.
Firstly web-based systems are very much focused on appearance and feel. They include
multimedia to enhance the presentation of the interface. The front-end of the system is of
major importance as user interaction can determine the success of the business that owns it.
Traditional systems tend to focus on the functionality. They do not need to focus on the
interface as much as their user group has already been established (Deshpande et al, 2001).
The users of web-based systems are not specified unlike those of a traditional system that are
known prior to implementation. As a result of this web-based systems have to cater for users
with a variety of skills such as first time users, computing professionals or those with
disabilities e.g. dyslectics, the deaf and even possibly blind people. This �complicates human-
computer interaction, user interface and information presentation� (Deshpande et al, 2001,
p.5).
Another point to make about the users of a web-based system is that they have no interest in
helping with the development of the system (this may not be the case for extranets). If a user
is interested in the site they will use it, yet getting them to help with requirements gathering
and testing would prove difficult. (Clemmensen, 2001, p.7) Users of traditional systems are
more likely to help with its development as they are designed to improve working conditions
and the efficiency of how a task is carried out.
Traditional systems focus more on the functional requirements needed in order for the system
to succeed such as the efficiency of how a task is carried out as mentioned above. �There is
the assumption that the users have some tasks they want to perform, and that the system
should assist them to complete these tasks as efficiently as possible� (Clemmensen, 2001,
p.7). This may not be the case when developing web-based systems. If a user goes to the
website Play.com, they may not necessarily want to buy a DVD but have other less-defined
goals. As mentioned in Clemmensen, 2001, p.7, these may include:
• �To get an impression of an e-commerce site
• To see what�s available
• To find an idea for a present
• To buy a DVD, but open to other suggestions�
17
The development of a web application is much more of a mixture between art and science
than a traditional system would be. The use of a web application to market a product or
service is used greatly in the commercial world. To do this many companies use many
multimedia elements. As mentioned in section 2.1.4 the type of media that could be used for a
marketing purpose would include graphics, video, sound, and animation. Most of these would
not instantly be needed in a traditional system, therefore it would not be the concern of the
computing professionals to have extensive knowledge of computer animation or any of the
elements mentioned above. Most of these skills are known by specialists in these areas,
therefore web application development is undertaken by individuals who do not specialise in
an area of computing, as well as those who do. (Clemmensen, 2001, p.7)
Traditional systems do not have the ability to behave in many different types means. What
this means is that while if necessary, traditional systems could be used for branding or
entertainment it would usually not be needed. These systems are not designed with external
users in mind; rather they behave in a transactional sense. (Conger, 1998)
The software used for interaction of the two types of system is different. Traditional systems
tend to use a specially designed browser or something such as Microsoft Access© or
Microsoft Excel©. The web-based systems all use a web browser as a standard. (University of
Aberdeen, 2001)
Web-based systems have the ability to be updated constantly and quickly. The iterative
development of a web-based system is needed to be able to stay ahead of the competition. If a
traditional system needs to be updated it tends to take a lot of planning and time. It is not as
necessary for these systems to be very quick in its redevelopment. This tends to be as a result
of not having to consult the users, whereas traditional systems users need to be consulted
before any updates go ahead. These systems are not designed as a direct tool in the contest
against the competition, rather to improve the efficiency of the organisation. (Conallen, 1999)
Table 2.2: Summarising the differences between Web-Based and Traditional Systems.
Web-Based System Traditional System
A lot of multimedia use Limited multimedia use
Much more emphasis on an artistically
created interface.
Less emphasis on the interface, much more
on functionality.
Unknown users Known users
18
Therefore limited user participation in its
development
Users participate in development processes
Have a marketing role Only used for the exchange of information
Developers with many specialities used All developed by computing professionals
Have many different purposes Mainly for transaction processing
Non-specialised browser Specialised browser
Ability to be updated constantly and quickly Needs lengthy planning to be updated
2.4 What are the Similarities between Web-Based and Traditional Systems?
Firstly many believe that the interface of a web-based system has many differences to that of
a traditional system. This is not entirely true; firstly there is the notion that a well-designed
interface will enable the user easier use of the system. This is the case with any type of
information system; a satisfied user or one that is able to use the system is likely to get the
most from it. Traditional system users would work with greater efficiency and web systems
users would use the system to either buy a product or gain enjoyment from using it. A user
wants a system to help them do something more efficiently, such as process some accounts or
buy something without leaving their house. They are both intended to make life easier
(Ambler, 2000, p.1).
Web systems tend to support work, as do traditional information systems. Therefore they are
usually integrated with databases and other transactional processing systems (Bieber et al,
1998).
It is important to remember that web-based system need the same processes as traditional
systems to succeed and perform as they are suppose to. A requirement gathering is very
important for both types of system; web-based developers must understand the market they
are entering into, what is needed, and how they are intending to succeed. A traditional system
developer will also need to understand its intended market, in its case the users. (Dennis,
1998)
The design of the two types of system would normally be constructed in a similar manner,
there is likely to be a conceptual model, and a developed understanding of how the system
will be implemented (Booch et al, 1999).
The process of testing is very important for both systems, it is up to the development team to
determine how this is done, but there will be an amount of similarity in their approaches
(Booch et al, 1999).
19
It was mentioned in section 2.2 that the users of a web-based system have no way of assisting
with its development if they do not want to. This will cause problems, as any system will need
some sort of user participation its development otherwise it may fail. (Vowler, 1992)
Table 2.3: Summary of the similarities between Web-Based and Traditional Systems
Users want the same outcome: to make what they do more efficient.
They are usually integrated with databases and other transaction processing systems.
They require effective project management processes.
User participation is critical to successful systems development.
Both are plagued by user acceptance problems.
2.5 Methodologies
This project is determined with investigating whether a traditional systems development
methodology is suitable for the development of a web-based system. It therefore is
appropriate to give an understanding of what a methodology is and why an organisation might
deem it fitting to use one.
2.5.1 What is a Methodology?
The British Computer Society defined an Information Systems methodology as �a
recommended collection of philosophies, phases, procedures, rules, techniques, tools,
documentation, management, and training for developers of information systems� (Avison et
al, 1995, p.418). Avison and Fitzgerald define a methodology �as a series of recommended
steps and procedures t be followed in the course of developing an information system�
(Gough, 2001, p.23). Avison and Fitzgerald also set out a number of components that should
be covered by a methodology:
1. How a project is to be broken down into stages
2. What tasks are to carried out at each stage
3. What outputs are to be produced?
4. When, and under what circumstances, they are to be carried out
5. What constraints are to be applied?
6. Which people are to be involved?
7. How the project should be managed and controlled
8. What support tools may be utilised.
(Avison et al, 1995, p.418-419)
20
If a company should use a methodology, why should they?
• To improve the quality and effectiveness of the development process; and
• To produce, as a result, a better end product, a better information system.
(Gough, 2001, p.23)
The following is an introduction to the four methodologies being used for this research. It will
include the reasons why they were chosen, a proof they are methodologies and a general
explanation of what they involve.
2.5.2 SSADM (Structured Systems Analysis and Design Methodology)
SSADM was originally developed in the eighties by a section of the UK�s civil service for use
by the government. SSADM although initially developed for government use only soon
became available throughout industry and academia. In 1986 a 3rd version was launched to
cope with the increase in online processing, and in 1990 a fourth version was introduced to
cover a statement of requirements. (Eva, 1992, p.3-4)
�SSADM provides thorough guidelines and rules for development staff to follow� (Avison et
al, 1995, p.294). It uses documentation throughout the whole development process as a way
to set standards for the project development. There are seven stages within SSADM version 4,
�activities of each stage are precisely defined as are their associated end-products� (Avison et
al, 1995, p.294).
• Feasibility
• Investigation of current environment
• Business system options
• Definition of requirements
• Technical system options
• Logical design
• Physical design
(Avison et al, 1995, p.294-295)
Project management procedures occur within the methodology framework for the use of the
accurate activities, introduced within the PRINCE management method.
The methodology does not cover any type of implementation guidelines. This includes any
type of planning for the implementation, it is assumed to be �installation-specific and
therefore not covered by the methodology� (Avison, 1995, p.296).
21
SSADM was chosen for this project because it is one of the most well known methodologies
and has been in use since the 1970s. It has a very detailed set of guidelines and project
management processes, which is identifiable in most traditional methodologies. While
SSADM claims to be useful for the development of some sort of web system there is an
assumption for this project that it will not be useful and therefore will be a good comparison
with a methodology assumed to work.
Through using Avison and Fitzgerald�s components for a methodology SSADM appears to
cover all of these components by a process of studying the many types of literature on
SSADM, including the official user manual. It is not necessary to give a more in depth
understanding of the reasons for this, as this is an assumption that any computing professional
would agree with. It would not alter the outcome of this project.
2.5.3 ETHICS (Effective Technical and Human Implementation of Computer-
based Systems)
ETHICS was designed by Enid Mumford in 1995 (Avison et al, 1995) and is different to the
majority of methodologies concentrating on the people issues of systems development. �It
encompasses the social-technical view that for a system to be effective the technology must
fit closely with the social and organisational factors� (Avison et al, 1995, p.353). As with
SSADM, ETHICS only provides guidelines on requirements analysis and the design of a new
system. Yet its approach is very different concerning itself with �the successful integration of
technology with the needs of the users� (Mumford, 1995, p.vii).
ETHICS splits itself into various systematic steps based around firstly the �diagnosing needs�
(Mumford, 1995, p.27) of the project which is the requirements gathering stage, secondly
there is a stage-by-stage guide to designing the system. It also incorporates various
�diagnostic and design tools� (Mumford, 1995, p.29). Based on Avison and Fitzgerald�s
components of a methodology ETHICS covers points 1, 2, and point 8 very easily, in
simplistic terms for simple development. Mumford also discusses the use of user participation
and professional developers. Mumford sees user participation as an equivocal part of system
development including it in every part of the methodology.
ETHICS supplies users with a managing change guide, giving a project management sense to
the methodology with sections on how to blend the relationships between �people,
technology, tasks and the organisational environment� (Mumford, 1995, p.8). It proves that
ETHICS is not just an approach to systems development with primarily unstructured
22
techniques, but provides a systematic process by which a system is to be development using a
�socio-technical� (Mumford, 1995) methodology.
Although ETHICS has a well-developed focus on the less appreciated aspects of system
development it lacks the technological know how to be useful for the development of a web-
based system. It is too socially oriented for a less known development process. Therefore it is
not likely to be able to cope with the lack of practice of web development, as people are not
ready to develop web systems in such a way. The assumption for this project is that ETHICS
is not suitable for web development; it will be necessary to prove this later.
2.5.4 RUP (Rational Unified Process)
The RUP was released in 1998 (Booch et al, 1999, p.xx) by the Rational Corporation. For the
purpose of this research the extension to the RUP will be used. It was designed by Ward and
Kroll and is portrayed in a paper �Building Web Solutions with the Rational Unified Process�
(Rational Corporation, 1999). It was developed to be used with the rest of the RUP not
instead of, and therefore has the great advantage of having a very well developed traditional
software engineering process.
The RUP was initially chosen, as it is a new object-oriented methodology, not an older
functional approach such as SSADM. The RUP also contains workflows for the
implementation and testing of a system, which ETHICS and SSADM do not. It is designed
for the development of large information systems and therefore may not be useful for all types
of web applications. Still it may be very useful because any systems development whether
traditional or web-based needs effective project management techniques, which the RUP has
in a great amount of detail.
The RUP is made up of �core workflows� and �phases�(Booch et al, 1999, p.11), which are
the different stages and time between various major points respectively. The extensions for
web solutions are integrated into each of the �core workflows�, allowing them to be used
within the main process. It is primarily concerned with developing a system that has a
creative design as well as the traditional software development techniques. Additions made
that improve the design of the solution include a �navigation map, and creative design
elements� (Rational Corporation, 1999), ensuring a visually compelling system as mentioned
in section 2.1 (Rational Corporation, 1999, p.1). This will be discussed later in the context of
its suitability. The RUP on first sight seems to provide a well-balanced approach, combining
23
knowledge of the understanding of web solutions as well as the detail and project
management to build a successful system.
2.5.5 OOHDM (Object-Oriented Hypermedia Design Methodology)
OOHDM (Rossi et al, 1995) is a methodology for the design and implementation of
hypermedia applications implemented on the web (Lowe, 1999, p.341). Hypermedia
applications are those �which use associative relationships among information contained
within multiple media data for the purpose of facilitating access to, and manipulation of, the
information encapsulated by the data� (Lowe, 1999, p.32). This is relating to the linking of
objects that make up applications, particularly important when discussing web applications.
The links between the interface and the supporting software are the link and cause of the
navigation design principle. Therefore the OOHDM is particularly relevant for the
development of web-based systems, with particular advantages to providing information to
the developer (Rossi et al, 1998).
OOHDM is totally based on the development of a web application and was never precluded
by a traditional method, or anything based around traditional information system
development. It provides a comparison for this project by being the only methodology
development produced for the development of web applications. The question posed asks will
it be better than a �traditional methodology�? This will be analysed throughout this report.
�OOHDM uses four stages of development, carried out in an incremental process� (Lowe,
1999, p.341). These include:
• Domain analysis
• Navigation design
• Abstract interface design
• Implementation
(Lowe, 1999)
Domain analysis is concerned with the building of a conceptual model, primarily relating to
the domain of the system rather than structure or functionality (Lowe, 1999). �The navigation
design is where user profiles are used to guide the design of the navigational structure�
(Lowe, 1999, p.341). Then the interface is modelled as well as behaviour definition between
the interface and the navigation objects. Finally �interface objects are mapped onto
implementation objects� (Lowe, 1999, p.341).
24
OOHDM provides users with the phases to carry out their development. It makes clear what
is expected within each phase, what is to be delivered and the tools to do this (Rossi et al,
1998). It is also an object-oriented approach, it will be interesting to understand if this would
make any difference to the web design. OOHDM is designed to make the most of the new
understanding and developments in the object-oriented approaches. Their framework for
enhancing the information systems in conjunction with the web design is meant to �improve
the access to the information resources� (Rossi et al, 1998, p.27-28).
One of the problems that has been noticed already with OOHDM is that it does not include
any requirements gathering tools or any instructions on how this should be performed (Rossi
et al, 1998), it is assumed to already to have taken place.
25
3.0 Evaluation of the Traditional methodologies
3.1 Evaluation Criteria
Evaluating methodologies is a process that many professionals disagree about and there are
many different issues and frameworks to be influenced by. The main reason for evaluating
methodologies is to �have a better understanding of the nature of their features, objectives,
philosophies in order to perform classifications and to improve future systems development�
(Avison et al, 1995, p.434).
It is important to have separate criteria for the evaluation of the two types of methodology.
The assumption is that a traditional methodology would not be useful for the development of
a web-based system, therefore it is necessary to view these in a different light from those
known as web development methodologies, which it is assumed are useful for building web
applications. Following is the criteria for the evaluation of the traditional methodologies and
the justification for this criterion.
• Is there any mention of the use of the web as a support tool or an alternative to the
server currently being used? Although this is not essential, any mention of the web
within the first stages of the methodology, would give a user the opportunity to
follow this up and look into the methodology more carefully. It would save time if
the user wanted a quick reference approach, although this is not advised.
• Is there a specified approach to developing effective user interfaces? What will be
looked for is reference to artistic specialists, cognitive issues and the use of
multimedia element, as well as specific interface planning and design. As specified
in section 2.1.1 it is one of the most important sections of the system and is the
cause of the failure of many web systems.
• Within the requirements gathering section, does the methodology make allowances
for unknown users? Is there a way to design the system without much user
participation if necessary? Website developers find it difficult to get users
involved in the development side, as sometimes they are unsure of exactly who
their users are. Methodologies that would be useful for web development would
need to give alternatives to user participation.
• Is their specification on the use of multimedia? Although this is not essential many
web applications do make use of multimedia to make their system seem more
attractive. Guidelines on its� use and development would aid any web application
developer.
26
• Does the design of the system include all necessary alterations in order to make
web system design? Does it create a good hypermedia navigational environment,
as well as the traditional conceptual and interface designs? It is necessary for a
methodology to split the two design areas up, as conceptual modelling is
concerned with the �objects and behaviours in the application domain, navigation
design is aimed at organising the hyperspace taking into account users� profiles
and tasks� (Rossi et al, 1999, p.241).
• Does the methodology provide information on how to make a system secure from
hackers? A methodology must give advice on how to best to employ security
technology. Firewalls and encryption are at the forefront of Internet security, and a
methodology should mention these. (Conallen, 1999)
• Does the methodology provide adequate development cycles? Are there separate
sections for requirements, design, implementation, and testing? As mentioned in
section 2.1.8 software engineering principles are essential to creating a sound
system.
It is important to recognise here that these criteria are for determining whether these
methodologies would be useful for building web-systems only. There will be no discussion of
their use for traditional systems development such as a database system. Therefore there is
little mention of the use of databases and transaction processing systems, as support tools
within a web-based system, although it is assumed these can be used. The concentration is
primarily focused on those characteristics that are firstly unique to web-based systems, as
well as those, which are essential to a sound development (development cycles).
3.2 SSADM
3.2.1 Mention of the Web
The process by which this was undertaken was primarily reading books, papers, journals, and
material found on the web. Based on the evaluation recorded above, an investigation was
carried out developing a conclusion regarding each of the criteria; answering the question did
SSADM cover this area of web-based development?
SSADM is not known as a methodology for web-based development; therefore it would be
extremely difficult to find any reference linking the methodology with any type of web
development. There are many examples of the use of SSADM in many types of
documentation. The first process undertaken to determine this, was to look in books found in
the library. SSADM books contain a lot of information regarding the processes and
27
documentation needed to fulfil its criteria, much of what is mentioned within the texts, bases
most of the technical details in the users hands, therefore assuming computing specialists
carry out the majority of the development. Therefore it is first and foremost a methodology
for a large system that wants a very thorough management process. There is not a single
reference to any type of web development in any text on SSADM. This may be because of the
time it was developed in the seventies and revised in 1990. This was before the boom caused
by the Internet, and before any major companies thought about investing in the Internet. Also
it seems SSADM is hard to use and develop with. Evidence for this is found on the Internet
with many companies abandoning their attempts to use the methodology, citing reasons such
as �demanding processes and limited ability to revise to suit your own specifications�.
(Harriot-Watt University, 1992) Most of the failures recorded are government projects, with
millions of pounds wasted. The last version of SSADM was released in 1990, over twelve
years ago and has not been updated since, which appears to be a reason for it disuse today and
probably in the future. If there were problems with its use for traditional systems, how can it
be suitable for the development of a web-based system? (Eva, 1992, Hares, 1994, Longworth,
1992)
There is no mention of the web within SSADM, yet this does not mean it has no use for the
web application developer. The next process to carry out is a study of the characteristics of
the web-based system and to understand whether SSADM is useful in the design and
implementation of these characteristics.
3.2.2 User interfaces
According to SSADM user participation is very important to the successful building of a
system (Eva, 1992). Interface face design is a very important aspect of a web-based system,
having the role of attracting users or potential users i.e. �surfers� (Conger, 1998). Therefore it
has to be asked why there is no mention of interface design, that SSADM is not suitable for
the design of a web-based interface. (Conallen, 1999) This analysis was achieved by studying
much information on SSADM and the interfaces within a web systems and coming to this
conclusion based on a balanced amount of material.
To do this, the process used was to investigate the use of SSADM for the purpose of interface
design, to find out if there is any guidance on designing an interface as well as its reference to
artistic specialists, who play an important role in interface design (Section 2.1.1).
SSADM uses a thorough requirements gathering process which enables a developer to
understand exactly what the user requires (based on a traditional system), this should at least
28
give an understanding of the needs of the interface. Therefore it may still be possible to carry
out some sort of interface design, although there are no specific guidelines to do this. From
this information, it was then decided to carry on with this research, even though it seems a
difficult task to develop a web interface.
Firstly are mentioned above it could be useful to use the requirements gathering process, also
there is an enormous amount of modelling that describes the function of the system, known as
logical models. These help us understand the relationship between functions and the business
logic lying behind the current system (Eva, 1992, p.331). It helps to comprehend the models,
which achieve the underlying structure and backbone, giving support, and information on
what the interface should do and how it should behave. (Eva, 1992)
Whereas SSADM could be useful for a conceptual model regarding the interface, it lacks in
presenting the user with any alternative to using a computing professional. There is no
evidence that someone who may not be a computing professional could apply the
methodology. Nor is there any reference to the fact that an artist or an expert in cognitive
science could design an interface. It�s hard to believe that a methodology so widely used and
assumed to be very useful could have no explanation regarding interfaces, or interface design.
3.2.3 Unknown Users
The previous section also ties in with a discussion on the users role within SSDAM, it is clear
that SSADM promotes user participation in many areas of development. There is reference to
this in many texts and presumably this has been undertaken in many projects. An impression
of the level of user participation was possible by looking through the SSADM manual,
looking for specific instances. These appeared to be primarily in a decision-making role for
future development and design (SSADM manual, 1990). During this process it was possible
to investigate into the possibility of unknown users, would it seem a problem for the project to
continue, based on the amount of participation? Also were there any guidelines for this
eventuality? The answer is that these eventualities, which are very frequent in web
development, are not catered for by SSADM. This seems to be because of the use of the
feasibility study, which is based around the environment of the proposed system. The owner
of the problem being solved by the system explains this, plus the users involved in
requirements gathering. The design relies specifically on these stages; therefore it could not
be possible to come to any other conclusion. (SSADM Manual, 1990, Eva, 1992, Hares,
1994)
29
3.2.4 Multimedia
When looking into the use of multimedia within SSADM, it was possible to just view the
index of any document. SSADM appears from the research to be a methodology that focuses
on the processes by which to achieve a system and does not have any guidelines on the types
of hardware or software to be used. Just from this simple process it obvious that there is no
clear guidelines for the use multimedia within a SSADM project. (Eva, 1992, SSADM
Manual, 1990)
3.2.5 Design
The process by which SSADM design�s projects is in two sections firstly the logical structure
is developed. It is plausible to view a system in just its logical view, which is how SSADM
wants developers to build up to a full physical design. The logical design is firstly about
getting the user to determine their technical requirements, although there is no advice on what
to use. Then to carry out the logical design, which collects the information from the opening
stages, then model them with the technical requirements ready to be inputted into the physical
design.
We then want to know about SSADM�s ability to produce a navigational design, how do the
users move around the system, can the design stages within SSADM be adapted to do this?
Throughout the stage on logical design there are processes identifying the system options, the
technical options, identifying all functional and non-functional requirements. These are stages
for decision-making that precedes the design; and they do not help with the navigation of a
user. Then there is the �user dialogue stage, distinguishing the logic of the exchange of data�
(Eva, 1992, p.59). This does help determine how the user interacts with the system, but rather
than showing the possible direction a user may take to get what they want, it concentrates on
the flow of data through the system. It is similar to the use of an activity diagram within
UML, documenting the dynamic view of the system. Therefore it can show the possible
actions of the system, not just from the input of human users, but also through interaction
with other systems. It is reasonable to get some sort of understanding from the dialogue
design, as to the navigation of a system; it also proves as an insight into the hyperspace, yet
fails to give the user an insight into the cognitive issues affecting the navigation. (Booch,
1999, Eva, 1992, Rossi, 1998)
The following stages of the logical design include the formulation of the �processing model�
(Eva, 1992, p.60). These have figures representing the input/output structures and the entity
descriptions. Both give some indication as to how the data moves throughout the system but
never gives any mention of human navigation.
30
The physical design is available to encourage the development of a �Function Component
Implementation Map� (Eva, 1992, p.63). It is primarily concerned with achieving the
outcome of the functional requirements. It is not concerned with any non-functional
requirements, which would include the accessibility associated with navigation of the system.
(Eva, 1992, Rossi, 1998)
Traditional methodologies tend not to incorporate hypermedia design into any of their models
(Enguix, 1999). This is clear through the investigation of SSADM, it concentrates on the flow
of data and the technical design of the functions. It would not be possible to gain a useful
navigation design, using this methodology.
3.2.6 Security
Although traditional systems need to have effective security to prevent their own hackers,
traditional methodologies do not have much focus on how to effectively incorporate security.
It is usually a very important aspect for the problem owner, and therefore cannot be
overlooked. For web applications it is very important and bad security will loose the owner,
users and customers. (Conallen, 1999)
It was possible to investigate into the security features of SSADM, yet this was not a large
process as there is no mention of the security options within the methodology. Studying the
manual, and searching the web achieved this conclusion. Much of the systems developed
using SSADM achieved their security through other means, such as specialist knowledge by
consultancies. (SSADM manual, 1990)
3.2.7 Development Cycles
Traditional methodologies have developed the use of development cycles over time. In the
fourth version of SSADM this has been achieved very well. SSADM uses a framework made
up of seven stages, mentioned in section 2.4.2, which splits the work to be accomplished.
These stages are spread amongst five modules, these have their own �plans, timescales,
controls and monitoring procedures� (Avison et al, 1995). The development cycles are the
basis for engineering principles. They need to undertaken to be able to effectively develop an
effective system.
The stages within SSADM define the outputs expected. Any system whether it is traditional,
or web-based needs to have the guidelines to achieve successful development. The principles
that SSADM basis itself on would provide any system with effective project management
31
skills. It is this type of discipline needed to support efficient development. (Avison et al,
1995, Eva, 1992)
32
3.3 ETHICS
3.3.1 Mention of the Web
The ETHICS methodology is used to a lesser extend than SSADM, and is not known so well
as SSAM. The idea of the methodology is based around the management of change. This
surely means that a changing organisation must make use of the Internet and the World Wide
Web in order to keep some sort of edge over the competition.
The process used to investigate the use of the ETHICS methodology, was via the web, but
primarily using the official text by Enid Mumford. The text takes the view that developers
need to be pointed in the direction; of a socio-organisational system that is aiming to change
the way the organisation operates. Web systems are not always developed to change the way
an organisation functions, but rather possibly to enter a market, and to enable users to do
something they never have before. This could include downloading music or other forms of
media. ETHICS does not enable this to be done, there is no mention of the web or the
Internet, and particularly not enough mention of the technical aspects needed to accomplish
its intentions. It claims to help the �introduction of systems incorporating new technology�
(Mumford, 1995, p.50), yet there is no mention of any of the technologies it proposes. This
may be because of the speed of changing technology, but at the time of publication the web
was up and coming, therefore computing professionals should have been aware of the latest
technologies. (Mumford, 1995)
3.3.2 User Interfaces
ETHICS takes great pride over the involvement of users in the development process. They
must have a great influence over the interface to be used within the system. It is possible to
make use of the thorough requirements achieved through the diagnosing needs stage. The
differing �fits� proposed in the methodology allow the development team to determine what is
needed within the system, in terms of knowledge, psychology, and efficiency (Mumford,
1995). These areas, especially psychology have a major effect on the way a user uses the
interface, how they view different colours, shapes etc.
Ultimately it will be the users who determine how the interface should be designed. ETHICS
does not help with the proclamation that artistic specialists aid in the design of the interface. It
seems that the users and a specialist development team would be capable in building the
system. This is not the case with web-based systems; firstly they need a detailed design plan,
taking into account the needs of the users, with the help of the users. Yet it is clear that users
cannot always develop what they require on their own or with the help of computing
specialists. ETHICS although capable of achieving excellent user requirements, does allow
33
the development team to outsource areas of development to others. Neither does it specify the
need to have a highly user-friendly interface. (Mumford, 1995, Avison, 1995)
3.3.3 Unknown Users
ETHICS is based around user participation; it would not be possible to implement this
methodology without the help of the potential users. Throughout any report on the use of
ETHICS there is constant mention of users and the role they have played in the systems
development. This could include user design, or focus groups based on discussing the range
of ideas possible for the new system. Web systems tend to use a lot of user participation when
they know who the users are. (Mumford, 1995)
3.3.4 Multimedia
As with the lack of user interface guidelines, it is also appears short on any information
regarding multimedia. The technical areas suggested are very light, giving no advice on the
alternatives possible. The only mention of technical alternatives states �they will not form any
part of the design procedures� (Mumford, 1995, p.46).
3.3.5 Design
ETHICS is based around the notion of a �socio-technical design� (Mumford, 1995, p.46). The
methodology gets the designer to specify the human objectives i.e. those which would
improve job satisfaction and the quality of working life, to the efficiency objectives, that
would improve business efficiency. Within the approach there is reference to technical
options that should be specified, but there is no mention of any modelling techniques used,
therefore how should the user design their system. (Mumford, 1995)
Systems cannot be designed on the basis of human and business objectives. ETHICS gives no
advice on how to choose the technical aspects of the system. There is no mention of this
within Mumford�s texts, and no information within any of the case studies suggesting how
this stage was completed. There is certainly no discussion on the use of any navigational aid,
or on how the system should be accessed.
The ETHICS methodology should, as mentioned in Avison et al, 1995, talk of the hardware
and software specification. It has to be analysed, as this does not appear in any other material
on the methodology. It would be a very difficult task to use ETHICS as an aid for the design
of a web-based system. It poses the question, should a more technically oriented design group
undertake the technical design? These findings show the answer to be yes removing the
34
importance of the methodology on the project and putting it on a number of different design
specialists. (Mumford, 1995, Avison et al, 1995)
3.3.6 Security
As with much of the specification for the hardware and software of the system, there is no
discussion on the security measures of the system. The ETHICS methodology is for the
change management of an organisation, very little specifies that this change has solely to
occur through the use of any form of IT. (Mumford, 1995) Therefore it is probable that
finding it useful for the security measures of a web system is very unlikely.
3.3.7 Development Cycles
The discussion on development cycles does not take into account the lack of information on
technical aspects. This is not the concern of good project management skills and therefore is
not involved in the discussion.
ETHICS provides some detailed analysis of the stages of a project. Traditional methodologies
are presumed to have these stages as noted in section 3.2.7. Differently to SSADM this is not
so noticeable in the ETHICS methodology, but there are steps on the development of
requirements analysis and a design. Avison and Fitzgerald point these out in their text,
depicting the design stage of the methodology to contain fifteen different steps. It was
difficult to determine these from the research carried out. This was due to the text in which
the methodology is described. It is vague and seems to have very little concern for the system,
which changes the organisation. (Avison et al, 1995, Mumford, 1995)
35
3.4 Summary
SSADM ETHICS
Is there any mention of the use of
the web as a support tool or an
alternative to the server currently
being used?
No
No
Is there a specified approach to
developing effective user
interfaces?
No
No
Within the requirements gathering
section does the methodology
make allowances for unknown
users?
No
No
Is their specification on the use of
multimedia?
No No
Does the design of the system
include all necessary alterations in
order to make web system design?
Partially, there is the use
of dialogue design. See
section 3.2.5
No
Does the methodology provide
information on how to make a
system secure from hackers?
No
No
Does the methodology provide
adequate development cycles? Are
there separate sections for
requirements, design,
implementation, and testing?
Yes
Yes, but not for testing or
implementation
Both the traditional methodologies performed poorly against the evaluation criteria. Neither
contained any mention of the Internet or the use of the World Wide Web to improve system
performance or ability. There was only mention of the use of database systems, on a closed
network within a single organisation. ETHICS did not even go as far as to mention the use of
a database, but rather concentrate on the organisational context in which the system was being
developed.
36
If a development team were to use either of these methodologies to try and build a user
interface for their system they would have to use additional resources, such as consultants.
SSADM pursues the notion of some type of screen shot developed using the logical
requirements of the system. It also assumes that the development team would have the
necessary skills to develop every aspect of the system. Web systems would need someone
effective in marketing, presumably being an artist or a graphics specialist. ETHICS although
not mentioning the interface directly, views it as a user design issue. This would fail unless
accepted by all users, based on the extra efficiency it would add to the organisation.
They is also no mention of the possibility that the users may be unknown, or unable to be
used in the development. Both rely heavily on user participation for a successful system to be
developed.
There is no mention of multimedia, or the possibility of the use of multimedia within a
system. The majority of web-based systems use some form of multimedia to attract users or
portray something in an exciting way.
SSADM does include some aids to ensure a workable design for web application. There is use
of dialogue designs, which go some way to modelling the navigation of the system. Although
it makes no mention of the hypermedia of the system and the way it should be arranged.
ETHICS proved to have poor guidelines on the design of a system with no mention of
navigation or hypermedia.
Neither of the methodologies provides the guidance needed to provide security for a web-
based system.
Both the methodologies do have well defined software engineering principles for the
requirements and design stages, suitable for any system development project. SSADM
provides information on the implementation side but vaguely brushes over the testing.
ETHIC does not include guidelines on the implementation and testing stages.
Both the methodologies would not be sufficient to aid in the development of web application
development. They do not cover some of the major aspects and fail to ensure efficient
modelling of any of the evaluation criteria. Yet their software engineering approach would
help structure a web project and seek to ensure their project management is sound to succeed
where many projects fail.
37
4.0 Evaluation of the Web-Based Systems Development Methodologies
4.1 Evaluation Criteria
Web-based methodologies are relatively new, only appearing in the mid-nineties. They were
developed to bridge the gap that had developed between traditional systems development
methodologies and web-based systems. According to the creators of these new
methodologies, traditional methodologies do not provide the means necessary to develop a
web-based system. �The cultures of the two types of system differ in terms of process, skills,
and culture. These differences can often be a major stumbling block on Web projects as these
cultures clash� (Rational Corporation, 2000, p.1-2). It is therefore necessary to analyse two
other methodologies specially for the purpose of building web applications. The criteria will
be slightly different, but to ensure a fair comparable test most of the criteria will be the same.
Following is the criteria for the evaluation of the web-based methodologies:
• Is there a specified approach for the development of user interfaces? Does it give
advice on the use of specialists to help with the design? Any methodology that fails
to include guidelines on the design of the interface, will fail the user, not fully aiding
in their project.
• Is there an understanding that not all projects have access to their users, and that
user participation is not always possible? Users are not always available to help in
the development of a project. This is especially true of websites where users are not
part of the developing organisation.
• Are there guidelines on the use of multimedia? The majority of web-based systems
contain some sort of multimedia. There should be some guidelines on its use.
• Are the design stages useful i.e. does it include navigation design as well as the more
traditional functional design? Navigation design is an area particularly identifiable
with web system design. It is particularly necessary to ensure a successful design.
• What software does it advise the use of, if any? Web systems tend to use web
browsers for users to navigate through the system. A web methodology should
advise developers regarding browsers, or at least ensure they know that their system
may appear different in the various browsers.
• Does the methodology include relevant guidelines on the security issues involving
web-based systems? This is a vitally important issue today; to ignore it would prove
fatal for the developer.
38
• Does the methodology provide adequate development cycles? This would ensure
good project management. It is known that many projects fail, through bad project
management.
4.2 RUP
4.2.1 User Interfaces
The RUP process uses a philosophy that aims to ensure �creative design process is integrated
with the overall software development process� (Rational Corporation, 2000, p.1). The
�creative design process� is primarily focusing on the user interfaces of the system. The
methodology starts out by inviting the developer to write a �Creative Design Brief�(Rational
Corporation, 2000, p.3). This forces them to think about how the user interfaces will look,
react, and interact with the potential users. There is also the chance to develop the initial �user
interface guidelines� (Rational Corporation, 2000, p.3).
The process undertaken through the use of this methodology is firstly to create a �Creative
Design Comp� (Rational Corporation, 2000, p. 5). The idea behind this is to give the
stakeholder a number of options on how the interface should look. The �Creative Design
Comps� then evolve into the �User Interface Prototype� (Rational Corporation, 2000, p.6),
these are the basis for a full interface design, and traditionally only tend to support the most
important areas of the design.
The UML (Universal Modelling Language) (Booch et al, 1999) provides a model for various
team members involved in the project. This is known as �the model� (Conallen, 1999, p.85)
and emphasises the importance of communication between various team members. It also
looks at how each member contributes to the development and how they each may have
different specialities. With this in mind the user then distributes the work for the development
of the user interface using varying specialists. (Conallen, 1999)
The RUP provides the developer with a thorough process of interface development. It
provides guidelines and stages with detailed explanations, showing what is to be delivered,
and how to carry these out. It also provides alongside the UML, a way to distribute work
effectively. (Conallen, 1999, Rational Corporation, 2000)
39
4.2.2 Unknown Users
The RUP does not explicitly explain how to develop a system without user participation.
Rather it relies heavily on the input of stakeholders. They are not necessarily users, but
problem owners, business executives, or anyone with an interest in the system.
Stakeholders of the system are responsible for making the majority of the decisions for the
development of the system. The development will give them the options available to them and
ask them to choose the one they prefer. For example as shown above in section 4.2.1 the
design team creates the �Creative Design Comps�, then they are presented to the stakeholders,
who decide on the course of action to take and which �Design Comp� to follow.
Although users are mentioned in various places of development, the methodology shows that
it is possible for the system to be developed without their involvement.
4.2.3 Multimedia
Where the RUP fails, is to give an understanding of the use of multimedia elements within a
web application. There is no mention of the inclusion of any multimedia elements, such as
video, audio, or animation. The extended UML models do not show the use of multimedia in
the sense that it is not modelled or distinguished from any regular hypermedia characteristics.
(Conallen, 1999, Rational Corporation, 2000)
4.2.4 Design
The RUP contains various types of design using the object-oriented approach of class
diagrams, plus the specific web designs showing the navigation of the system. The class
diagram shows the, �sets of classes, interfaces, and collaborations and their relationships;
class diagrams address the static design view of a system� (Booch et al, 1999). They provide
web application developers with the understanding of how progress is made from the analysis
stage developing �actors� in the RUP �use-case diagrams�, to a design where the use case is
realised and the relationships between use-cases identified.
Navigational design is regarded as one of the most important aspects of web application
development. The UML interaction diagram, containing the sequence diagram and the
collaboration diagram, which shows in as much detail as necessary the way a process moves
through the system. The newly developed �navigation map� shows how a user will interact
with the system. It shows every possible eventuality, a separate diagram is drawn for each
possible type of user. The navigation map is developed at an early stage of development
before the interface is designed, this way there is valuable communication early on in the
40
project between the stakeholders and the development team. (Booch, 1999, Conallen, 1999,
Rational Corporation, 2000)
4.2.5 Software
The software advice within the RUP as well as UML is very vague for the purpose of a web-
based application. Although there is in depth processes on implementation, these lack any
guide to using a web browser. The information they do give, it is hard to assume that this
would operate on a web browser.
The information provided by the RUP does give some valuable knowledge to the
development team on other software for the development of web-based systems. These
include middleware e.g. CORBA and Java Applets, to �provide platform-independent
graphical user interfaces� (Booch et al, 1999, p.240). For the purpose of this project it is not
necessary to go any further into a discussion on the use of varying Internet technologies,
rather to leave it as an overview on software use.
4.2.6 Security
The RUP introduces the notion of security by showing that users reject many systems because
they are concerned about the level of security technology being used. Then they analyse the
varying Internet security currently available, including firewalls and differing encryption
standards.
Developers would achieve user confidence by following the advice given by the RUP. It
would not be possible to gain this confidence without any security technologies in use.
(Conallen, 1999)
4.2.7 Development Cycles
RUP uses a well-documented iterative process. This means that the work to complete the
project is split up into �mini-projects�, known as �iterations� (Booch et al, 1999, p.7). Each
iteration is a step covering all the workflows, but just one phase. The workflows are the stages
in development that make up any development process, i.e. �requirements, analysis, design,
implementation and testing� (Booch et al, 1999, p.11). Phases are �the span of time between
two major milestones of a development process� (Booch et al, 1999, p.447).
The areas not covered by the RUP include areas such as �project planning, resource planning,
risk mitigation, and quality control� (Booch et al, 1999, p.13). Focusing just on the workflows
41
does not enable effective joins between them; this contributes to an efficient process. (Booch
et al, 1999)
Much of the information gathered on the RUP was done so through various texts on the
subject, plus personnel knowledge regarding the use of the methodology. The texts covered
have included the official texts by the Rational Corporation, and the use of the online RUP
resources. It has not been possible to implement the RUP for the purpose of this project, but
the use of the framework for previous coursework�s have improved the information available,
on the RUP in practice.
42
4.3 OOHDM
4.3.1 User Interfaces
OOHDM use what they call an �Abstract Interface Design� (Rossi et al, 1998, p.15) to
develop the user interface from the navigation design. This is developed using an �Abstract
Data View design approach� (Rossi et al, 1998, p.16) that comprise of objects representing
the state and the interface. They have a set of attributes that define what it does i.e. the result
of a mouse click, or a double mouse click. An �Abstract Data View� (ADV) also allows the
definition of the interface appearance in terms of objects such as menu bars and buttons that
directly interact with the user.
The ADV shows the interaction between various aspects of the interfaces and can be directly
implemented into an interface. What this means is they show how the interface reacts to
external events and how they influence navigation.
The methodology specifically advises the development team to include graphic design
specialists. It therefore assumes that the graphics specialist will define the appearance of the
interface. (Rossi et al, 1998)
4.3.2 Unknown Users
The development stages within OOHDM have proven not to give any evidence of aiding the
developer, with user participation. It does not distinguish any of the information gathered
through the questioning of users. Therefore it must be assumed possible, to be able to develop
a system using the methodology without aid from users.
This is fairly applicable for the design of a web-based system. It is not clear whether this is
purposely done, as the methodology creators have given no indication of this fact. This is
most definitely caused by the missing process of requirements gathering. (Rossi et al, 1999)
4.3.3 Multimedia
Although much of what is discussed within OOHDM is regarding the use of object-oriented
objects it points out that there is use of multimedia elements within web systems. It
acknowledges the use of multimedia in the interface design by modelling it accordingly.
This is done within the real interface objects, whose purpose it is to show �the way in which
multimedia objects will be synchronised� (Rossi et al, 1999, p.244).
43
4.3.4 Design
The design stages of the methodology are very well developed and provide excellent models
for the implementation to be derived from. Firstly the conceptual model is developed. It is
similar to the class diagram used in UML, which is built upon �classes, relationships, and
sub-systems� (Rossi et al, 1998, p.5). The conceptual model acts as a basis for the
navigational design as the conceptual model does not reflect the fact that the application will
be implemented on the WWW.
The navigation model therefore represents the view over the conceptual model. As with the
RUP it demonstrates how the user will navigate their way throughout the system. The
development team should produce a different model for each user profile. An example of this
is for a university website that has one view for the students, but another for the lecturers.
(Rossi et al, 1999)
The third stage in design is the �Abstract Interface Design� as mention in sectioned 4.2.1.
4.3.5 Software
The application of software is not something discussed in any detail within the methodology
specification. It does though make reference of the use of a web browser to view the
interfaces and navigate through the system. (Rossi et al, 1998, Rossi et al, 1999, Lowe, 1999)
4.3.6 Security
The process by which OOHDM implements a system does not mention technology. There is
no evidence of security technologies in any of the documentation studied for this project.
(Rossi et al, 1998, Rossi et al, 1999, Lowe, 1999)
4.3.7 Development Cycles
The first point to make is that OOHDM does not include information regarding requirements
analysis. It assumes this is already carried out by members of the organisation, and does not
regard it as a task to be undertaken by computing specialists.
The design stage as discussed in section 4.3.4 is very well developed and contains three
separate sections. The final section is focused on the implementation of the design. It involves
the �mapping of design objects onto the particular runtime environment being targeted�
(Rossi et al, 1998, p.18).
44
There is no mention of a section on testing, but the sections up until this point do ensure that
the application maintainability of the application is improved. (Rossi et al, 1998, Rossi et
al, 1999, Lowe, 1999)
45
4.4 Summary
RUP OOHDM
Is there a specified
approach for the
development of user
interfaces? Does it give
advice on the use of
specialists to help with the
design?
Yes, specific design stages
regarding interfaces.
Yes, specific design stages
regarding interfaces.
Is there an understanding
that not all projects have
access to their users, and
that user participation is
not always possible?
No, makes use of
stakeholders, which would
include users
No mention of users
Are there guidelines on the
use of multimedia?
No
No
Are the design stages
useful i.e. does it include
navigation design as well
as the more traditional
functional design?
Yes
Yes
What software does it
advise the use of, if any?
Varying Internet
technologies
None specified
Does the methodology
include relevant guidelines
on the security issues
involving web-based
systems?
Yes information regarding
firewalls, encryption, etc.
No
Does the methodology
provide adequate
development cycles?
Yes
Yes, but not including
requirements or testing.
46
Both methodologies performed adequately against the criteria. The RUP came out on top but
the older OOHDM proved to be more in depth in some of the categories. Both included a
detailed approach to developing a user interface, although neither really explicitly ensured the
possibility of graphics or other specialists involvement.
The RUP specifically ensured effective use of stakeholders. It is unclear whether they did this
assuming that it may not be possible to gain help from users. OOHDM does not mention
anything regarding users or stakeholders, which leads to question where do the requirements
come from, and who do you ask questions, regarding the design?
Neither includes guidelines on the use of multimedia. The RUP does not make any reference
of multimedia. OOHDM includes it within some of the models, but does not include any
advice on its use.
Both methodologies ensure that the development team has a very detailed design. Particular
emphasis is paid to separating navigational design from other design issues. The RUP uses its
�navigational maps� (Rational Corporation, 2000), while OOHDM uses a �navigational
structure� (Rossi et al, 1998).
Software advice is very thin in both methodologies. There is no information regarding web
browsers that is of any use, and only in the RUP does it mention software in any detail.
The RUP gives strong advice on the use of security for a web-based system. It includes
guidelines on the use of firewalls, as well as other security technologies. OOHDM gives an
indication of the use of security in web applications, but does not develop this further.
The best aspect of using the RUP is its use of development cycles and excellent software
engineering principles. It is much better than OOHDM, which misses out vital areas primarily
testing. The development team does not undertake requirements analysis it assumes the users
do, their role is only to ensure effective requirements have been gathered.
47
5.0 Conclusion and Findings
5.1 Comparison of the Methodologies
In this paper there has been an emphasis to try and go beyond what has been learnt already. It
is necessary to develop a new breed of methodologies solely for the purpose of developing
web methodologies. The objectives in section 1.2 states that it is necessary to understand one
of these methodologies, determine whether they are useful and comment on them in
comparison with traditional methodologies.
Both the traditional methodologies used proved the assumption made in section 1.1, that these
were not suitable for the purpose of web development. Firstly as the criteria has proven they
were not developed for this purpose. There is no mention of the Internet as a basis for
development; this is especially true of SSADM version 4 that was released in 1990 (Eva,
1992), before the Internet boom took off.
The ETHICS methodology does not include a specific stage for interface development,
focusing on the effects the system would have on the organisation. At some extent SSADM
does help with interface design, there are its �dialogue designs (also an aid in navigational
design) and screen shots� (Eva, 1992), which enable an initial interface to be planned, yet not
to the stage of readiness for a web-based system. In comparison both web methodologies
proved very compliant on interface design. The RUP proved better making use of
stakeholders, but both provide detailed designs of each interface within the system.
While user participation is a very important aspect of system development, none of the
methodologies made specific reference to the development of a system where the users are
unknown. Both the traditional methodologies rely heavily on user participation. Although this
is not a fault and is very relevant to the development of a traditional system, it does not fulfil
the requirements of every eventuality, for web-based development. The web-based
methodologies also have the same weakness, neither the RUP nor OOHDM provide any
guidelines to deal with this possibility.
As mentioned in section 2.1.4 multimedia occurs within most web systems. None of the
methodologies give any guide to how multimedia should be used and modelled for web
applications. The only methodology to give a hint of its use was OOHDM but this is limited
to how it should be modelled.
The design is a very important area of web development, therefore it is essential that a useful
methodology provide the user with an in depth guide. The navigation design, which is singled
48
out in many papers as the most important design phase for web development, did not appear
in either of the traditional methodologies. SSDAM uses �dialogue designs� to ensure there is
an understanding of the movement of data, as initiated by the user, but no understanding as
how the users would navigate their way around the system. ETHICS does give any help on
the navigational design of the systems mechanisms. Both the web methodologies have major
stages on navigational design, splitting it from other design stages to ensure it is completed
effectively. Thus the users should be able to find the information they are looking for a lot
easier.
The software criteria was not used on the traditional methodologies, as it is assumed that they
would ensure the design of a specialist browser, with no information on the specifics of
choosing software already on the market. Neither of the web methodologies proved to give
suitable guidance on browsers or the varying Internet technologies.
Both SSADM and ETHICS make no reference to controlling information through the use of
security. OOHDM being specifically for web-based systems is expected to contain this, but
has nothing. The RUP is the only methodology to explain the various types of security
technologies possibly used in web applications.
Both the traditional methodologies appear to have good software engineering practices,
splitting the development process up into stages. The RUP is the best out of the
methodologies with detailed workflows made up of different phases, with iterative processes
to ensure better development. Following is a table summarising the development stage in each
methodology:
SSADM ETHICS RUP OOHDM
Requirements ! ! !
Design ! ! ! !
Implementation ! ! !
Testing !
This proves that three out of the four methodologies are floored. The RUP with its extensive
software engineering framework proves to be the most suitable methodology out of the four
investigated.
49
5.2 Are the Traditional Methodologies useful for Web-Based Development?
At the start of the report the assumption is made that these methodologies would not be
useful. This to some extent is true; in section 5.1 the comparison shows some fatal flows these
methodologies have at dealing with some of the vital aspects of web development.
These include navigational design, interface design, the prospect of unknown users, and
multimedia use. It could be pointed out that they were not intended for web development but
provide web developers with the planning and project management to ensure a successful
system. Yet this is not true either as the software engineering standards in the RUP
methodology are more efficient and complete.
In some areas the traditional methodologies performed just as well as the web-based
methodologies. These were primarily those characteristics similar in both types of system.
They are useful �for inter organisational perspectives� (Eriksen, 2000, p.482), but they are
not suitable to build systems with an external audience in mind, for which they do not provide
proper guidance.
5.3 Are the Web-Based Methodologies useful for Web-Based Development?
It was sensible to assume that these methodologies would perform better against the
evaluation criteria. It is true that the methodologies did perform well in comparison to the
traditional methodologies, but not as badly as was hypothesised.
The design stage of both provides proper guidance, but neither includes guidance on obvious
areas associated with web systems such as multimedia. OOHDM misses out vital areas
identified to be important for web development. Security is not covered at all, systems with
no security would get no users, or users that a very disappointed. There is no mention of
software to use in support of the system (web browsers, middleware etc.) and stages not
included in the development cycle.
The RUP is the most suitable out of the four methodologies; it includes areas associated with
traditional software development and web development. Although it misses out a vital area on
multimedia it provides the development team with the good parts of a traditional software
engineering approach, as well as guidance on the development of a web-based system.
50
6.0 Project Evaluation
6.1 Criteria for Evaluation
• Did the solution of the project achieve the necessary objectives?
• Did the evaluation gain the results expected?
• What were the strengths of the evaluation?
• What were the weaknesses of the evaluation?
• What could have been improved on within the solution?
6.2 Evaluation of the Solution
The project did achieve the objectives outlined in section 1.2. It is necessary for this to be
evaluated, as this is the basis for gathering the information required to come to a solution.
Several methodologies were studied in section 2.4 of the project, and what is meant by web-
based was explained in section 2.1. Both the extension of the RUP, but especially OOHDM
are methodologies specifically for the development of web applications, these were studied
throughout the project. The characteristics of a web-bases system were identified, as was a
criterion for evaluating methodologies. The comparison was completed in section 5.1.
The results gained by were partly expected, initial research had pointed out that neither the
traditional nor the web methodologies would be useful. As expected the traditional
methodologies were not useful, the evaluation criteria proved this to be true. The web
methodologies though proved otherwise to the hypothesis, they performed a lot better than
expected. It proved they were not just a mixture of �ad-hoc approaches� as described in
section 1.1.
The evaluation criteria were supposed to cover a wide range of characteristics, this ensured
that there was an accurate portrayal of most of what creates a well-developed web-based
system. It revealed whether each methodology cover all the aspects of web development
rather that just the technical or the management sides. It would have an inconclusive
investigation had the criteria been weak and only covered a small amount of the
characteristics. Another strength is that it threw up unexpected results that were not
hypothesised. It proved some of the research previously undertaken was not totally accurate.
This may be because time has past and methodologies have changed, most of the research
previously embarked on was done so in the late nineties. The RUP extension was only
developed in 2000, confirming some of the material to already be out of date.
51
If the project covered a wide area it is also possible that it could have been too thin in some
areas. If time was permissible certainly the area of design could have in much more depth,
giving better results on the methodologies suitability. It is certainly possible there could have
been different results achieved from a very depth focus on each of these areas, especially
those that are technical. Although an in depth technical study on Internet technologies would
have taken too long for this type of project.
Not having implemented any of the methodologies could have also have an affected on the
conclusion. Although it was not necessary to find the usefulness of these methodologies, it
may have discovered certain areas of the methodology that may not have come to light using
this method. To accomplish an extremely reliable conclusion, it would have been viable to
develop a design model, and try out an interface prototype.
If time permitted an implementation would have been carried out to prove the results to be
true and create a better understanding of the specifics in relation to areas of the criteria.
6.3 Evaluation Summary
• Objectives achieved
• Results not expected
• Criteria covered a wide range of characteristics
• Not enough details in design and interface sections
• Implementation could have improved results.
52
References
Ambler, Scott, (2000), User Interface Design: Tip and Techniques, URL:
http://www.ambysoft.com/userInterfaceDesign.pdf [March 30 2002].
Avison, D.E. & Fitzgerald, G (1995), Information Systems Development: Methodologies,
Techniques and Tools, 2nd edition, McGraw-Hill.
Barry, Chris & Lang, Michael (1999), Techniques and Methodologies for Multimedia Systems
Development, URL: http://www.is.nuigalway.ie/mlang/research/IFIP_WG82_2001.pdf
[13 February 2002]
Bieber, M & Isakowitz, T & Vitali, F (1998), Web Inormation Systems, Communications of
the ACM, 41(7): pp 78- 80
Booch, G & Jacobson, I & Rumbauch, J (1999), The Unified Software Development
Process, Addison-Wesley.
Clemmensen, Torkil & Holck, Jesper (2001), What Makes Web-Development Different?,
URL: http://www.cbs.dk/staff/holck/iris.pdf [25 April 2002]
Conger Sue (1998), What�s so Different about the World Wide Web Anyway, URL:
http://delivery.acm.org/10.1145/360000/353116/p415-
bieber.pdf?key1=353116&key2=2800710201&coll=GUIDE&dl=GUIDE&CFID=239896
2&CFTOKEN=43590050 [March 15 2002].
Conallen, Jim (1999), Building Web Applications with UML, Addison-Wesley.
Davis, Joseph G. & Enguix, Carlos F. (1999), Filling the Gap: New Models for Systematic
Page-based Web Application Development and Maintenance, URL:
http://budhi.uow.edu.au/web-engineering99/accepted_papers/enguix.pdf [January 2002].
Eriksen, Lars (2000), Limitations and Opportunities of System development Methods in Web
Information System Design, In Richard Baskerville et al (eds) Organisational and Social
Perspectives on IT: IFIP TC8 WG8.2 International Working Conference on the Social
and Organisational Perspectives on research and Practice in IT, Aalborg, Denmark,
pp.474-486.
53
Eva, Malcolm (1992), SSADM Version 4: A User�s Guide, McGraw-Hill.
Hall, Wendy & Lowe, David (1999), Hypermedia and the Web: An Engineering
Approach, Wiley.
Hares, John S. (1994), SSADM - Version 4, Wiley.
Harriot-Watt University (1994), URL: www.cee.hw.ac.uk/ism/ug1/ssadm.htm [April 3
2002].
Konecny, James & Ruppel, Cynthia (2000) The Role of IS Personnel in Web-based Systems
development, URL: http://www.acm.org/sigcpr/program.html [January 2002].
Longworth, G (1992), Users Guide to SSADM Version 4, NCL Blackwell.
Lyardet, F & Rossi, G & Schwabe, D (1999), Web Application Models Are More than
Conceptual Models, in: Advances in Conceptual Modelling: Lecture Notes in Computer
Science 1727, pp.239-252, Springer Verlag.
Mumford, Enid (1995), Effective Systems Design and Requirements Analysis � The
ETHICS Approach, Macmillan.
Rational Corporation (2000), Building Web Solutions with the Rational Unified Process,
URL: http://www.rational.com/products/whitepapers/101057.jsp [20 April 2002].
Rossi, G & Schwabe, D (1998), An Object oriented Approach to Web-Based Application
Design, Theory and Practice of Object Systems, 4(4)
(1990), SSADM Reference manual: version 4, NCC Blackwell.
University of Aberdeen (2001), Lecture on Information Systems, URL:
www.csd.abdn.ac.uk/~jmackint/teaching/derekslectures/internet_lecture_cs1011.ppt
[February 2002]
Whyte, W.S., (2001), Enabling eBusiness, Wiley.
54
Appendix A: Reflection on the Project Experience
At the beginning of the project I had little knowledge on the development of web-based
applications, and the tools used to do this. I aimed to understand how web systems were to be
developed and the various ways possible to do this. I was sure that traditional methodologies
were not suitable, but I wanted to prove this and gather material on the methodologies that
were supposed for web development.
During the first semester I was still unsure of how to go about doing this. The background
research carried was of a wide variety and very vague. I was aware that I wanted to determine
the use of these methodologies but still unsure how to do so. I knew I did not want to go
through an implementation of the methodologies as I did not have time, but what were the
alternatives?
It was at the start of the second semester that I thought of deriving the evaluation criteria to
decide on the value of each of the methodologies. Next I had to decide what to include in the
criteria and what not too. Web development covers a very wide area and it was never going to
be possible to cover all of it. I ended up concentrating on characteristics of systems that were
not too technical, but still enable an insight into these possibilities.
I would advise anyone undertaking this type of research project to organise his or her
reference material in an efficient way. It takes a lot of time reading through various papers
and research, many of them on the web, therefore it is necessary to keep accurate records of
them all.
I would also advise anyone to start early on this type of project. Although there is no technical
element to it, the work still has to be proven and the research is very important compared to
those with a technical solution.
My project would have benefited from a clear approach being determined in the first
semester. Unfortunately my criteria was not developed until semester two therefore I had to
the majority of the investigation in the second semester when there was a lot of other work to
do.
55
