Implications of Information Technology in System Development
Every organization without any exceptions needs information and a system to manage the information (Avison & Fitzgerald, 1998). This system for managing information is called an Information system and it can be totally manual, computerized or a mix of the two. The information system is not just popping up, but has to be created. This process of creating is the system development. Some authors also include the managing, maintenance and liquidation in the system development and this as parts of the system development lifecycle.
This essay shall illustrate systems development and how the traditional methods used before needs to incorporate information technology. Moreover, the benefits of IT in systems development shall also be assessed. A review of previous works and scholars shall be the basis for this analysis.
Systems development covers a broad array of information. When we talk of system development we point out the process of developing information systems and not just systems in general. Different authors differs in opinion of what the system development contains of and in what way we should develop. One uses concepts like methods, methodologies and tools but defines these concepts in different ways. Often can different methods use similar vocabulary and contain the same phases, but when we study the under laying philosophy they have not much in common. Avison & Fitzgerald says that from 1988 to 1994 the brand names of methodologies increased from 300 to 1000 (1998). They continue with claiming that many of them have much in common and are only differenced to special markets or situations and this often by marketing purposes.
Methods are used and then discharged, the method used yesterday seemed to be the perfect one, but soon there is a new and better one. The term method is so commonly used in IT community in the context of software development that hardly any effort was ever made to define its semantic. With hundreds of methods with which to develop IT systems anything that looks like some kind of a software development process or architecture framework or even notation for a system modeling is called a method (and sold as such) no matter how close it resembles one.
System development is an activity in which a systematic approach is taken to investigate the conditions to realize a computerized information system improve the business in a company or a organization and also in agreement with the result model, construct and introduce information system in a practical application (Nationalencyklopedin, 1995). System development is about to solve new unknown problems or to further elaborate solutions to known problems that occur in systems, which handle different kind of information (information systems). Maybe it is better to speak of information system development instead of system development in our science, but that would be too heavy to use in the long run according to Andersen (1994).
Basic foundations in system development
Loen & Stolterman state that generally we seek for the perfect method, but claim that this is the wrong focus (1998). The result is mainly dependent of the participants of the process and will never be better than these. They continue with claiming that different methods are collections of history, experience and competence and should only be used as such collections. It s the methodology beyond that we should reflect and challenge in our developing process. Jan Stage has gone even further and claims that application of new system development methods even might be to compensate for the developers lack of competence and the only problem solved is their feeling of incompetence (Brejknes & Dahlbom, 1990). Other authors mean that system development moves toward a more industrial development process and therefore we should use the term Software engineering instead (Eriksson & Penker, 1996).
Methodologies
This makes us move forward to the definitions of methodologies, method, etc. Loosely rendered from Eriksson & Penker (1996) and combined with thoughts from Avison & Fitzgerald (1998) and Loen & Stolterman (1998) we could make a hierarchical picture of the relationships between different concepts. For example the same tools may be used in several techniques. Though several authors agree about the relations about the order of method techniques tools, they differ in their view of methodology method. Sometimes the concept methodology is used in a way that other author s claim is method and vice versa. In classical theory of science methodology is the doctrine about a method (Nationalencyklopedin, 1994). This view of the relationship is adopted by Eriksson & Penker (1996) and they state that the methodology is the philosophy beyond the method. The philosophy is essential for understanding the method and then using it properly. You cannot compare methods without comparing the methodologies behind. The methodology as concept can in some ways be related with the concept paradigm. Examples of philosophies behind different methodologies are human aspects, scientific approach, pragmatic view, expert-lead development (Avison & Fitzgerald, 1998), user-lead development and developing with focus on the organizational competence (Bjerknes & Dahlbom, 1990).
Some authors lack a clear distinction between method and methodology. British Computer Society (BCS) defines an information system methodology as a recommended collection of philosophies, phases, procedures, rules, techniques, tools, documentation, management, and training for developers of information systems (Maddison, 1983). Avison & Fitzgerald (1998) have adopted this definition as we can see in their definition of system development methodology: A collection of procedures, techniques, tools, and documentation aids which will help the system developers in their effort to implement a new information system. Their definition continues, but the extract above is enough to show their view of sight. They continue with claiming that a methodology usually is based on some philosophical view, otherwise it s just a method. This is in our opinion the fundamental breaking point. The methodology is just the philosophical founding behind a method and the method is the collection that Avison & Fitzgerald describes. In some way we can agree with Maddison (1983) and see the methodology as the overall, which contains everything below in the hierarchy.
This view tends to bring more chaos than clearness, so we would prefer to see methodology as the philosophy behind the method and the method as the overall that contains everything below in the hierarchy. It may seem to be a slight difference, but although important.
Method
Its common to briefly describe methods in general, when one tries to describe a method in particular. Therefore it seems like almost every spokesman for a method has his/her own definition of what a method is. Though this confusion we will try to find a general definition for the concept. If the methodology is the philosophy behind the method, than we can break that out from BCS definition of information system development; a recommended collection of phases, procedures, rules, techniques, tools, documentation, management, and training for developers of information systems (Maddison, 1983). The definition of methodology above by Avison & Fitzgerald is a method if it is not based on a philosophical view (1998). Eriksson & Penker have several definitions of methods (1996). First they state that methods help us to solve problems that are alike. Human has always worked according to methods, whether it is how to bake bread or how to forge a sword. There are needs for several methods because of different problems, situations and contexts. In the area of system developing the authors say that a method contains a concept of models, a developing cycle and different phases. Eriksson & Penker also tries to define method in an even more general way by saying that a method is a notation (representation, model) and a process (phases, flow). If we combine and relate the above-mentioned definitions of method, we may have an overview and a starting point to identify what a method for information system development in general contains.
With the picture from the Methodology-part fresh in mind we can say that with method as an overall concept it contains techniques and tools. These techniques and tools are yet usually not unique for just one method. Let us describe this with a simple example. The recipe of how to bake muffins is a sort of method. When you are to mix egg with sugar there are several ways to do this. Mix, stir, beat or whip are different techniques that you may choose and of course these techniques are used in other recipes as well. If you decide to whip you can use the tool electric mixer, of course there is nothing that says that you have to use a special brand, etc. So we may conclude this with that techniques and tools may be a part of a method but are not bounded to the method as concept.
The phases of development
The process of an information system development method is the process from problem/idea to an implemented and functioning system. Methods use to contain certain phases of development and suggestions of in what order we are to do certain things, for example analyze, construction, and implementation. If we continue the definition of methodology, interrupted above, by Avison & Fitzgerald says (1998): A methodology will consist of phases, themselves consisting of sub-phases, which will guide the system developers in their choice of the techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate information system projects.
Once again we keep in mind that Avison & Fitzgerald mean that a methodology is simply a method if it lack of philosophy, but anyway we can conclude with that they count the phases and their sub-phases as parts of a method. Eriksson & Penker claims that the process of a method also includes a development cycle (1996). This development cycle control in what order things are to be done, both referring to the phases and within a phase. The authors give some examples of development cycles, such as iterative, incremental, sequential (waterfall), recursive, parallel, and fountain. We may agree with the statement that this development cycle exists and is essential, but we believe that this should be defined as a part of the philosophy behind the method as part of the methodology.
The Organization and System Development
One aspect of the organizational context of internal projects is the system designers’ interactions with users during the development process. Many studies have investigated and championed users’ participation in system development as a means to improving design (Wilson, 1991). Keil and Carmel (1995) described the different kinds of participative practices available in the product development and in-house environments. Despite the difficulties of accessing end users in product development projects, user involvement is still advocated as a way of gaining a better understanding of user needs (Grudin, 1991; Keil & Carmel, 1995).
Advantages of IT in System Development
Organizations has become increasingly interested in analyzing the organizational context of systems design (e.g., Curtis, Krasner, & Iscoe, 1988). Previous work has focused on product development organizations in identifying organizational constraints on the work of system designers (Grudin, 1991). This essay focuses on the evolution of different approaches to systems development and how information technology helps in achieving the strategic objectives of organization. Here the organizational context (in terms of shared beliefs, politics and inter- and intragroup relations) is seen as an agent for the success of the system development and IT enhancement.
Traditional system development research has concentrated on seeking ways in which to design more usable interfaces. This search has tended to focus on the development of cognitive theories of user behavior in interaction with computer technology (user modeling) in order to define design parameters (e.g., Howes, 1995). With Suchman (1987) observations of situated action, participatory design projects (Greenbaum & Kyng, 1991), and sociological accounts of computer use in context (e.g., Button, 1993), this search has moved out of the laboratory and sought to take a more holistic view of the users’ world as a way of informing design (Wixon, Holtzblatt, & Knox, 1990 ). It is now quite widely accepted that we must understand users’ working practices in detail and in context to design technology that can be effectively incorporated in work systems (e.g., Blomberg, 1995; Markus & Keil, 1994), a perspective now enhanced by the interest in developing groupware.
Another branch of information technology has sought to understand the design process from the perspective of system designers. Analogous to user modeling studies, some researchers have investigated the cognitive problem-solving strategies of designers (e.g., Guindon, 1990). As in Suchman (1987) account of users, Sharrock and Anderson (1993) emphasized the “situatedness” of such technical problem solving when viewed out of the laboratory. Again associated with the rise of interest in groupware, attention has now turned to the work of design teams and how designers collaborate on larger scale projects over time (e.g., Kraut & Streeter, 1995).
From a system development perspective, there is a growing interest in modeling the software development process with IT (Fuggetta & Wolf, 1996), in the sense of creating procedures and plans to allow a more effectively managed process. Sommerville and Rodden (1996) argued that the use of particular development methods is consistent with particular organizational cultures; for example, hierarchical organizations may prefer traditional waterfall methods.
For years, an inability to change those systems quickly has thwarted promising business innovations. But several new approaches to systems development are now able to deliver business benefit fast. Not all of them are technically elegant. Not all of them will work in every situation. But, taken as a group, they make even major changes to information systems possible in weeks or months — rather than the years required by traditional efforts.
One reason that existing systems-building methods are so slow to deliver business benefit is that they are frequently shaped by the systems developer’s priorities, not those of the business itself. In the traditional development process, developers can become isolated from business needs. As a result, they spend a great deal of time solving technical problems that bring only marginal business benefit.
The inability of organizations to incorporate such design features can exacerbate conflict. Unfortunately for some program managers, some systems may have a structure that renders them unable to incorporate desirable features. Perrow (1984) notes that managers have comparatively little choice in the design of some of their systems. Development may require that all components lie in close proximity or be developed on site. A system’s functionality may be so specialized as to preclude the addition of new functions. By recognizing the role of technology in the accommodation of developments–and by recognizing differences among technologies in their ability to allow such accommodation—managers and employees can better understand why program outcomes vary (Klein, 2000).
System dynamics with the aid of information technology, on the other hand, can organize the descriptive information, retain the richness of the real processes, build on the experiential knowledge of managers, and reveal the dynamic behaviors that follow from different policy choices (Forrester, 1995).
References
Andersen, E.S. (1994). Systemutveckling principer, metoder och tekniker. (A. Helleskog & Ů Forsberg trans.). Lund: Studentlitteratur.
Avison, D.E. & Fitzgerald, G. (1998). Information Systems Development: Methodologies, Techniques and Tools. (2 ed.). Berkshire: McGraw-Hill Book Company Europe.
Bjerknes, G. & Dahlbom, B. (1990). Organizational Competence in System Development. Lund: Studentlitteratur.
Blomberg, J. (1995). Ethnography: Aligning field studies of work and system design. In A. Monk & N. Gilbert (Eds.), Perspectives on HCI: Diverse approaches (pp. 175-197). London: Academic.
Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31, 1258-1287.
Eriksson, H-E & Penker, M. (1996). Objektorientering handbok och lexikon. Lund: Studentlitteratur.
Forrester, J. (1995) The Beginning of System Dynamics. The McKinsey Quarterly, No. 4.
Fuggetta, A., & Wolf, A. (Eds.). (1996). Software process. Chichester, England: Wiley.
Greenbaum, J., & Kyng, M. (Eds.). (1991). Design at work: Cooperative design of computer systems. Hillsdale, NJ: Lawrence Erlbaum Associates, Inc.
Grudin, J. (1991). Systematic sources of suboptimal interface design in large product development organizations. Human-Computer Interaction, 6, 147-196.
Guindon, R. (1990). Designing the design process: Exploiting opportunistic thoughts. Human-Computer Interaction, 5, 305-344.
Howes, A. (1995). An introduction to cognitive modelling in human-computer interaction. In A. Monk & N. Gilbert (Eds.), Perspectives on HCI: Diverse approaches (pp. 97-119). London: Academic
Keil, M., & Carmel, E. (1995). Customer-developer links. Communications of the ACM, 38, 33-44.
Klein, H. (2000) System Development in the Federal Government: How Technology Influences Outcomes. Policy Studies Journal, Vol. 28.
Kraut, R., & Streeter, L. (1995). Coordination in software development. Communications of the ACM, 38, 69-81.
Loen, J. & Stolterman, E. (1998). Design av informationsteknik materialet utan egenskaper. Lund: Studentlitteratur.
Maddison, R.N. (ed.) (1983). Information System Methodologies. Chichester: Wiley Heyden.
Nationalencyklopedin (vol. 13). (1994). Hoo Bokfoget Bra Bor
Nationalencyklopedin. (vol. 18). (1995). Hoo Bokfoget Bra Bor
Perrow, C. (1984). Normal accidents. New York, NY: Basic Books.
Sharrock, W., & Anderson, B. (1993). Working towards agreement. In G. Button (Ed.), Technology in working order: Studies of work, interaction and technology (pp. 149-161). London: Routledge.
Sommerville, I., & Rodden, T. (1996). Human, social and organisational influences on the software process. In A. Fuggetta & A. Wolf (Eds.), Software process (pp. 89-109). Chichester, England: Wiley.
Suchman, L. (1987). Plans and situated actions. New York: Cambridge University Press.
The Oxford English Dictionary. (vol.III & X). (1961). London: Oxford University Press.
Wilson, J. (1991). Participation–A framework and a foundation for ergonomics? Journal of Occupational Psychology, 64, 67-80
Wixon, D., Holtzblatt, K., & Knox, S. (1990). Contextual design: An emergent view of system design. Proceedings of CHI ’90 Conference, 329-326. New York: ACM.
Credit:ivythesis.typepad.com
0 comments:
Post a Comment