- Email: [email protected]
A viewpoint on software engineering and information systems: what we can learn from the construction industry?
Information and Software Technology 43 (2001) 795±799
www.elsevier.com/locate/infsof
Short Communication
A viewpoint on software engineering and information systems: what we can learn from the construction industry? David Avison a,*, David Wilson b a
Department of Systems d' Information et de Decision, ESSEC Business School, Avenue Bernard Hirsch-BP 105, 95021 Cergy-Pontoise cedex, France b University of Technology, Sydney, Australia Received 16 June 2001; revised 21 August 2001; accepted 23 August 2001
Software engineering seeks to improve our understanding of software systems; whereas information systems look at their impact on individuals, organizations and society. There are many common interests. We share some methodologies, techniques, tools, and even research methods. We are frequently researching and practicing in the same areas. Yet, we are not sharing experiences. Software engineering (SE) is seen as `teckie' by information systems (IS) analysts; and IS seen as `wishy-washy' by software engineers. Further, to some extent at least, each seems to be attempting to take over each other's territory and become `all things to all men'. We are in midst of a power struggle, which is wasteful and unproductive. Even worse, practitioners too often see both disciplines as irrelevant to the `real world' and SE and IS analysts are often seen as unprofessional and associated with failure. As well as being `messy' and unfortunate at best, this does not make any practical sense. We wish to engender debate to improve this situation. We see both SE and IS improving as disciplines and practices by clearer de®nition and separation of activities. In this article, we look at the construction industry as a possible analogy to engender debate. We use this model to provide guidance which might lead to a more positive spirit of genuine co-operation between software engineers and IS analysts, inspire more con®dence to users and organizations, and yet distinguish clearly the roles of each, both in computer applications development in practice and in their curricula and status in higher education. 1. The building analogy We can use the `building analogy' to illustrate and explain the IS development life cycle, indeed the latter is similar to the `achievement of large and complex projects in other areas of endeavor' [1]. The problems are similar: the * Corresponding author. Tel.: 133-1344-33195; fax: 133-1344-33001. E-mail address: [email protected] (D. Avison).
decomposition of complex activities, estimating costs and schedules and the management of multi-disciplinary teams. However, to help understand the analogy, the reader is asked to consider a building to be a one-off, architectdesigned, development, as it normally is in France, for example, not one of a number of very similar houses, typical as found in an English housing estate. The building analogy provides a useful illustration of the complex process and we will provide an example that most of us can easily visualize: 1. A person has bought a plot of land and wants to build a new house. The buyer approaches an architect and sketches out his/her basic requirements for the new house: three bedrooms, modern kitchen, home of®ce and double garage. The architect then prompts the buyer with questions in order to develop these requirements into suf®cient detail for a house plan to be drafted. The architect uses his/her knowledge of modern design to ask questions such as: Do you want an en suite bathroom? Do you want the garage to be integral to the house? Do you want a brick house? Do you want a wood frame? This information is suf®cient to draw up a draft plan for comment. Changes will be incorporated and the plans signed off. 2. The plans are then submitted to a construction manager/ planner or civil engineer who develops detailed design speci®cations from the plans. The construction planner uses his/her knowledge of building regulations and of building material properties to develop the speci®cations. During this process, the construction planner identi®es problems (where the plans cannot be physically implemented) and options (where the plan can be implemented in a variety of ways) and these are referred to the buyer for resolution. Finally, the construction planner draws up the speci®cations and sends them to the buyer for approval. The buyer may ask questions and demand further changes, for example, differently coloured tiles
0950-5849/01/$ - see front matter q 2001 Elsevier Science B.V. All rights reserved. PII: S 0950-584 9(01)00186-0
796
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
The plans and speci®cations relate to ISs development documents as follows:
Table 1 Development cycle and levels of discourse Step
Description
Level of discourse
1
Requirements de®nition
Level 5: articulating the problem Level 4: structuring the problem
2
Design
Level 3: establishing structure (or model) for solutions Level 2: exploring and evaluating options
3
Construction (program development)
Level 1: assigning referents to solution
or a serving hatch between kitchen and dining room. The changes are made and the speci®cations signed off. 3. The speci®cations are then submitted to a builder to build the house using his/her knowledge of construction techniques (and possibly those of sub-contractors). The builder may identify problems during the process (for example, particular materials not being available) and options, and again these are referred to the buyer for resolution. Finally, the builder completes the house and the buyer inspects the ®nished product. The buyer may ask for remedial work to be carried out to meet the speci®cation, for example, one of the doors may not close properly or the kitchen cabinets not being as speci®ed. The remedial work is carried out and the contract signed off. 4. The buyer moves into the house, which meets his/her requirements.
2. The analogy applied to IS and SE The analogy is useful in illustrating and explaining the ISs development life cycle and the roles of people in it. The house represents the IS and the roles as follows: ² the house buyer (user); ² the architect (systems analyst); ² the construction manager/planner or civil engineer (software engineer); ² the builder (programmer/coder).
² basic requirements (concept proposal); ² plans (requirements de®nition); ² speci®cations (design speci®cation). We can explain the need for these steps in developing solutions to requirements through the ®ve levels of discourse shown in Table 1 [2]. This also relates the steps to the levels of discourse and suggests that different skills are needed for the different steps. Step 1, we will argue, is the role of the systems analysts; step 2, that of software engineers, and step 3, that of programmers/coders. Of course, the above descriptions of systems development for buildings, software and ISs are rather simplistic. Development follows a much more iterative and spiral model, there is fuzziness and overlap, but this does not alter their similarity in many aspects. However, there are important differences in training, professionalism and roles of software engineers and ISs analysts. These are at least part implied through developing the analogy. To re¯ect the different skills required at each step, the construction industry not only de®nes separate roles (architect, construction manager/planner, civil engineer, builder) but also de®nes a separate body of knowledge for each and requires quite distinct training and education to attain distinct professional quali®cations. These differ in detail according to country but in principle: ² An aspiring architect must enrol on a degree in architecture and on graduation join a recognized profession with its own professional society. ² An aspiring construction manager/planner must enrol on a degree in building and on graduation join a recognized profession with its own professional society. ² An aspiring civil engineer must enrol on a degree in engineering and on graduation join a recognized profession with its own professional society. ² An aspiring builder must enrol for a trade quali®cation and gain speci®c training and education focused on the builder's role in the development cycle. In addition, the construction industry recognizes other
Fig. 1. Building development.
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
797
Fig. 2. Information systems development.
specialist roles, such as project managers and quantity surveyors, and there are training programs for them as well. The relationships between these different roles within the development life cycle are shown in Fig. 1.
systems analysis draw more on sociology, psychology, economics and other management disciplines it is likely to be situated in a management or social science faculty. We see IS and SE, therefore, as separate disciplines associated with separate disciplinary groups.
3. Emerging computing disciplines
4.2. Curricula
The construction industry provides an interesting contrast to that of the IT industry. Separate roles are suggested and sometimes de®ned, but there is often confusion. Many future software engineers and systems analysts graduate from similar generic degrees in computing or management, many others do not have a related quali®cation at all. The industry neither recognizes distinct bodies of knowledge nor distinct quali®cations for the different roles. We argue that SE and systems analysis require different types of people, having different skills, different backgrounds, different quali®cations and belonging to different professional organizations and, perhaps, having different personality traits. Fig. 2 shows a similar model of IS development as the building life cycle of Fig. 1. Although it shows the involvement of both system engineers and system analysts in some parts of requirement de®nitions and design, these are the different aspects of the overall process. This leads to the requirement for good communications between the software engineer and system analyst.
We suggest separate degrees and curricula for ISs and SE programs. SE might include:
4. Implications
² ² ² ² ² ² ² ² ² ² ² ² ²
We draw out a number of implications inspired from this comparison of ISs development and building construction. 4.1. Disciplinary groups We see the separation of SE and systems analysis into distinct departments or groups within universities. SE is likely to be in an engineering faculty and ISs and system analysis in a management faculty. SE can draw on the other disciplines likely to be situated in the engineering faculty and is related to other engineering disciplines in spirit [3]. Parnas argues this is not to do with questions of ownership, but those relating to content and style of education. SE may also draw on disciplines in a science faculty, for example, computer science, physics and mathematics. As ISs and
² ² ² ² ² ² ² ² ² ² ² ² ² ² ²
requirements analysis; software architecture; design; testing and quality assurance; software management; project management; selection and use of software tools and components; human±computer interface; maintenance; communications skills; documentation; architecture; database and information retrieval; programming languages; introduction to ISs issues. ISs courses might include: systems thinking; IS and the organization; IT/IS strategy; requirements analysis; systems analysis techniques; ISs methodologies; communications skills; human±computer interaction; project management; change management; knowledge management; e-business; introduction to SE issues.
We make three observations from these outline curricula. First is the importance of a course unit that looks at the other discipline, thus enabling cross-understanding and
798
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
supporting good communications between the two. The second observation concerns the otherwise sparsely shared subject matter. The third is that neither program looks like a computer science (CS) program. The contrast between CS and SE may surprise some readers, but the different needs are clear. In general, software engineers design and build things, whereas CS is more theoretical, leaning greatly on mathematics and physics. The content of a CS degree program might centre on discrete mathematics, algorithms and data structures, AI and robotics, numeric and symbolic languages, operating systems, compilers and programming languages (see, for example Ref. [4]). The contrast between computer science and IS is even more marked. Whereas, the issues for the computer scientist concern the computer system, the issues in ISs concern more on the computer system's impact on organizations, individuals and society.
emerging, such as the UK Academy of Information Systems (UKAIS) and the Association of Information Systems (AIS). The AIS is an international association of academics, divided into regional groups, and supports conferences and other activities. The UKAIS has some, albeit few, practitioners as members and is mainly a support group for IS academics in the UK. It holds an annual conference and PhD consortium. There is also UK heads and professors of IS group which acts as a pressure group. There is a similar group of computer science academics, which represents SE interests. Australia has a separate conference (somewhat like the independent International Conference in Information Systems (ICIS) before that became part of AIS activities).
4.3. Professional associations
Although we see distinctions and demarcation between SE and IS, both roles are vital to the successful development of an IS. There are aspects of both roles that are required at the same time during the ISs development life cycle, such as during the requirements de®nition and design stages. The project team needs to be formed at the beginning of the project and IS analysts and SE engineers should meet regularly as part of their job speci®cation. Just like the architect and civil engineer, they should be aware of each other's role during the process and be able to communicate their requirements. The requirement for quality in quick time means that it is important that roles are well speci®ed and understood, and that communication problems are eased.
We see the requirement for separate professional associations for systems engineers and systems analysts in the same way as those representing architects and construction engineers (and accountants, doctors and lawyers). In the United States, the IEEE and the ACM would seem to be most relevant to SE and IS respectively, though the latter does have very strong links with SE and computing in general. In the UK, the British Computer Society (BCS), along with the IEE, has associated itself with engineering and is now well placed to represent software engineers (see the piece by Trevor Burridge in Ref. [5]). In doing so, however, it seems to have decided not to represent IS. For example, IS-quali®ed people are unlikely to gain Chartered Engineer status through membership of the BCS, whereas SE-quali®ed people are very likely to achieve this status. It is, perhaps, odd that the BCS sees itself as the Society for Information Systems Engineers. Alternative groups such as the Data Processing Management Association and the UKAIS (see below) have been set up to ®ll the void left by the BCS. It may lead to improved practice if the professional associations representing each group became stronger. Belonging to a professional association should be an indicator of professional competence and strong ethical values. Both professions should be guided by a code of ethics as well as a code of good practice. For example, the IEEE in association with the ACM has a code of ethics for software engineers [6]. Failure to comply with this leads to loss of membership and a likely lawsuit from the user. Probably the Texas Board of Professional Engineers comes closest to this way of thinking. In June 1998, it established SE as a recognized engineering discipline and established licensing criteria for software engineers [5]. It is illegal to practice SE without a license or appropriate exemption in Texas. 4.4. Academic associations In the same way, we see separate academic associations
4.5. Teamwork in development projects
4.6. Skills and traits We agree with Teague [7] and Dahlbom and Matthiassen [8] who distinguish between those skills that focus on machines and modelling and those that focus on people and organizations. Software engineers have what they call the mechanist trait of the former, whereas systems analysts have what they refer to as a romantic trait. One represents the role of the engineer, interested in building artefacts, with the other interested in helping people and intervening in organizations. Neither is `good' nor `bad' and both are required in ISs development. Without this combination, we may get good technical systems or good social systems, but to be effective we need good socio-technical systems. We see future ISs analysts as being good communicators, perhaps extrovert, with good communication skills, whereas future software engineers will have good technical skills and be good at problem solving. 4.7. Research approaches The research approaches of both are likely to be mainly empirical Ð they are both applied disciplines Ð but the methods somewhat different. Qualitative approaches, such as action research, ethnography and case studies, are likely to be the mainstay of the IS researcher (see Ref. [9]) along
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
with questionnaire/surveys, whereas the SE researcher will tend to use problem solving approaches, perhaps quantitative, as he/she wishes to ®nd the most ef®cient solution to the problem at hand. 4.8. The position of programming We see the work of the programmer/coder as paralleling that of the builder in construction. It is an important skill that requires training in programming languages and the design, coding and testing of programs.
799
as curricula and research approaches, it is important that trainees and professionals in each are aware of the issues of the other. In this paper we have presented an opinion piece concerning SE and ISs using the analogy of the construction industry to guide the discussion. Analogies can be taken too far, and there are other analogies (the ®lm industry springs to mind) and other opinions. We have stretched the argument to engender debate. We hope that this paper will lead to a more constructive debate about the disciplines and practices of SE and ISs.
5. Conclusions In this short opinion paper, we have drawn the parallel between building construction and software construction and suggest that there are many important similarities. Just as there are marked differences between the architect and civil engineer, in terms of role, skills, quali®cations, etc., there needs to be differences between the systems analyst and software engineer. Both are essential to the successful completion of an IT project, but they are different. We use this analogy to draw implications with regard to the disciplines of ISs and SE. We see SE as an engineering discipline, with links to the sciences, and IS as a social science with links to other management disciplines. We see their respective curricula to be very different, but each needs to refer to the issues of the other discipline. We argue that both require professional training and draw on different skills and traits. However, we also see counter arguments that should be addressed. First, the separation of SE and ISs in terms of disciplinary groups and curricula should not be seen as a competitive strategy. Indeed, we can only be successful in building software systems if systems analysts and software engineers, as architects and civil engineers, communicate and cooperate and act as teams of experts. In this case, the whole will indeed be greater than the sum of the parts. Second, there is a danger that professional associations protect members to the exclusion of users and society at large. The respective associations' codes of ethics and codes of good conduct need to be backed up by strong regulative force. Finally, although we have argued that each discipline requires different skills and traits as well
Acknowledgements We are grateful for the reactions to our views presented at the meeting of the Software Engineering and Information Systems Network (SEISN) at Imperial College, London in September 1999. The web site for the group is http:// www.seisn.reading.ac.uk. We also thank colleagues at UTS: Bruce Campbell, Chris Johnson, Kewan McDonald and Gordana Culjak in particular.
References [1] C. Edwards, J. Ward, A. Bytheway, The Essence of Information Systems, Prentice-Hall, Chichester, 1991. [2] J. Dobson, M. Martin, M. Bonatti, M. Morganti, Architectural Discourse for Information Systems, Proceedings of the 4th UKAIS conference, McGraw-Hill, Maidenhead, 1999. [3] D.L. Parnas, Software engineering programs are not computer science programs, IEEE Software (1999). [4] H.M. Walker, G.M. Schneider, A revised model curriculum for a liberal arts degree in computer science, Communications of the ACM 39 (1996) 12. [5] J.R. Speed, What do you mean I can't call myself a software engineer?, IEEE Software (1999). [6] D. Gotterbarn, How the new software engineering code of ethics affects you, IEEE Software (1999). [7] J. Teague, Personality type, career performance and implications for computer science recruitment and teaching, Proceedings of the Third Australasian Conference on Computer Science Education, 1998, pp. 155±163. [8] B. Dahlbom, L. Matthiassen, The future of our profession, Communications of the ACM 40 (1997) 6. [9] M. Myers, D.E. Avison (Eds.), Qualitative Research in Information Systems: A Reader Sage, London, 2002.
www.elsevier.com/locate/infsof
Short Communication
A viewpoint on software engineering and information systems: what we can learn from the construction industry? David Avison a,*, David Wilson b a
Department of Systems d' Information et de Decision, ESSEC Business School, Avenue Bernard Hirsch-BP 105, 95021 Cergy-Pontoise cedex, France b University of Technology, Sydney, Australia Received 16 June 2001; revised 21 August 2001; accepted 23 August 2001
Software engineering seeks to improve our understanding of software systems; whereas information systems look at their impact on individuals, organizations and society. There are many common interests. We share some methodologies, techniques, tools, and even research methods. We are frequently researching and practicing in the same areas. Yet, we are not sharing experiences. Software engineering (SE) is seen as `teckie' by information systems (IS) analysts; and IS seen as `wishy-washy' by software engineers. Further, to some extent at least, each seems to be attempting to take over each other's territory and become `all things to all men'. We are in midst of a power struggle, which is wasteful and unproductive. Even worse, practitioners too often see both disciplines as irrelevant to the `real world' and SE and IS analysts are often seen as unprofessional and associated with failure. As well as being `messy' and unfortunate at best, this does not make any practical sense. We wish to engender debate to improve this situation. We see both SE and IS improving as disciplines and practices by clearer de®nition and separation of activities. In this article, we look at the construction industry as a possible analogy to engender debate. We use this model to provide guidance which might lead to a more positive spirit of genuine co-operation between software engineers and IS analysts, inspire more con®dence to users and organizations, and yet distinguish clearly the roles of each, both in computer applications development in practice and in their curricula and status in higher education. 1. The building analogy We can use the `building analogy' to illustrate and explain the IS development life cycle, indeed the latter is similar to the `achievement of large and complex projects in other areas of endeavor' [1]. The problems are similar: the * Corresponding author. Tel.: 133-1344-33195; fax: 133-1344-33001. E-mail address: [email protected] (D. Avison).
decomposition of complex activities, estimating costs and schedules and the management of multi-disciplinary teams. However, to help understand the analogy, the reader is asked to consider a building to be a one-off, architectdesigned, development, as it normally is in France, for example, not one of a number of very similar houses, typical as found in an English housing estate. The building analogy provides a useful illustration of the complex process and we will provide an example that most of us can easily visualize: 1. A person has bought a plot of land and wants to build a new house. The buyer approaches an architect and sketches out his/her basic requirements for the new house: three bedrooms, modern kitchen, home of®ce and double garage. The architect then prompts the buyer with questions in order to develop these requirements into suf®cient detail for a house plan to be drafted. The architect uses his/her knowledge of modern design to ask questions such as: Do you want an en suite bathroom? Do you want the garage to be integral to the house? Do you want a brick house? Do you want a wood frame? This information is suf®cient to draw up a draft plan for comment. Changes will be incorporated and the plans signed off. 2. The plans are then submitted to a construction manager/ planner or civil engineer who develops detailed design speci®cations from the plans. The construction planner uses his/her knowledge of building regulations and of building material properties to develop the speci®cations. During this process, the construction planner identi®es problems (where the plans cannot be physically implemented) and options (where the plan can be implemented in a variety of ways) and these are referred to the buyer for resolution. Finally, the construction planner draws up the speci®cations and sends them to the buyer for approval. The buyer may ask questions and demand further changes, for example, differently coloured tiles
0950-5849/01/$ - see front matter q 2001 Elsevier Science B.V. All rights reserved. PII: S 0950-584 9(01)00186-0
796
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
The plans and speci®cations relate to ISs development documents as follows:
Table 1 Development cycle and levels of discourse Step
Description
Level of discourse
1
Requirements de®nition
Level 5: articulating the problem Level 4: structuring the problem
2
Design
Level 3: establishing structure (or model) for solutions Level 2: exploring and evaluating options
3
Construction (program development)
Level 1: assigning referents to solution
or a serving hatch between kitchen and dining room. The changes are made and the speci®cations signed off. 3. The speci®cations are then submitted to a builder to build the house using his/her knowledge of construction techniques (and possibly those of sub-contractors). The builder may identify problems during the process (for example, particular materials not being available) and options, and again these are referred to the buyer for resolution. Finally, the builder completes the house and the buyer inspects the ®nished product. The buyer may ask for remedial work to be carried out to meet the speci®cation, for example, one of the doors may not close properly or the kitchen cabinets not being as speci®ed. The remedial work is carried out and the contract signed off. 4. The buyer moves into the house, which meets his/her requirements.
2. The analogy applied to IS and SE The analogy is useful in illustrating and explaining the ISs development life cycle and the roles of people in it. The house represents the IS and the roles as follows: ² the house buyer (user); ² the architect (systems analyst); ² the construction manager/planner or civil engineer (software engineer); ² the builder (programmer/coder).
² basic requirements (concept proposal); ² plans (requirements de®nition); ² speci®cations (design speci®cation). We can explain the need for these steps in developing solutions to requirements through the ®ve levels of discourse shown in Table 1 [2]. This also relates the steps to the levels of discourse and suggests that different skills are needed for the different steps. Step 1, we will argue, is the role of the systems analysts; step 2, that of software engineers, and step 3, that of programmers/coders. Of course, the above descriptions of systems development for buildings, software and ISs are rather simplistic. Development follows a much more iterative and spiral model, there is fuzziness and overlap, but this does not alter their similarity in many aspects. However, there are important differences in training, professionalism and roles of software engineers and ISs analysts. These are at least part implied through developing the analogy. To re¯ect the different skills required at each step, the construction industry not only de®nes separate roles (architect, construction manager/planner, civil engineer, builder) but also de®nes a separate body of knowledge for each and requires quite distinct training and education to attain distinct professional quali®cations. These differ in detail according to country but in principle: ² An aspiring architect must enrol on a degree in architecture and on graduation join a recognized profession with its own professional society. ² An aspiring construction manager/planner must enrol on a degree in building and on graduation join a recognized profession with its own professional society. ² An aspiring civil engineer must enrol on a degree in engineering and on graduation join a recognized profession with its own professional society. ² An aspiring builder must enrol for a trade quali®cation and gain speci®c training and education focused on the builder's role in the development cycle. In addition, the construction industry recognizes other
Fig. 1. Building development.
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
797
Fig. 2. Information systems development.
specialist roles, such as project managers and quantity surveyors, and there are training programs for them as well. The relationships between these different roles within the development life cycle are shown in Fig. 1.
systems analysis draw more on sociology, psychology, economics and other management disciplines it is likely to be situated in a management or social science faculty. We see IS and SE, therefore, as separate disciplines associated with separate disciplinary groups.
3. Emerging computing disciplines
4.2. Curricula
The construction industry provides an interesting contrast to that of the IT industry. Separate roles are suggested and sometimes de®ned, but there is often confusion. Many future software engineers and systems analysts graduate from similar generic degrees in computing or management, many others do not have a related quali®cation at all. The industry neither recognizes distinct bodies of knowledge nor distinct quali®cations for the different roles. We argue that SE and systems analysis require different types of people, having different skills, different backgrounds, different quali®cations and belonging to different professional organizations and, perhaps, having different personality traits. Fig. 2 shows a similar model of IS development as the building life cycle of Fig. 1. Although it shows the involvement of both system engineers and system analysts in some parts of requirement de®nitions and design, these are the different aspects of the overall process. This leads to the requirement for good communications between the software engineer and system analyst.
We suggest separate degrees and curricula for ISs and SE programs. SE might include:
4. Implications
² ² ² ² ² ² ² ² ² ² ² ² ²
We draw out a number of implications inspired from this comparison of ISs development and building construction. 4.1. Disciplinary groups We see the separation of SE and systems analysis into distinct departments or groups within universities. SE is likely to be in an engineering faculty and ISs and system analysis in a management faculty. SE can draw on the other disciplines likely to be situated in the engineering faculty and is related to other engineering disciplines in spirit [3]. Parnas argues this is not to do with questions of ownership, but those relating to content and style of education. SE may also draw on disciplines in a science faculty, for example, computer science, physics and mathematics. As ISs and
² ² ² ² ² ² ² ² ² ² ² ² ² ² ²
requirements analysis; software architecture; design; testing and quality assurance; software management; project management; selection and use of software tools and components; human±computer interface; maintenance; communications skills; documentation; architecture; database and information retrieval; programming languages; introduction to ISs issues. ISs courses might include: systems thinking; IS and the organization; IT/IS strategy; requirements analysis; systems analysis techniques; ISs methodologies; communications skills; human±computer interaction; project management; change management; knowledge management; e-business; introduction to SE issues.
We make three observations from these outline curricula. First is the importance of a course unit that looks at the other discipline, thus enabling cross-understanding and
798
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
supporting good communications between the two. The second observation concerns the otherwise sparsely shared subject matter. The third is that neither program looks like a computer science (CS) program. The contrast between CS and SE may surprise some readers, but the different needs are clear. In general, software engineers design and build things, whereas CS is more theoretical, leaning greatly on mathematics and physics. The content of a CS degree program might centre on discrete mathematics, algorithms and data structures, AI and robotics, numeric and symbolic languages, operating systems, compilers and programming languages (see, for example Ref. [4]). The contrast between computer science and IS is even more marked. Whereas, the issues for the computer scientist concern the computer system, the issues in ISs concern more on the computer system's impact on organizations, individuals and society.
emerging, such as the UK Academy of Information Systems (UKAIS) and the Association of Information Systems (AIS). The AIS is an international association of academics, divided into regional groups, and supports conferences and other activities. The UKAIS has some, albeit few, practitioners as members and is mainly a support group for IS academics in the UK. It holds an annual conference and PhD consortium. There is also UK heads and professors of IS group which acts as a pressure group. There is a similar group of computer science academics, which represents SE interests. Australia has a separate conference (somewhat like the independent International Conference in Information Systems (ICIS) before that became part of AIS activities).
4.3. Professional associations
Although we see distinctions and demarcation between SE and IS, both roles are vital to the successful development of an IS. There are aspects of both roles that are required at the same time during the ISs development life cycle, such as during the requirements de®nition and design stages. The project team needs to be formed at the beginning of the project and IS analysts and SE engineers should meet regularly as part of their job speci®cation. Just like the architect and civil engineer, they should be aware of each other's role during the process and be able to communicate their requirements. The requirement for quality in quick time means that it is important that roles are well speci®ed and understood, and that communication problems are eased.
We see the requirement for separate professional associations for systems engineers and systems analysts in the same way as those representing architects and construction engineers (and accountants, doctors and lawyers). In the United States, the IEEE and the ACM would seem to be most relevant to SE and IS respectively, though the latter does have very strong links with SE and computing in general. In the UK, the British Computer Society (BCS), along with the IEE, has associated itself with engineering and is now well placed to represent software engineers (see the piece by Trevor Burridge in Ref. [5]). In doing so, however, it seems to have decided not to represent IS. For example, IS-quali®ed people are unlikely to gain Chartered Engineer status through membership of the BCS, whereas SE-quali®ed people are very likely to achieve this status. It is, perhaps, odd that the BCS sees itself as the Society for Information Systems Engineers. Alternative groups such as the Data Processing Management Association and the UKAIS (see below) have been set up to ®ll the void left by the BCS. It may lead to improved practice if the professional associations representing each group became stronger. Belonging to a professional association should be an indicator of professional competence and strong ethical values. Both professions should be guided by a code of ethics as well as a code of good practice. For example, the IEEE in association with the ACM has a code of ethics for software engineers [6]. Failure to comply with this leads to loss of membership and a likely lawsuit from the user. Probably the Texas Board of Professional Engineers comes closest to this way of thinking. In June 1998, it established SE as a recognized engineering discipline and established licensing criteria for software engineers [5]. It is illegal to practice SE without a license or appropriate exemption in Texas. 4.4. Academic associations In the same way, we see separate academic associations
4.5. Teamwork in development projects
4.6. Skills and traits We agree with Teague [7] and Dahlbom and Matthiassen [8] who distinguish between those skills that focus on machines and modelling and those that focus on people and organizations. Software engineers have what they call the mechanist trait of the former, whereas systems analysts have what they refer to as a romantic trait. One represents the role of the engineer, interested in building artefacts, with the other interested in helping people and intervening in organizations. Neither is `good' nor `bad' and both are required in ISs development. Without this combination, we may get good technical systems or good social systems, but to be effective we need good socio-technical systems. We see future ISs analysts as being good communicators, perhaps extrovert, with good communication skills, whereas future software engineers will have good technical skills and be good at problem solving. 4.7. Research approaches The research approaches of both are likely to be mainly empirical Ð they are both applied disciplines Ð but the methods somewhat different. Qualitative approaches, such as action research, ethnography and case studies, are likely to be the mainstay of the IS researcher (see Ref. [9]) along
D. Avison, D. Wilson / Information and Software Technology 43 (2001) 795±799
with questionnaire/surveys, whereas the SE researcher will tend to use problem solving approaches, perhaps quantitative, as he/she wishes to ®nd the most ef®cient solution to the problem at hand. 4.8. The position of programming We see the work of the programmer/coder as paralleling that of the builder in construction. It is an important skill that requires training in programming languages and the design, coding and testing of programs.
799
as curricula and research approaches, it is important that trainees and professionals in each are aware of the issues of the other. In this paper we have presented an opinion piece concerning SE and ISs using the analogy of the construction industry to guide the discussion. Analogies can be taken too far, and there are other analogies (the ®lm industry springs to mind) and other opinions. We have stretched the argument to engender debate. We hope that this paper will lead to a more constructive debate about the disciplines and practices of SE and ISs.
5. Conclusions In this short opinion paper, we have drawn the parallel between building construction and software construction and suggest that there are many important similarities. Just as there are marked differences between the architect and civil engineer, in terms of role, skills, quali®cations, etc., there needs to be differences between the systems analyst and software engineer. Both are essential to the successful completion of an IT project, but they are different. We use this analogy to draw implications with regard to the disciplines of ISs and SE. We see SE as an engineering discipline, with links to the sciences, and IS as a social science with links to other management disciplines. We see their respective curricula to be very different, but each needs to refer to the issues of the other discipline. We argue that both require professional training and draw on different skills and traits. However, we also see counter arguments that should be addressed. First, the separation of SE and ISs in terms of disciplinary groups and curricula should not be seen as a competitive strategy. Indeed, we can only be successful in building software systems if systems analysts and software engineers, as architects and civil engineers, communicate and cooperate and act as teams of experts. In this case, the whole will indeed be greater than the sum of the parts. Second, there is a danger that professional associations protect members to the exclusion of users and society at large. The respective associations' codes of ethics and codes of good conduct need to be backed up by strong regulative force. Finally, although we have argued that each discipline requires different skills and traits as well
Acknowledgements We are grateful for the reactions to our views presented at the meeting of the Software Engineering and Information Systems Network (SEISN) at Imperial College, London in September 1999. The web site for the group is http:// www.seisn.reading.ac.uk. We also thank colleagues at UTS: Bruce Campbell, Chris Johnson, Kewan McDonald and Gordana Culjak in particular.
References [1] C. Edwards, J. Ward, A. Bytheway, The Essence of Information Systems, Prentice-Hall, Chichester, 1991. [2] J. Dobson, M. Martin, M. Bonatti, M. Morganti, Architectural Discourse for Information Systems, Proceedings of the 4th UKAIS conference, McGraw-Hill, Maidenhead, 1999. [3] D.L. Parnas, Software engineering programs are not computer science programs, IEEE Software (1999). [4] H.M. Walker, G.M. Schneider, A revised model curriculum for a liberal arts degree in computer science, Communications of the ACM 39 (1996) 12. [5] J.R. Speed, What do you mean I can't call myself a software engineer?, IEEE Software (1999). [6] D. Gotterbarn, How the new software engineering code of ethics affects you, IEEE Software (1999). [7] J. Teague, Personality type, career performance and implications for computer science recruitment and teaching, Proceedings of the Third Australasian Conference on Computer Science Education, 1998, pp. 155±163. [8] B. Dahlbom, L. Matthiassen, The future of our profession, Communications of the ACM 40 (1997) 6. [9] M. Myers, D.E. Avison (Eds.), Qualitative Research in Information Systems: A Reader Sage, London, 2002.