information systems development methodologies in...
TRANSCRIPT
Information Systems Development Methodologies in the Age of Digital Economy
Dimitrios Papatsoutsos
University of Athens
Department of Informatics
University Campus, TYPA Buildings, 15771
Tel: +3017275217
Fax: +3017275214
Number of Words: 6233
Keywords: IS development, IS development methodologies
Information Systems Development Methodologies in the Age of Digital Economy
00 AAbbssttrraacctt
The recent evolution of Information and Communication Technologies (ICT) resulted to new forms
of economic activity included in the general term “Digital Economy”. Changes are affecting both
organizations that use Information Systems and organizations that develop them. In this new
economic environment, Information Systems development methodologies play a significant role,
but they are called to accomplish new requirements. The research presented in this paper, aims to
define and present the role that the Information Systems development methodologies can play in
this new era and the new shape they should probably get in order to play this role.
11 IInnttrroodduuccttiioonn
One of the most well known notions in the area of Information Systems Development is
“methodology”. The notion of “methodology” was very vigorous during the 70s and until the end of
the 80s. During all this period, a large volume of research work was done, which was mainly
focused on the debate between two opposite schools: the school of the “hard” approach and the
school of the “soft” approach to Information Systems Development.
During the same period, governments and large organizations were demanding specific
methodologies as prerequisites in order to contract large IT projects (e.g. SSADM by the UK
government or IDEF by the US DoD). These methodologies were of the “hard” approach and their
adoption was one of the main reasons that methodologies were so vigorous during that same period.
The Information Systems applications developed during that period were exhaustively examined
and, in many cases, the use of Information Systems development methodologies (particularly those
based on the “hard” approach) was combined with serious failures, which means systems that never
worked or worked after long delays or worked with much lower performance than their design
prefigured and their users expected.
Since the end of the 80s, the criticism against the use of methodologies has been very intensive,
while the study of the “methodology” concept has been reduced during the 90s. The bibliographical
citations have been less frequent and the use of the term “methodology” lost its generic meaning and
was mainly oriented to more specific categories and characteristics of the software development
process.
One possible reason for this recent aversion of the Information Systems academy to the formalized
ISDMs was mainly the series of cases where the use of a methodology resulted to failed (or at least
defective) Information Systems. One other reason was the shift of the needs and requirements of the
organizations, mainly due to the application of new technologies like Internet and the changes that
these new technologies have brought to the structure and the operation of companies and
organizations.
The above stand only for the academy of Information Systems. Referring to the community of the
practitioners, the reality was usually different. Even during the period that the formalized
methodologies almost axiomatically dominated in the academy, the practitioners (when they were
not forced by external factors to use specific methodologies) were less bound to the strict phases
and steps and used the methodologies more as a project management tool than a scientifically
documented guide of thinking.
22 LLiitteerraattuurree RReevviieeww
A research attempt in the area of Information Systems must be based, at first, on some selected,
fundamental readings. These can be books, collections of conceptual papers or even some
outstanding papers in the discipline.
First of all, a method is required for the research project and a good reading on this is “Project
Research in Information Systems – A student’s guide” by Tony Cornford and Steve Smithson. This
book introduces the discipline to the researcher and proposes a comprehensive guide for the study
and the research in terms of a scholarly project.
Then, an introduction to the basic concepts of Information Systems development is needed. A good
introductory reading is the book “Information Systems Development: Methodologies, Techniques
and Tools” by D.E. Avison and G. Fitzgerald and, in the same way, Donal J. Flynn’s “Information
Systems Requirements: Determination and Analysis”. As a second step, an in-depth examination
and a taxonomy of the conceptual notions on which Information System’s development
methodologies are based, is given in “Information Systems Development and Data Modeling –
Conceptual and Philosophical Foundations” by Rudy Hirschheim, Heinz K. Klein and Kalle
Lyytinen.
In order to study Information Systems in organizations and businesses, it is very useful to study
some aspects of organizations theory and business management, especially for a researcher that
comes from the scientific/engineering school of thought. A good introduction to this area is
“Organization Theory” which is a selection of readings, edited by Derek S. Pugh.
The dichotomy between “hard” and “soft” approaches to Information Systems development has
been a main point of discussion in the discipline for the past two decades. A good way to get
familiar to these two approaches is to study fundamental readings of the two schools:
!"Two of the most representing methodologies of the hard approach, are the British SSADM
(Structured Systems Analysis and Design Method), described in “SSADM Version4: A user’s
guide, Second Edition” by Malcolm Eva and the United States DoD’s IDEF (Integration
DEFinition) family of methods, analytically described in the methods’ manuals, published by
the United States Air Force.
!"Many selected papers on the soft approach can be found in “Information Systems Provision –
The Contribution of Soft Systems Methodology”, edited by Frank Stowell.
The use of formalized Information Systems development methodologies can be seen from a critical
perspective through the series of papers of Dr. Brian Fitzgerald, who combines the conceptual,
academical point of view with that of the practitioner.
Many recent papers describe several aspects of component-based software development, which
seems to be the new trend in the IS discipline, addressing some problems such as re-use etc.
33 RReesseeaarrcchh MMoottiivvaattiioonn aanndd GGooaallss
The present research work aims to define and present the role that the Information Systems
Development Methodologies can play in the present era, which by many people is called “the era of
Digital Economy” or “the era of the New Economy”. Another target is to research if another form
would be necessary for the methodologies to survive in this new era and, if so, what this new form
would be like. For this purpose it is necessary to collate and compare the concept and the main
theoretical and practical characteristics of methodologies –on the one side- and the main
characteristics that compose the environments and the needs of the enterprises for the present and
the next years.
The first step is to present the notion of methodology at the level of a definition and at the level of
what practically constitutes one. This is the subject of Paragraph 3.1. Then, in Paragraph 3.2, the
main characteristics of this new business environment are presented, along with the needs that the
Information Systems are intended to address.
In Paragraph 3.3, a question is brought up for discussion, that has a central position in this research.
It is about the reasons for which a scientific approach to the concept of methodology is still valuable
nowadays. As a matter of fact, scientific research about an issue is justified only when the following
two prerequisites are both satisfied:
First, the anticipated results of the research can prove some valuable usefulness. A subject that can
contribute either to the theory or to the practice of its discipline is a subject that could justify a
researcher to study.
Second, there must be a scientific problem that is not already solved. If all the problems related to a
subject have been successfully addressed, then it is obvious that there can be no scientific research.
In a semiotic way, one could say that this is no more a subject of Science but it could be a subject of
Technology.
Thus, in Paragraph 3.3, we propose the existence of a problem that is not already solved and that its
solution may have a valuable usefulness to both theory and practice.
3.1 What Is A Methodology?
Trying to present some information about the conceptual abstraction of “methodology”, there are
two points of view:
One is to give a definition. In fact, there is no single definition of methodology and, to make things
worse, the existing definitions seem not even to be compatible one to another.
Second is to give some characteristics of a methodology, characteristics that are common to all (or,
at least, most of) the existing methodologies and affect their use.
3.1.1 Definitions
A variety of definitions have been proposed for the concept of methodology.
There are definitions where no clear distinction appears between the notions of “method” and
“methodology”. Several authors make no distinction at all and use either one term or the other
([Glykas 1994], [Avison, Fitzgerald 1988], [Flynn 1992]) to give the same meaning, that of a
“recommended collection of philosophies, phases, procedures, rules, techniques, tools,
documentation, management and training for developers of Information Systems” [Avison,
Fitzgerald 1988].
Others like [Checkland 1981], [Hirschheim et al. 1995] and [Vonk 1990] use both terms,
distinctively. For them, methodology is a higher order construct, more comprehensive than method,
a meta-method or method of methods, which may be used to systematically and logically assess the
appropriateness of any given method, while method is a way of accomplishing a task in a structured
manner.
What can be seen after all is that in most cases the definition given by an author heavily depends on
the school of thought where the author belongs. So, it would be more useful to discuss about several
characteristics of a methodology that mostly affect the way methodologies are used.
3.1.2 What constitutes a methodology?
A methodology can be viewed as consisting of three major components:
a) A work breakdown structure that provides guidelines of what to do and when to do it
b) Techniques on how to do what needs to be done
c) Advice on how to manage the quality of the results
The purpose of a methodology is to help a development group successfully change object systems,
that is to perceive, generate, assess, control and carry out the proposed system changes in them.
Methodologies are normative in the sense that they organize sets of behavioral and technical rules
into a coherent approach, which prescribes how to address major development problems.
A few aspects beg for comment here:
!"The idea of an organized collection implies that methodologies are not random sets of rules, but
they imply instead some type of coherence and integration between their parts.
!"Methodologies are not just rules, but they include concepts and beliefs that define the content
and behavior of the object systems (and their possible change) as well as values, which state
what properties in object systems are good and desirable.
!"In addition to rules, they also point to methods, which specify procedures for accomplishing
well-defined tasks, and normative principles (such as decision rules and organizing rules), which
specify behavioral expectations.
!"Methodologies are closely connected to material resources such as instruments and tools which
are drawn upon when the methodology is followed and enacted.
Methodologies must meet several conditions to achieve their purpose:
!"They must be written so that they can be taught, learned and transferred over a wide range of
development situations.
!"They must be understandable and socially acceptable.
!"Often, their use must be motivated by rewards and sanctions, because a methodology change
requires people to change their working habits, thinking and language.
!"Methodologies must be legitimized. Reasons to use them must be accepted and justified by
those who decide on their use.
3.2 Characteristics Of The “Digital Economy”
Internet commerce is growing fastest among businesses. It is used for coordination between the
purchasing operations of a company and its suppliers; the logistics planners in a company and the
transportation companies that warehouse and move its products; the sales organizations and the
wholesalers or retailers that sell its products; and the customer service and maintenance operations
and the company’s final customers. The expected benefits that drive businesses to shift their activity
to electronic forms, include [MITI 1997]:
!"Lower purchasing costs
!"Reduced inventory (the right products in stock)
!"Lower cycle times
!"More efficient and effective customer service
!"Lower sales and marketing costs
!"New sales opportunities
Business has been conducted electronically for many years, through technologies such as EDI
(Electronic Data Interchange) and EFT (Electronic Funds Transfer). But the Internet is fueling the
growth of e-commerce allowing consumers to purchase products and services electronically and by
providing open, widely available technologies for organizations to conduct business.
The press has declared 1999 as the year that electronic commerce entered the mainstream of world
business. IDC reports that worldwide e-commerce reached $130 billion in 1999. It is expected to
more than double during 2000 and is forecast to reach $2.5 trillion in 2004. This nearly 25-fold
increase in only five years will place enormous demands on the information technology industry to
deliver reliable, scalable systems to handle the huge volumes of business.
A detailed framework has been developed [MACIS 1998], encompassing the different financial,
social, managerial and technological issues involved, their importance and their interrelationships.
According to this framework, an organization is formed by five forces (structure, technology,
people, strategy, management processes) and operates in a specific external socio-economic and
technological environment. These forces are seen to be in dynamic equilibrium and move through
time to accomplish the organization’s objectives. The use of this model for the classification of the
key issues concerning the impact of Information Technology on the way business is done can be
seen in the following paragraphs.
3.2.1 Impact on the structure of organizations
High connectivity in and between organizations makes an enterprise part of a chain of events and
processes. This: (a) enables the organization to respond faster to changes in the outside world and
(b) puts a pressure on the enterprise to respond fast. On the other hand, due to the increased internal
communication, organizations are now becoming more team-based. All these call for new
approaches in the design of organizational structures, the development of strategies, the
implementation of management processes and the establishment of new frameworks. Non-core
activities are more and more being outsourced, network-type organizations appear and a large
number of partnerships or alliances are happening every day. These developments blur the corporate
identity and the organizational boundaries of an organization. Change becomes the only constant
thing in today’s organization and modern Information Systems (and the way they are developed)
must reflect all this flexibility needed, which introduces the meaning of “Living Information
Systems”.
3.2.2 Impact on technology management
The sweeping penetration of ICT in organizations is changing drastically the way technology is
and/or should be managed. It is obvious that technology management becomes one of the key
functions of management in an organization, there is a need for new skills for the job and there is a
growing “dependence-relationship” between the various functional areas of the organization and IT.
The IT expenses represent a large ratio of the organization’s budget so they are controlled much
tighter. Many different systems, developed in different periods of time, based on different
technologies, accomplishing different needs, must be connected and share data and functions. Users
become a key factor due to their increasing involvement. And most of all, businesses expect more
and more from technology as they see it as the key for keeping up with competition.
3.2.3 Impact on individuals in organizations
As the structure of the organization and the technology that is used is changing, one could safely
suppose that those changes affect the way individuals behave, do their work and feel about the
organizations. This stands for employees of organizations that use Information Systems as well as
for employees of organizations that develop Information Systems.
Employee loyalty and commitment are reduced and new forms of employment appear. People stay
for short time in the same position so time for training is extremely short too. And, concerning
organizations that develop systems, a long life-cycle means many changes of the people involved in
the project, which must be properly managed. Or, people working from a long distance, with no
personal contact to each other. Projects become different so project management must become
different and methodologies must reflect those changes.
3.2.4 Impact on strategy of organizations
The ICT already has significant impact on the strategy and the tasks performed in an organization.
Human capital is becoming the other key competitive factor, so the knowledge of the experts must
be properly diffused all over the organization. The expansion of companies to new markets and new
types of activities means that Information Systems are called to accomplish new needs in new ways.
And customers are brought in the center of the business activities, which often makes them users of
the systems (via the Web, for example), thus a part of the group of stakeholders, as well.
3.2.5 Impact on management processes
Most of the above changes have a strong impact on how the organization must be managed. Time
[Bloomberg 1999], communication and knowledge become the key concepts of management, being
tightly bound to ICT.
Communication is greatly improved (inside and through the organizational boundaries), faster
decision-making needs on-time, valid (though complex) information from multiple data sources and
organizational learning becomes a main demand, given that knowledge is the key to success and the
organization can’t be found to only a few (dangerously valuable) experts. The horizontal and
vertical flow of properly processed information is the only solution to these needs.
3.3 Why Do We Still Have To Study About Methodologies?
A methodology is a process that requires a major investment in human and material resources (high-
level staff, team management, sophisticated software and hardware tools, etc.). On the contrary, the
known as “quick and dirty” way of software development does not demand anything of the above
while, in addition, it offers important time saving which is not negligible at all in the current
demanding and competitive environment.
Apart from the above, there are many cases in the literature where the implementation of a
formalized methodology did not bring the prospected results. So what reason would there be for one
to use a formalized software development methodology, unless a specific benefit would be
expected?
The implementation of a formalized Information System Development Methodology is a process
that organizes work and influences the way of thinking of the development team’s members. So, if
the members of this team could properly organize their mind and the structure of their work without
the contribution of a methodology then the use (and, consequently, the study) of methodologies
would be worthless.
In fact, there are some extremely experienced analysts that do not tightly follow the steps of a
methodology but they mostly rely on their experience and their ability to cope with difficult
situations because they have faced such situations before. Apart from that, there are some cases
where a small-scale application is developed by a small team, which does not need any kind of
“official” structure.
3.3.1 Premises of the methodologies
The implementation of a formalized methodology is normally expected to bring some benefits and
address some challenges that include the following [Jayaratna 1994]:
Structure of tasks and functions: A methodology is not just a collection of tasks and activities. It
incorporates a philosophy and it grounds both the process in order to develop the new system and
the internal logic of the system itself on this philosophy.
Cost control: Major systems development projects usually involve considerable investments, which
include hardware and software needed for the operation of the development team and for the
operation of the system itself. A formalized methodology with firmly defined steps provides
advanced control on the operational cost of the development team and on the form of the final
solution (and, consequently, on the total cost of the solution).
Control of project: Due to its rigorous structure, a formalized methodology is supposed to provide
better control on the deliverables and, consequently, better control (a) on the progress of the project,
(b) on the final form of the solution and the response to the requirements and (c) on the quality of
the deliverables.
Minimization of uncertainty: Every step is clearly predefined and the results are predictable,
which means measurable and controllable.
Control of human resources: When a team of people undertakes a large-scale project, relations
and behaviors are going to grow. A formalized methodology defines both the skills that are expected
for a person to be a member of the development team and the roles that are assigned to them. This
form of structure and management of the team clarifies the relationships between the members of
the team and minimizes the problems that arise due to “unofficial” behaviors.
Exercising power: As a consequent of the above, the clear definition of roles due to a methodology
may facilitate the exercise of the assigned power by people that are properly authorized, in a
predefined and controllable manner.
Security: When the roles are defined and the power is strictly exercised, then the users may be
forced in various ways to comply their tasks in a specific manner.
Learning tool: Through the iterative steps of a methodology, knowledge and experience is
accumulated, about the characteristics and the official and unofficial relations of the organization in
issue and of the organizations in general, per size or per subject or per internal structure etc.
External factors: Large organizations of the public (usually) or the private sector pose as a
requirement the use of a specific methodology (e.g. SSADM in the United Kingdom). Generally, the
tense in large accounts is to demand that the development team holds a certificate of quality
assurance (e.g. ISO 9000), which is dramatically facilitated when a formalized methodology is used.
3.3.2 Problems with methodologies
The above premises of the use of methodologies seem very challenging and if they could stand
alone, free of any problems, no discussion would be necessary about the whole subject of whether to
use systems development methodologies or not and in what way. But, in fact, various problems
arise, some of them [Paul 1993] due to the nature of methodologies, the way they are structured and
the philosophy they are grounded on and some [Fitzgerald 1999] due to the recent evolutions of the
general business environment that were described in Paragraph 3.2. Some of these problems can be
described as follows:
Fixed Point Theorem: All methodologies are based on a conceptual assumption known as the
“Fixed Point Theorem” [Paul 1993]. This theorem takes for granted that there is a point in time
when all the stakeholders in an IT project really know what they want and this will remain constant
forever. This has never proved to be true. Even the so-called “soft” approaches do not stand far from
this theorem. Their difference of the “hard” approaches is that they consider the IS to be a much
more complex system and they take into account more parameters. On the other hand, approaches
like prototyping gives the user a better chance to participate in the development of the IS, but, even
a number of iterations, the “fixed-point” is supposed to be found.
Rapidly changing environment: The only constant thing in today’s business environment is
change. In a turbulent environment [Salmela et al. 2000], the Information System must rapidly adapt
to the continuously changing conditions. According to the above, methodologies based on the “fixed
point theorem” cannot accomplish such a requirement.
Cost: A methodology is a very expensive procedure. This means that small companies and
organizations and early-starters without the financial power of large organizations or multinational
enterprises, for example, cannot stand the cost to apply one, so they simply follow the ad-hoc way.
Time: A methodology is a very time-consuming procedure. This means that a formalized
methodology seems not to be appropriate for the world of e-business where everything must be done
quickly. This, in conjunction with the fixed-point theorem, encounters the fact that during a long-
term project, the environment and the conditions at the end of the project will be different than those
at the beginning.
Building on existing infrastructure: Traditional methodologies are intuitively based on the
hypothesis that the organization under consideration has no IS at all, which was mainly the truth
before 2 or 3 decades when those methodologies were first introduced. In today’s environment,
most organizations have a kind (or a level) of IT services and what they need is some modifications
on the existing IS (in order to exploit new technologies or to follow organizational change) or
expansion of the existing IS to new business processes (e.g. e-commerce).
Reuse: Most traditional, formalized methodologies tend to re-invent the wheel, while modern,
component-based development of IS applications can reuse previous work. This is a serious waste
of resources and modern methodologies must be adapted to this new reality [De Marco 1996].
Alternative aspects: The strategic, creative and marketing components of an e-commerce project
are every bit as important as developing the software. Traditional formalized methodologies, for
example, do not take into account that the “artistic” side of the IS, in many cases is almost the most
important component. And, especially in case of B2C (Business to Consumer) applications, the user
interface is the equivalent of the showcase for the consumer. To make things worse, it must be taken
into account that in these cases the user of the system usually is a consumer with no training at all.
3.3.3 The component-based approach
A serious attempt towards the solution of some of the problems mapped in paragraph 3.3.2, was the
evolution of the component-based software development. Some of the problems addressed by this
approach were related to time needed, reuse of software (and thus cost), building on existing
infrastructure.
The component-based approach is concerned with the development of software systems by using
components as the essential building blocks. It is not a revolutionary approach but incorporates
successful concepts from established paradigms like object-orientation while trying to overcome
some of their deficiencies. Proper encapsulation of common functionality, for example, and
intuitive graphical description techniques like class diagrams are keys to the widespread success of
an object-oriented software development process. However, the increasing size and complexity of
modern software systems leads to huge and complicated conglomerations of classes and objects that
are hard to manage and understand. Those systems obviously require a more advanced means of
structuring, describing and developing them. Component-based development is a possible approach
to solve these problems.
Component-based system development is rooted in the object-oriented model, which represents a
major revolution in software engineering. Objects are straightforward abstractions of real-world
entities. The component model, on the other hand, focuses on building software systems by
combining and matching pre-developed software objects. The component concept is an extension of
the object concept. The benefits of the component approach range from rapid software development
to increased customization and maintainability and enhanced software quality. Components with
well-defined interface can be quickly combined and assembled to form a complex application
system [Lewandowski 1998].
With the component model, some software companies can focus on individual component
development and leave system assembly tasks to others. With increasing specialization, software
producers can enhance their productivity. Businesses can purchase components from different
vendors or develop more specialized components in-house in order to assemble a highly customized
enterprise system. In a dynamic business environment, when companies are changing their business
strategies and processes, they can simply replace old components with new ones. The result is easy
software maintenance and guaranteed minimum delay between business information systems with
business processes.
An analogy to the building industry illustrates a successful application of such a component-
oriented approach: First, the building owner provides the architect with the functional and non-
functional requirements in a more or less informal way. Examples are the number and function of
rooms and the money he wants to spend. The architect then constructs a first, overall ground plan
and several side views or even a computer-generated virtual model of the building. If these
proposals meet the owner’s expectations, the architect will elaborate a more detailed and technical
construction plan. It describes the different components of the building, like walls and windows,
and how they fit together. Now the architect invites tenders for these components and evaluates their
offers. At last, the “best” component producers get the job, place the components to the architect’s
disposal and integrate them into the building. During the whole process, the architect’s construction
plan is the basis of communication between all parties working on the building.
Although there already exist a variety of technical concepts and tools for component-oriented
software engineering, the successful model from the building industry was not completely
transferred to software development yet. This seems to be partly due to the lack of a suitable
component-oriented methodology [Ran 1999], [Fan et al. 2000].
There have been attempts for the standardization of the component-based development, like COM
(Component Object Modeling), CORBA (Common Object Request Broker Architecture) and EJB
(Enterprise JavaBeans) specifications and UML (Unified Modeling Language), which give very
useful tools to the developers of enterprise applications. But still some shortcomings occur, that
stand against our will to see those specifications as the ultimate approach to software development
[Mattson et al. 1999].
COM, CORBA and EJB are all technical oriented and their main subject is to give proper,
standardized interfaces for the communication between objects and components. On the contrary,
[Cline, Girou, 2000] the specification of an easily adaptable software application is primarily a
business problem, not a technical one. Indeed, the most important questions have to do with the
underlying business.
On the other hand, UML, as a modeling language, is expected to address such shortcomings and
picturize the business rules and the business culture necessary for the proper structuring of the
Information System. But, [Kobryn, 2000] the semantics for component are dated and emphasize
implementation diagrams, which typically occur at the tail end of the modeling process. This means
that currently, traditional techniques and tools (e.g. DFDs) are used for the early analysis and design
tasks. Thus, component-based development seems to inherit problems that stem from the
fundamental concepts of traditional formalized methodologies.
Apart from that, as component applications grow and proliferate, so will the need for abstractions to
manage their size and complexity. Consequently, UML model management constructs should be
refined, extended or augmented to support large component systems and frameworks. These
constructs include, but are not limited to, containers, frameworks and subsystems and better
guidelines and examples for mixing and matching these constructs.
Various attempts occur, such as Enduring Business Themes (EBT) and Enduring Business
Frameworks (EBF) [Cline, Girou, 2000] to overcome such issues, especially those related to the
business aspects of the Information Systems development. Approaches like these are very
interesting and promising but still very young to be implemented and tested in real world cases.
44 RReesseeaarrcchh MMeetthhoodd aanndd AApppprrooaacchh
It is well noted that any research effort should aim to contribute both to the theory and practice of IS
[Cornford, Smithson, 1996]. Referring to [Iivari 1991], the same authors present a framework of
three broad styles of research:
!!!!""""Constructive research methods
#"Conceptual development
#"Technical development
!!!!""""Nomothetic research methods
#"Formal-mathematical analysis
#"Experiments, laboratory and field
#"Field studies and surveys
!!!!""""Idiographic research methods
#"Case studies
#"Action research
The above is not simply a list of distinct research techniques consisting of elements that can be
“mixed and blended” in a kind of a receipt. More than this, the above represent a framework of
choices for the structuring of the research approach. Each of them represents a different point of
view and it can reveal different aspects of a topic.
The development of a conceptual framework is first of all necessary for the efficient and valid
setting of a number of well-defined hypotheses, the verification or disapproval of which, will guide
the research. This framework, taking into account both the requirements of theory and practice,
must include a description of the area in which the research will take place, its present status, and
will conclude to a robust statement of the problem that is going to be studied.
Field studies and surveys give the necessary statistical population for their results to be valid, with
respect to the conditions in which they stand. A survey on a sample statistical population of the
proper size and suitably chosen, gives to the researcher the opportunity to extract fruitful
conclusions, using techniques like clustering.
Surveys however do not give the researcher the opportunity to go deep inside the elements of
particular situations and examine the influence of specific parameters on the relevant problems.
Taking this fact into account, it is anticipated that our research design will include one or more case
studies.
As the above picture shows, the first step of this research will be the construction of a conceptual
framework. This must include the needs that a methodology must address in the organizations of the
THE RESEARCH APPROACH
✔ Constructive Research Methods– A conceptual developm ent
✔ Nomothetic Research Methods–Field studies and surveys
✔ Idiographic Research Methods–Case studies
present and the future and the way that the existing methodologies do so, at least according to their
specifications.
Then, this framework will be tested against “real world”, with the use of surveys and field studies.
Their results will be useful feedback to the conceptual framework, with two goals:
!"First, to correct possible shortcomings of the framework itself
!"Second, to give the requirements that a methodology must accomplish in order to be useful for
modern businesses and organizations
The final result will be a kind of an outline of a methodology, probably accompanied with some
necessary software tools, proper to be implemented in real cases. It would be ideal if this “package”
could be tested in a real case, which would be used as a case study.
55 EExxppeecctteedd RReessuullttss aanndd LLiimmiittaattiioonnss
As already mentioned above, the expected results of the research, include both a mapping of the
problems occurring on the implementation of Information Systems development methodologies in
modern organizations and an attempt to investigate new forms for the methodologies to overcome
their present shortcomings. As a final result, the formulation of a new methodology’s outline is
expected.
Limitations come from two sides:
First, both the scale of the Greek business market and the scale of most Greek enterprises are not
always appropriate for the study of large IT projects. Apart from that, it is not always easy to find
willing answers to surveys and questionnaires and most of all appropriate case studies.
Second, trying to construct a new methodology beyond conceptual positions, along with specific
techniques, tools and possibly software tools requires an effort, which is beyond the capability (and,
probably, the scope) of a research project like this.
66 RReeffeerreenncceess
Avison D.E., Fitzgerald G. (1988) Information Systems development: methodologies, techniques
and tools, Blackwell Scientific Publications
Bergner K., Rausch A., Sihling M., Vilbig A. (1999) Componentware – Methodology and process
Bloomberg J. (1999) Software methodologies on Internet time,
http://datamation.earthweb.com/apdev/9910meth1.html
Checkland P. (1995) Soft Systems Methodology and its relevance to the development of Information
Systems, in INFORMATION SYSTEMS PROVISION (ed. Frank Stowell), McGraw-Hill
Checkland P.B. (1981) Systems thinking, systems practice, John Wiley, Chichester
Cline M., Girou M. (2000) Enduring Business Themes, Communications of the ACM, May
2000/Vol. 43, No. 5
Cornford T., Smithson S. (1996) Project research in information systems. Macmillan Press
DeMarco T. (1996) The role of software development methodologies: past, present and future,
Proceedings of the 18th International Conference on Software Engineering, pp. 2-4
Fan M., Stallaert J., Whinston A.B. (2000) The adoption and design methodologies of component-
based enterprise systems, European Journal of Information Systems, 2000, 9, pp. 25-35
Fitzgerald B. (1999) Systems Development Methodologies: the problem of tenses, forthcoming in
Information Technology & People
Flynn D.J. (1992) Information Systems requirements – Determination and analysis, McGraw-Hill
Glykas M.M. (1994) Agent Relationship Analysis in Organizational Transformation: the ARMA
methodology for systematic Business Process Redesign, PhD Thesis, Cambridge University,
Engineering Department
Hirschheim R., Klein K. Lyytinen K. (1995) Information Systems development and data modeling –
Conceptual and philosophical foundations, Cambridge University Press
Iivari J. (1991) A paradigmatic analysis of contemporary schools of software development,
European Journal of Information Systems, Vol.1, No.4, pp.249-272
Jayaratna, N (1994), Understanding and Evaluating Methodologies, McGraw-Hill, UK
Kobryn C. (2000) Modeling components and frameworks with UML, Communications of the ACM,
October 2000/Vol. 43, No. 10
Lewandowski S. M. (1998) Frameworks for component-based client/server computing, ACM
Computing Surveys, Vol. 30, No. 1, March 1998
MACIS (1998) Development of a Management Curriculum on and for the Information Society,
ESPRIT Project, http://www.hellasnet.gr/macis
Mattson M., Bosch J., Fayad M. E. (1999) Framework integration – Problems, causes, solutions,
Communications of the ACM, October 1999/Vol. 42, No. 10
Ministry of International Trade and Industry (MITI), Japan (1997) Towards the Age of the Digital
Economy – For Rapid Progress in the Japanese Economy and World Economic Growth in the
21st Century, http://www.miti.go.jp/intro-e/a228101e.html
Paul R. J. (1993) Why Users Cannot “Get What They Want”, ACM SIGIOS Bulletin, December
1993, Vol.14, No.2, pp.8-12
Ran A. (1999) Software isn’t built from Lego blocks, Symposium on Software Reusability SSR ’99
Los Angeles CA USA
Salmela H., Lederer AL., Reponen T. (2000) Information systems planning in a turbulent
environment, European Journal of Information Systems, 2000, 9, pp. 3-15
Vonk R. (1990) Prototyping: The effective use of CASE technology, Prentice-Hall, London