and steps and used the methodologies more as a project management tool than
a ... is the book “Information Systems Development: Methodologies, Techniques
... methodologies are based, is given in “Information Systems Development and ...
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
[email protected]
Number of Words: 6233 Keywords: IS development, IS development methodologies
Information Systems Development Methodologies in the Age of Digital Economy
0 Abstract 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.
1 Introduction 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.
2 Literature Review 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.
3 Research Motivation and Goals 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 (highlevel 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 longterm 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 componentoriented approach: First, the building owner provides the architect with the functional and nonfunctional 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.
4 Research Method and Approach 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.
THE RESEARCH APPROACH ✔ Constructive Research M ethods – A conceptual developm ent
✔ N omothetic Research M ethods –Field studies and surveys
✔ Idiographic Research M ethods –C ase 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
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.
5 Expected Results and Limitations 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.
6 References 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 componentbased 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
