nokobit 2004 siste

7/31/2019 Nokobit 2004 Siste

1/249

The 11th Norwegian Conference on InformationSystems

Stavanger, 29. November 1.December, 2004

Program Chair and Editor

Knut H. R. RollandNorwegian University of Science and Technology

Organizing Chair

Bjarte RavndalStavanger University College


2/249


3/249

Welcome to NOKOBIT 2004!

Welcome to NOKOBIT 2004!First of all, I would like to welcome you all to the 11th NorwegianConference on Information Systems (NOKOBIT 2004).

According to tradition, this years conference is a mixture of newcomers tothe IS field as well as more experienced IS researchers. For many,NOKOBIT thus serves as a first arena to explore the Norwegian IScommunity and to learn the tricks of the trade of IS research. In thisregard, it is important that NOKOBIT continues to be a relatively safe and

friendly arena, where the more experienced researchers take the role ofadvisors and mentors.

A quick browse through this years proceedings reveals papers focusing onsuch diverse issues as empirical software engineering, IT standards, ITand organizational change, and mobile informatics. Regarding researchmethods and approaches one finds a similar diversity, ranging fromtraditional positivist studies to interpretive case studies and highlyexperimental approaches. Obviously, one can always discuss whether thiswide range of different styles or genres of research is favourable. In a small

community such as Norway, would it not be better to concentrate on a fewissues and approaches to research? On the one hand, this diversity is goodbecause it means that the Norwegian IS community can relate to largercommunities in Scandinavia, Europe, and America. To some extent,diversity is also good for knowledge creation, since we often can get newideas from chatting with researchers specializing in other fields. On the otherhand, however, diversity can create problems related to communication andunderstanding. For example, it is not always easy for researchers usingqualitative approaches to understand and evaluate results from a study done

from a positivist point of view, and vice versa. I hope this, and many otherinteresting issues will be discussed during the conference, and that wetogether can cultivate a strong Norwegian IS community that has a voicealso beyond the borders of Norway.

A heartfelt thanks goes to Bjarte Ravndal who has done all the work inStavanger and to the reviewers who did all the hard work for selecting thebest papers to be published in the proceedings. This could not have beendone without you!


4/249

Welcome to NOKOBIT 2004!

4

And, last but not least, I would like to take the opportunity to wish you allboth a pleasant and interesting conference!

Knut H. Rolland, Program Chair


5/249

Reviewers

Reviewers

Jennifer Blechar

Bendik Bygstad

Torgeir Dingsyr

Gunnar Ellingsen

Arild Jansen

Tor J. Larsen

Carl Erik MoeJudith Molka-Danielsen

Glenn Munkvold

Petter Nielsen

Maung K. Sein

Ingjerd Skogseid

Thomas sterlie

Margunn Aanestad


6/249

Contents

Contents

NOKOBIT PANEL

Diskusjonspanel om forskningsprogram i offentlig sektor 8

PAPER SESSION 1: Alternative Approaches to IS Development

Paper 1: "A workshop-oriented approach for defining electronic process guides -A case study" by Dingsyr, Moe, Dyb and Conradi 10

Paper 2: "Skapende teater og utvikling av informasjonssystemer - Likheter ogforskjeller i prosess og produkt" by Omland and Seljeseth 26

Paper 3: "Developing e-Government Portals: From Life-Events through Genresto Requirements" by Haraldsen, Stray, Pivrinta and Sein 44

PAPER SESSION 2: Information Systems Innovation and Adaptation

Paper 1: "What is the relationship between software development processes andIT based business innovation? An exploratory study in Norway" by Bygstad,Fagerstrm and stensen

72

Paper 2: "The Role of Actual IS Utilization Level: Extending the Expecation-Confirmation Model of IS Continuance Intention" by Larsen and Sreb 93

PAPER SESSION 3: IS Research and Issues of Collaboration

Paper 1: "Collaborative Research Network: Case Study at Molde UniversityCollege" by Molka-Danielsen 108

Paper 2: "Mobile work - Mobile ICT Supporting Secondary Work" by Skattr,Hasvold, Berntzen, and Engvig 132


7/249

Contents

7

Paper 3: "ICT-related change in complex organisations: The role ofinfrastructural and regulatory constraints" by Aanestad and Boulus 150

PAPER SESSION 4: IT Infrastructures and Standards

Paper 1: "An empirical investigation of factors influencing success in broadbandimplementation" by Elevoll and Graumann 173

Paper 2: "Local actors bridging the broadband divides" by Skogseid 194

Paper 3: "The emergence of functional standards: Digital Rights Managementstandards in the mobile telecommunications industry" by Blechar210

PAPER SESSION 5: IT/IS Learning and Education

Paper 1: "IKT skaper bde variasjon og lring - De frste tanker fra et prosjektom elevers oppfatning av IKT som lringsverkty" by Godejord

229

Paper 2: "Empirical Software Engineering Education" by Jaccheri and sterlie 242


8/249

NOKOBIT PANEL

NOKOBIT Panel

Diskusjonspanel om forskningsprogram i offentlig sektor pNOKOBIT 2004

Forskningsrdet har igangsatt et prosjekt VIOS - Verdiskapende innovasjon i offentligsektor som tar sikte p mobilisere virksomheter i offentlig sektor til formulere oggjennomfre forskningsbaserte innovasjonsprosjekter og utviklingsoppgaver, i samarbeid

med forskere og andre virksomheter, offentlige og private.

Mlet med programmet er medverke til utvikle ein smartare og meir effektiv offentlegsektor, med betre kvalitet i tenestetilbodet og i forvaltninga. (s. 50, KRDs St.prp.nr. 1).

Begrunnelsen for et slikt program er blant annet:- Suksessfulle og robuste offentlige tjenester er avhengig av innovativ forskning

og en mer koordinert satsing p FoU- Det er behov for mle produktivitetsendringer for tjenester i det offentlige

En hper derfor at VIOS skal bidra til at de offentlige blir mer innovativt og kan fungere

som hjelpeapparat for fremme innovasjon i samfunnet. Videre m offentlig sektor girmulighet til utnytte kompetanse- og kunnskapsressursene, samt de mulighetene somligger i IKT-sttte for tjenesteproduksjon for tjenesteproduksjon.

Programmet er n forankret i forslaget til Statsbudsjett under Kommunal ogregionaldepartementet og Nrings- og handelsdepartementet. Mer om programmet phttp://www.program.forskningsradet.no/vios/nyheter/visnyhet.html?id=5

I diskusjonspanelet nsker vi drfte det foreliggende programforslaget og blant annethvilke typer prosjekter det kan vre aktuelt igangsette.Innleder vil vre Trond Knudsen, fra sekretariatet for programmet i Forskningsrdet. Andredeltagere er fra forskningsmiljene og forvaltningen.

Panelansvarlig er Arild Jansen, Avdeling for forvaltningsinformatikk, UiO.


9/249

Alternative Approaches to Information Systems Development

SESSION 1

Alternative Approaches to Information SystemsDevelopment

This track presents research concerning different alternative methods for the

development of information systems. Papers by Dingsyr et al. and Omland

& Seljeseth both discuss methods that focus more on informal techniques,

creativity and participation than traditional approaches. In the paper by

Haraldsen et al. a specific approach for the development of "new"

technologies like e-Government Portals is described.

Papers are presented in the following order:

1. "A workshop-oriented approach for defining electronic process guides

- A case study" by Dingsyr, Moe, Dyb and Conradi

2. "Skapende teater og utvikling av informasjonssystemer - Likheter og

forskjeller i prosess og produkt" by Omland and Seljeseth

3. "Developing e-Government Portals: From Life-Events through

Genres to Requirements" by Haraldsen, Stray, Pivrinta and Sein


10/249


11/249


11

Knowledge-work, like software development seems to be extremely difficult to supportwith enactment.A more practical approach to process work for companies, is to make such processdescriptions available as electronic process guides (EPGs) on the company Intranet. Ourrecommendation is that the developers should be involved in such processes, both towork as recommended and to contribute to the process models. Otherwise, there willeasily be a too large gap between the official process model and the actual process,leading to poor process conformance. This has happened in many organizations withelaborate quality systems, that are hardly respected by (or applicable for) the rank and file(Conradi & Dyb, 2001). A balance must therefore be found between discipline (obeyingformal routines) and creativity (Glass, 1995) (actual development with much

improvisation (Dyb, 2000)).This chapter reports on the experience with developing of an electronic process guide in aNorwegian medium-size company with rather strict requirements on their softwareprocesses. To increase process awareness by the developers, process workshops were runto collect experience that could lead to better process descriptions. This kind ofparticipatory design has a strong Scandinavian work and research tradition.The issue we would like to discuss in this chapter is our suggested method for organizingprocess workshops. Interesting questions are which organizing elements make a well-working process, and how the process can be designed to increase process guide usage inthe future. We will describe how this was done in an example company, and discussexperiences from using this method, compare it to other possible approaches, and

conclude with advice for organizing similar workshops.Now, we present electronic process guides in further detail and then describe importantissues in employee participation which we build on in designing process workshops. Therest of the chapter is organized as follows: we introduce the research method, describeour workshop-oriented method to define software processes, which we have used inseveral small and medium-sized software companies. We present a case study of resultsfrom conducting process workshops in a satellite software company. We discuss findingsfrom the case study in relation to existing theory, and finally conclude the chapter.

ELECTRONIC PROCESS GUIDESEffectively disseminating process knowledge to process participants is crucial in any

software process improvement effort. Process participants need effective guidance whenprocess conformance is important, when a process changes frequently, and when newpersonnel join a project.Traditionally, this has been the realm of large organizations, and the way of describingand communicating processes has focused on printed standards and handbooks. However,such handbooks are more often seen as dust collectors than software processimprovement facilitators, and especially so in small and medium-sized companies.For process guides to be useful, increasingly more software companies not only tailortheir process guides to the specific needs of the company, but also make them availableon the companys intranet. This way the traditional process handbook shifts from a bulky


12/249


12

pile of paper to a flexible on-line structure allowing easy access to all relevantinformation by means of an electronic process guide (Scott et al., 2002).A process guide can be seen as a structured, workflow-oriented, reference document for aparticular process, and exists to support participants in carrying out the intended process(Kellner et al., 1998). Whether in the form of a printed handbook or an electronic version,a process guide should include the following basic elements: Activities: descriptions of how things are done, including an overview of the

activities and details regarding each individual activity. Artifacts: details regarding the products created or modified by an activity, either as a

final or intermediate result of the activity or as a temporary result created by one of thesteps.

Roles: details regarding the roles and agents involved in performing the activities. Tools and Techniques: details regarding the tools and techniques used to support or

automate the performance of an activity.It can also include access to: Lessons learned and frequently asked questions for relevant topics. Access to informal resources such as human experts, discussion boards. Metrics tools for instant data collection and display. Project-level information, including task allocation, updated plans and personal time

sheets.This means that an electronic process guide becomes a low-key, effective and flexibleintegrator and access channel towards a company experience base.

A common way to describe processes is to describe process entry, tasks, verification andexit, where entry and exit are criteria needed to be fulfilled and the tasks describeactivities, roles, artifacts, tools and techniques. This is commonly referred to as theETVX model.Based on these elements, Kellner et al. (1998) have proposed a set of basic requirementsand design principles for EPGs. Most importantly, an EPG should provide all theinformation elements and relationships contained in a good paper-based process guide. Inaddition, it should capitalize on diagrams, tables, and narrative to provide an effectiveuser interface. Also, it should make extensive use of hyper-links to support flexiblenavigation and direct access to supporting information such as examples and templates.However, the potential of EPGs can only be realized when key capabilities are not only

adopted, but also infused across the organization. This is complicated by the fact thatthere is considerable scepticism among software developers to learn from and adhere toprescribed process models, which are often perceived as overly structured or implyingtoo much control (Conradi & Dyb, 2001). Therefore, we cannot expect such infusionof EPGs unless they are perceived as useful and easy to use in daily practice andconsistent with the existing values, past experience, and needs of the software developers(Davis, 1989; Venkatesh & Davis, 2000).

EMPLOYEE PARTICIPATION


13/249


13

Conradi and Dyb (2001) showed the importance of employee participation during thedevelopment and introduction of formal software routines and that such routines must besupplemented by collaborative, social processes to promote effective infusion andorganizational learning.This insight is not new. Employee participation and the way people are treated, has beennoted to be a crucial factor in organizational management and development ever since thefamous productivity studies at Western Electrics Hawthorne plant in the 1920s (Mayo,1933; Mayo, 1945). The results of these studies started a revolution in managementthinking, showing that even routine jobs can be improved if the workers are treated withrespect.Since then, participation and involvement has been one of the most important foundations

of organization development and change (Cummings & Worley, 2001; French & Bell,1999). Participation is also one of the fundamental ideas of Total Quality Management(Crosby, 1979; Deming, 2000; Juran, 1992). Similarly, participation has always been acentral goal and one of the pillars of organizational learning. For example, autonomouswork groups (Trist, 1981), quality circles (Ishikawa, 1990), survey feedback (Baumgartel,1959; Neff, 1966), quality of work life programs (Davis, 1977), search conferences(Emery & Purser, 1996), and cultural analysis (Denison & Spreitzer, 1991; Schein, 1992)are all predicated on the belief that increased participation will lead to better solutionsand enhanced organizational problem-solving capability.What can be learned from these prior studies is that people tend to support what theyhave participated in creating, or to use Berger and Luckmanns (Berger & Luckmann,

1966) words: it is more likely that one will deviate from programmes set up for one byothers than from programmes that one has helped establish oneself.An important aspect of participation is co-determination, i.e. the direct participation ofworkers in decisions about what should best be done at their own level. Within thecontext of software development, no one is more expert in the realities of a softwarecompanys business with respect to the day-to-day details of particular technologies,products, and markets than the software developers and their first-line managers are.Hence, it is important to involve all those who are part of the software process, and havedecisions made regarding the development of EPGs by those who are closest to theproblem.Consequently, and in order to get realistic descriptions with accurate detail as well as

company commitment in an efficient manner, we involve all relevant employee groups indefining processes by using process workshops as a tool to reach consensus on workpractice.

MethodThe research reported in this chapter is from a large industrial research project, SoftwareProcess Improvement through Knowledge and Experience (SPIKE), where manycompanies cooperate with research institutions and universities in improvement activities.The collaboration is based on finding common improvement and learning goals, andworking together to obtain the goals. The communication between contact persons in thecompanies and researchers (and data collection) is through meetings (minutes,


14/249


14

observation, and pictures), telephone calls, and e-mail communication. The researchersusually stay two-day visits in the participating companies in order to also get into theinformal arena in the company, and not just collaborate in official meetings.This research method is a form of action research (Greenwood & Levin, 1998), where theresearchers and participants from the companies had common goals: to improve softwaredevelopment, and learn from that experience. Together with the company, we discusshow improvement activities can be organized, and try it out in a cogenerative learningprocess. That the process is cogenerative means that both company insiders andresearcher outsiders are able to reflect on actions performed. A communication arena isestablished with regular meetings between researchers and people from the qualitydepartment in the company. In this case, the process workshops were a solution suggested

by researchers for a problem the quality department had: to improve documentation of thecore processes of the company. We organized feedback-sessions after performing theprocess workshops for cogenerative learning.Potential problems with this type of research are that it can easily be biased, in thateveryone is interested in reaching the goals that are set up. Thus, we do not know if thesame results would be achieved with another set of researchers, with other people fromthe company, or with another company in the same situation. But action research is a wayto get interaction with companies in a way that would not be possible if it was not somuch in the company's interest.The case company was selected because they were putting much effort in softwareprocess improvement, and was thus a candidate for participation in the SPIKE project.

Defining Processes in a Medium-Size Software CompanyWe first describe the company where we carried out research, and then present our workwith process workshops in this company.

A SATELLITE SOFTWARE COMPANYSince the company was founded in 1984, they have delivered turnkey ground stationsystems, consultancy, feasibility studies, system engineering, training, and support. Thecompany has been working with large development projects, both as a prime contractorand as a subcontractor.Customers range from universities to companies like Lockheed Martin and Alcatel to

governmental institutions like the European Space Agency and the NorwegianMeteorological Institute.Most of the software systems that are developed are running on Unix, many on the Linuxoperating system.The company possesses a stable and highly skilled staff, many with masters degrees incomputer science, mathematics or physics, and have what we can describe as anengineering culture. Approximately 60 people are working in the company, and themajority is working with software development. Projects are managed in accordance withquality routines fulfilling the European Space Agency PSS-05 standards and ISO 9001-2000.


15/249


15

The company had an extensive quality system, but the system was cumbersome to usebecause of the size and because it existed partly on file and partly on paper. As a part ofbeing certified according to ISO 9001-2000, the company decided to document all mainprocesses in the company. We worked with the company in defining the processes forsoftware development.

DEFINING REQUIREMENTS FOR AN EPGWe started out with an initial workshop. The goal of this workshop was to define thedifferent existing project types in the company, and to decide the format and mostimportant requirements for the process guide. The company defined four main projecttypes, and they chose the most common one as a starting point for the following

workshops. Product development was the most common project type, and the size of thisproject type was typically 1000-4000 work hours. Other project types was customercontrolled development projects, delivery projects (integration of existing components,and configuration), maintenance projects, and studies. Typical activities for productdevelopment projects were either customizing an existing product for a customer,developing a new system for a customer, or an internal project with a mixture of newdevelopment and integration of existing products. After the project types were definedand product development was chosen as a starting point, the most important requirementswere defined. The process guide should provide: Description of tasks for the most important roles in a project Checklists for each main process Templates for all documents produced Descriptions of best practice Access to all tools needed in the project (e.g. a requirement and a bug track system).In addition to these functional requirements a few non-functional requirements weredefined during the first workshop. The most important such requirements were that itshould be: easy accessible, as simple as possible, and up to date.

DISCUSSING PROCESSES: THE PROCESS WORKSHOPWe ran a total of six process workshops focusing on different parts of the developmentprocess. The workshops involved people from the market and quality department as wellas the development unit.In the first process workshop for product development, initiation was the one thecompany wanted to start with. The initiation process was defined to include offer,follow-up and blast off.We followed the same pattern for each workshop, which we describe below withexamples of output from the first workshop. See (Ahonen et al., 2002), for a discussion ofa similar group process technique.The workshops differed in length, but would usually last half a day. The researchers actedas moderators and secretaries. In addition to a meeting room, the workshop required acollection of stickers in different colors, and walls that were covered with paper, wherewe could attach stickers and draw figures. A digital camera was useful to document the


16/249


16

results of the workshop. We also found it useful to bring large process worksheets, basedon the ETVX model: a sheet with boxes for input, activities, output, roles and relateddocuments involved in the process (see Figure 2).We defined process(es) in six steps and five sub-steps as shown in Figure 1.As the initiation of projects is an interface between different parts of the organization, itwas important to bring together people from marketing, quality assurance and thedevelopment department. We started the workshop by giving a 15-minute presentation ofwhat we were going to do, and put a large sheet with a figure of the process worksheet (asin Figure 2) on the wall one for each process that would be discussed in the meeting.For each sub-process we wanted to define, offer, follow-up and blast-off, we wentthrough the sub steps:

Decide onprocess(es) to

define

Invite participants

Process workshop

Identify activities

Define sequence

Define input andoutput

Define roles

Find relateddocuments

Delegateresponsibility for

implementation

Role-basedreading of

resulting process

Implement theprocess in EPG

Figure 1: Steps to define a process in a workshop

Identified activities. We brainstormed on the main activities of the process by using theKJ process (Scupin, 1997) (after Japanese ethnologist Jiro Kawakita) and documented theresult. The KJ is a creative group technique to organize and find relations betweenseemingly unrelated ideas. We did this as follows: We gave each participant a set of yellow stickers and a thick pen. We asked them to

write suggestions for activities on each yellow sticker in large letters. People got timeto document 5-10 ideas.


17/249


17

We asked each participant to present her suggestions: attach each sticker on a wall, anddescribe the activity. No-one was allowed to criticize or discuss the ideas at this point. Grouped the suggestions: the participants came forward to the wall and organized the

yellow stickers into groups. We asked them to state why they chose to move thestickers.

Formulated headings: we found new suitable headers that described the stickers in eachgroup. The headings were formulated to make sense to people who have notparticipated in the workshop.

We documented the diagram on the wall with groups and supporting activities onstickers.

During this work, several interesting discussions came up, and several important

problems and misunderstandings were solved. Especially marketing and project managershad different views on initiation, but were able to agree on a common process during theworkshop.Because we wanted to get through three sub-processes in half a day, we used time boxingwhich limited discussion. However, we were able to produce an extensive material in thetime slot for each sub-process.The main activities identified in this step for the blast-off sub-process were: Appoint project manager Organize Handover meeting First project analysis Allocate resources Prepare for kick-off meeting Internal kick-off.Defined the sequence of the activities. We took the activities from the previous phase,made a sticker for each. Then, we placed them on the activities-field of the processworksheet, where time goes from left to the right. We found a suitable workflow betweenthe activities.Defined input and output. We found documents or artifacts that must be available to startthe sub-process, and which documents that mark the end of the sub-process. We usedstickers with other colors than for the activities to mark input and output, and attachedthem on the process worksheet on the wall together with the activities. Conditions thatmust be satisfied to begin or exit the sub-process can be described in checklists.


18/249


18

Figure 2: A process worksheet with input, activities, output, roles and relateddocuments defined.

Defined roles. We brainstormed on which roles should contribute in each activity andfound the following roles for the blast off phase: project manager, quality assurance,development responsible, technical responsible, product committee, bid manager,purchasing manager, logistics expert.Related documents. We identified documents that either already existed in the company,or new documents that would be helpful in carrying out the activities. Such documentswere templates, checklists and good examples of input or output documents.

The researchers documented the process workshop by taking notes of stickers in differentcategories, and by the use of pictures (as in Figure 3).


19/249


19

Figure 3: A workshop participant adds an activity to a process worksheet.

We found it helpful to ask the people who participated in the process workshop to readthe result and comment on it (see (Shull et al., 2000) for an example of such a techniquein requirements inspection). We assigned the most typical roles that were involved in theprocesses to people and asked them to find if there was information that was lacking orirrelevant for this role in the description. This reading resulted in a number ofmodifications and clarifications on the process description.Finally, two people in the company were responsible for making a draft process guide,based on the overall description of the processes which are developed in the workshop.Each activity was then described in much more detail than what appeared in theworkshop minutes the participants gave feedback on these before the processes wereimplemented in the process guide, as shown in Figure 4.


20/249


20

Figure 4: A screenshot of a part of the resulting electronic process guide onthe company Intranet.

FOLLOWING WORK

After the first version of initiation was accepted and implemented in the process guide,the company was ready for the next workshop. After initiation it was natural to focus onproduct development. This process was defined to include the sub-processes:specification, elaboration, component construction, and system integration. Alsofor these processes, input, activities, output, roles, and related documents involved in theprocess were defined.After the two main processes, product development and initiation were defined, thecompany was ready to release the first version of the process guide. The enthusiasm washigh after the workshops. It was therefore important to give the workshop participantsfeedback through a running system even if it was not complete. Waiting for the perfectand complete process guide would take too long and could kill the enthusiasm. While

implementing and releasing the process guide, the company conducted processworkshops on project closure, product release, delivery and competence registration.These seven first workshops had from 4-6 participants (researchers not included), and 20persons (1/3 of the employees) from the company participated in one or more workshops.The workshops lasted from 2 hours (workshop on format and requirements of the processguide) to 6.5 hours. The participants did not need to prepare themselves before theworkshops. The company used: 168 work hours for seven workshops 40 work hours on supplementary work after workshops 208 work hours for implementing the process guide 223 work hours for implementing project tracking tools in addition to the guide


21/249


21

38 work hours on documentation.The total cost of developing the first version of the process guide was 1049 work hours.The two researchers used 10 work hours each including preparation and supplementarywork for each workshop.

DiscussionIn this section, we would like to discuss our experience with conducting processworkshops, and elaborate on strengths and weaknesses of applying such an approach.We believe that participation and involvement is critical to achieve improvement in anyorganization, and see the process workshop as an arena which is open for many of theemployees to take part in. Further, we see the process workshops as an arena where

representatives from various departments can meet and discuss which will giveparticipants a broader view of how work is conducted in the organization. Finally, we seethe process workshop as an arena for collective reflection and learning, where employeescan share experience on how they usually solve tasks, and discuss efforts to help themsolve the tasks more efficiently.It is not the intention in this paper to prove that process workshops are more suitablethan other techniques in eliciting process descriptions. We do not yet have sufficientexperience with the resulting process descriptions to investigate that issue. We will ratherpoint out some elements that we noted when conducting the workshops which can beuseful for other approaches in the future. However, we note the findings of Ahonen et al.(2002), who report that a similar workshop-technique for modeling software processes

both increased the knowledge of the real process and identified points of improvement.First, we noted that the people who participated in the workshops were contributing withmany new perspectives on the processes. For example, one of the people in the qualitydepartment in the company had already made a draft version of a process descriptionbefore organizing a workshop. He found that the workshop produced a number ofactivities, roles, and also input and output-documents that he did not think of himself.The brainstorming sessions with yellow stickers worked well to get all participantsinvolved in the process. We have experienced that software developers often can be quiteintrovert people; and the workshops gave them the opportunity to participate moreactively in discussions. Using the stickers gives each participant approximately the sametime to present experience.

The workshop provided an arena for cross-functional discussion in the company, andthere were several discussions between for example the market and software developmentdepartments on how issues were to be handled. We think many clarifications were madethat would not have appeared if it had not been for these workshops.We were satisfied with using the simplified version of the ETVX process worksheets inthe brainstorming sessions. Using the worksheet gave an easily understandable visualpresentation of the results and the connection between different elements of the result.None of the participants in the workshops we organized said they found the ETVX sheetsinappropriate.During the sessions we used time boxing in order to generate ideas for all sub-processesand sub-process elements. Because of limited time, we had to stop some discussions to


22/249


22

move to the next process element. In an organizational learning sense, one could arguethat we should have had more space for free dialogue, which would elicit more of thetacit knowledge from the people involved. However, using time boxing generated aflow in the workshop. We had the impression that none of the participants got bored orstopped engaging in discussions because the topic was irrelevant, which might havehappened if we had allowed for more time.Another aspect that gave a lot of feedback on the results was the role-based reading of theresults of the workshop. Assigning roles to people was a good tool in discoveringinconsistencies, for example that a role was missing in one sub-process description or thata document relevant to a role appeared in one sub-process as output and not as input inanother sub-process later. It also gave us general feedback of the wording of the names of

roles, documents and activities.We claim that the workshops provided an arena for participation which was consistentwith existing values, past experience and also with the needs of the company employees.Further, the process workshops were fairly efficient in terms of resources spent to designthe process guide. We do not think using other approaches such as process expertsconducting interviews or purchasing existing canned processes would have come outcheaper for the company. Other approaches would also probably require more tailoring,and would not involve the employees to such a large degree. It would also put less focuson the learning aspects through reflection on own practice, which are evident in group-work.On the basis of the workshops conducted, we can recommend other companies wanting

to develop electronic process guides to organize a set of workshops using thebrainstorming techniques, the ETVX sheets and the role-based review.

Conclusion and Further WorkFrom the previous discussion of how process workshops worked in the case study of thesatellite software company we can conclude: Process workshops conducted in the way described provides an open forum for

reflection and learning about own work methods. Process workshops are an efficient method for discussing and agreeing on a set of work

processes.Further work in this area will be to follow the acceptance, usage and impact of this

process guide in the satellite company. We will study the usage of the process guide overtime using a modified version of the Technology Acceptance Model as well as studyingusage logs and performing qualitative semi-structured interviews. We intend to study therelation between involvement in process workshops and actual use of the process guideover time.

AcknowledgementsThis work was conducted as a part of the SPIKE research project, supported by theResearch Council of Norway. We are very grateful to our contact persons in the satellite


23/249


23

company for providing a stimulating environment in the project and to the participants inthe process workshops for a positive attitude towards new work methods.

BibliographyTorgeir Dingsyrwrote his doctoral thesis on Knowledge Management in Medium-Sized Software Consulting Companites at the software engineering group at theDepartment of Computer and Information Science, Norwegian University of Science andTechnology. He has published papers on knowledge management in softwareengineering, software process improvement, case-based reasoning and on softwareengineering education. In 2001, he spent half a year as a guest researcher at theFraunhofer Institute for Experimental Software Engineering in Kaiserslautern, Germany.

He is now employed at the Sintef ICT research foundation, working on software processimprovement projects.Nils Brede Moe is a research scientist at SINTEF ICT in Trondheim, Norway. He joinedthe department in 1998. He holds a M.Sc. degree in Informatics from the NorwegianUniversity of Science and Technology in 1998. He has published papers on healthinformatics (telemedicine and homecare), user-cantered design and process improvement.Tore Dyb received his M.Sc. degree in Computer Science and Telematics from theNorwegian Institute of Technology in 1986 and his Ph.D. degree in Computer Sciencefrom the Norwegian Univer-sity of Science and Technology in 2001. He has worked as aconsultant and a researcher both in Norway and in Saudi Arabia. His research interestsinclude empirical software engineering, software process improvement, knowledge

management, and organizational learning. Dr. Dyb is currently a senior scientist atSINTEF ICT and a visiting research scientist at Department of Software Engineering atthe SIMULA Research Laboratory.Reidar Conradi received his MS and his PhD in computer science from the NorwegianUniversity of Science and Technology in Trondheim (NTNU), and has been there since1975. He is now a professor at the Department of Computer and Information Science atNTNU. Conradi was a visiting scientist at Fraunhofer Center for Experimental SoftwareEngineering in Maryland and at Politecnico di Milano in 1999/2000. His interests areprocess modeling, software process improvement, knowledge and software engineeringdatabases, versioning, object-orientation, component-based development, andprogramming languages.

ReferencesAhonen, J. J., Forsell, M., & Taskinen, S.-K. (2002). A Modest but Practical SoftwareProcess Modeling Technique for Software Process Improvement. Software ProcessImprovement and Practice, 7(1), 33-44.Baumgartel, H. (1959). Using Employee Questionnaire Results for ImprovingOrganizations: The Survey 'Feedback' Experiment. Kansas Business Review, 12, 2-6.Becker-Kornstaedt, U., Neu, H., & Hirche, G. (2001). Software Process TechnologyTransfer: Using a Formal Process Notation to Capture a Software Process in Industry. In


24/249


24

V. Ambriola (Ed.), Proceedings from the Eight European Workshop on Software ProcessTechnology (EWSPT2001) (pp. 63-76): Springer LNCS 2077.Berger, P. L., & Luckmann, T. (1966). The Social Construction of Reality: A Treatise inthe Sociology of Knowledge. Harmondsworth: Penguin Books.Conradi, R., & Dyb, T. (2001). An Empirical Study on the Utility of Formal Routines toTransfer Knowledge and Experience. In V. Gruhn (Ed.), Proceedings of the EuropeanSoftware Engineering Conference 2001 (ESEC'2001) (pp. 268-276): ACM/IEEE CSPress.Crosby, P. B. (1979). Quality is Free: The Art of Making Quality Certain. New York:McGraw-Hill.

Cummings, T. G., & Worley, C. G. (2001). Organization Development and Change.Cincinnati, Ohio: South-Western College Publishing.Davis, F. (1989). Perceived Usefulness, Perceived Ease of Use, and User Acceptance ofInformation Technology. MIS Quarterly, 13(3), 318-339.Davis, L. (1977). Enhancing the Quality of Work Life: Developments in the UnitedStates. International Labour Review, 116 (July-August), 53-65.Deming, E. W. (2000). Out of the Crisis. Cambridge, Massachusetts: The MIT Press (firstpublished in 1982 by MIT Center for Advanced Educational Services).Denison, D., & Spreitzer, G. (1991). Organizational Culture and OrganizationalDevelopment: A Competing Values Approach. In R. Woodman & W. Posmore (Eds.),Research in Organizational Change and Development (Vol. 5, pp. 1-22.). Greenwich,Connecticut: JAI Press.Derniame, J.-C., Kaba, B. A., & Wastell, D. (1999). Software Process: Principles,Methodology, and Technology. Springer Verlag LNCS 1500.

Dyb, T. (2000). Improvisation in Small Software Organizations. IEEE Software, 17(September/October), 82-87.Emery, M., & Purser, R. E. (1996). The Search Conference. San Francisco: Jossey-Bass.French, W. L., & Bell, C. H. J. (1999). Organization Development: Behavioral ScienceInterventions for Organization Improvement. Upper Saddle River, New Jersey: Prentice-Hall.Glass, R. L. (1995). Software Creativity. Prentice Hall.

Greenwood, D. J., & Levin, M. (1998). Introduction to Action Research. SagePublications.Ishikawa, K. (1990). Introduction to Quality Control. London: Chapman & Hall.Juran, J. M. (1992). Juran on Quality by Design: The New Steps for Planning Quality intoGoods and Services. New York: Free Press.Kellner, M. I., Becker-Kornstaedt, U., Riddle, W. E., Tomal, J., & Verlag, M. (1998).Process Guides: Effective Guidance for Process Participants. Proceedings of the 5thInternational Conference on the Software Process: Computer Supported OrganizationalWork, Lisle, Illinois, USA.


25/249


25

Lehman, M. M., & Belady, L. A. (1985). Program Evolution - Processes of SoftwareChange. Academic Press.Mayo, E. (1933). The Human Problems of an Industrial Civilization. Boston: HarvardUniversity Press.Mayo, E. (1945). The Social Problems of an Industrial Civilization. Boston: HarvardUniversity Press.

National Institute of Standards and Technology. (1993). The Standard for IntegrationDefinition for Function Modelling (IDEF0).Neff, F. W. (1966). Survey Research: A Tool for Problem Diagnosis and Improvement inOrganizations. In A. W. Gouldner & S. M. Miller (Eds.), Applied Sociology (pp. 23-38).

New York: Free Press.Oquendo, F. (2003). Software Process Technology. Proceedings of the NinthInternational Workshop, EWSPT2003, Helsinki, Finland.Schein, E. H. (1992). Organizational Culture and Leadership. San Francisco: Jossey-Bass.Scott, L., Carvalho, L., Jeffery, R., DAmbra, J., & Becker-Koernstaedt, U. (2002).Understanding the Use of an Electronic Process Guide. Information and SoftwareTechnology, 44, 601-616.Scupin, R. (1997). The KJ Method: A Technique for Analyzing Data Derived fromJapanese Ethnology. Human Organization, 56(2), 233-237.

Shull, F., Rus, I., & Basili, V. R. (2000). How Perspective-Based Reading Can ImproveRequirements Inspections. IEEE Computer, 33(7), 73-79.Trist, E. (1981). The Evolution of Socio-Technical Systems: A Conceptual Frameworkand an Action Research Program. Toronto, Ontario: Ontario Quality of Working LifeCenter.Venkatesh, V., & Davis, F. (2000). A Theoretical Extension of the TechnologyAcceptance Model: Four Longitudinal Field Studies. Management Science, 46(2), 186-204.


26/249


26

Skapende teater og utvikling av informasjonssystemerLikheter og forskjeller i prosess og produkt

Hans Olav OmlandJorunn SeljesethHgskolen i Agder

Serviceboks 422, 4604 KristiansandEmail: [email protected], [email protected]

SammendragSkapende teater og systemutvikling kan synes som svrt forskjellige fagomrder.

Produktene fra de to prosessene henvender seg til forskjellige brukergrupper og kan

tilsynelatende ha forskjellig hensikt og bruk. Likevel er det to begreper som finnes i

begge fagomrdene, nemlig prosess og produkt. I denne artikkelen sammenligner vi bde

prosessene som brukes og produktene som utvikles innen de nevnte fagomrdene. Vi

forsker f tak p grunnleggende temaer som ligger under prosessene for

sammenligne dem. Vi finner mange likheter med det som foregr i utviklingen av

produktene. Produktene, en teateropptreden og et informasjonssystem kan umiddelbart

synes svrt forskjellige. Vr diskusjon viser at det ogs her er mange likheter.

Konklusjonene i denne artikkelen kan vre nyttige i utdanning av studenter innen begge

fagomrdene og at fagomrdene kan bde lre av hverandre og samarbeide for gjre

utdanningen bedre.

InnledningBde innen skapende teater og utvikling av informasjonssystemer (IS-systemer) foregrdet en prosess som leder til et produkt. Selv om skapende teater og utvikling av IS-systemer kan virke veldig forskjellig p overflaten brukes begrepene produkt og prosess


27/249


27

innen begge fagmiljene. Denne tilsynelatende store forskjellen mellom de to fagfeltenekoblet med bruk av de samme grunnleggende begreper gjr at vi mener det er interessant se p hva som legges i begrepene og f fram likheter og forskjeller i dem innen de tofagfeltene. En slik klargjring vil kunne ha betydning for fagfeltene generelt. I denneartikkelen vil vi anvende resultatene fra den generelle sammenligningen i enundervisnings/lringssituasjon. Vi mener at en slik sammenligning vil bevisstgjre osssom undervisere og derigjennom kan vi lage et bedre undervisningsmilj for studenteneinnen de to fagomrdene. I utdanning av studenter er det viktig f fram disse toelementene og forskjellene p dem.Vi tar utgangspunkt i flgende problemstilling:

Hva kan undervisningsmiljene innen skapende teater og utvikling avinformasjonssystemer lre av hverandre i utforming av bde prosess og produkt?

Vi sker svar p problemstillingen ved starte med en generell diskusjon ogsammenligning av prosess og produkt innen de to fagfeltene. Deretter diskuterer vikonsekvensene for oppbygging av lringsmiljene innen de to fagfeltene. Artikkelenfortsetter med en litteraturgjennomgang. Deretter sammenligner vi utviklingsprosesseneog produktene for skapende teater og systemutvikling. S flger et kapittel der vidiskuterer likheter og forskjeller mellom prosessene og produktene. Vi vil ogs diskuteremulige konsekvenser for lringsmiljet i de to fagene. Artikkelen avsluttes med enkonklusjon.

LitteraturgjennomgangDramafagomrdet har hatt en utvikling hvor en kan se vektleggingen p prosess ogprodukt som et gjennomgende tema. Pendelen har svingt fra produktets viktighet ogbetydning uten tanke p prosess til total vektleggingen av prosess hvor produkt erutelukket.

Faget har to grunnpilarer: Skoleteatertradisjonen og reformpedagogikken. Braanaas(1999) skriver at skoleteatertradisjonen vektlegger produktet mens reformpedagogikkenvektlegger prosesstanken og utviklingen av naturlige og medfdte uttrykksevner.Slade (1954) og Way (1967) vektlegger prosessen. Heatcote og Bolton (1994) utarbeidet

en metode for lre som blir kalt prosessdrama hvor vektleggingen er drama sommetode for lre andre fag eller mellommenneskelige forhold. Hovedintensjonen meddenne metoden er lre av vre i prosess, og produkt er utelukket. Szatkowski (1991)skriver om teaterprven som modell for dramafaget. Dette var et av anslagene i retning av utvikle betydningen av produkt i faget. Han viser til Ross (1978) sin modell forskapende arbeid p teateromrdet. Ross konkretiserer den generelle modellen for allskapende virksomhet. Han hevder at det estetiske innebrer en egen erkjennelsesform.For Ross er skapende virksomhet og lek p det nrmeste knyttet sammen. For kunneutvikle den kreative prosess m disse forutsetningene vre tilstede:Teatergruppens impuls til en forestilling bearbeides som flger for til slutt bli etteaterprodukt:


28/249


28

sanser (materiale til ideer: observasjon, lytting, fornemme bevegelser) uttrykksmidlene (kropp, stemme, teaterkonvensjonene) hndverk (ferdigheter, teknikker, teatertekst, scenografi, rombevissthet, lys) bildedannelse og fantasi (assosiasjoner, kontraster)

Pendelen har de siste rene klart svingt i retning av se p prosess og produkt somlikeverdige og med klare rtter i teaterkunsten. Vektleggingen gr i retning av kunneutvikle evne til uttrykke seg gjennom form. Samtidig fr prosessen og produktet storbetydning som erkjennelsesform.

Det er mange forskjellige systemutviklingsmetoder tilgjengelig i dag og de differ

greatly, often addressing different objectives (Avison og Fitzgerald 1988). Det er ogsmange implisitte og eksplisitte antagelser og perspektiv bak hver metode (Iivari andHirschheim 1996). Metoder har mange komponenter som spesifiserer: faser i et prosjekt,oppgaver som skal utfres, resultater fra prosjektet, begrensninger som foreligger, hvemskal vre involvert, verkty som skal brukes og hvordan man skal lede og kontrollereprosjekter (Avison og Fitzgerald 1995). Metoder blir laget for gjresystemutviklingsprosessen enklere og mer kontrollerbar. I noen r har det vrt enbevissthet om at metoder ikke lser alle problemer i utvikling av informasjonssystemer.Huisman og Iivari (2002) skriver at den utstrakte tro p at bruk av utviklingsmetoder Isystemutvikling fremdeles er kontroversiell. Nyere underskelser rapporterer at mangeorganisasjoner sier at de enten ikke bruker metoder eller at de bruker deres egen in-

house metode (Huisman og Iivari 2002; Kiely og Fitzgerald 2003).

Metoder kan ha mange forskjellige funksjoner fra det tekniske gjre det enklere kontrollere prosessen til den mer politiske siden hvor metoden kan fungere som ritualer(Robey og Markus 1984). Metoder m bli forsttt og brukt forskjellig avhengig avkonteksten og den aktuelle utvikler. rvik el al. (1999) beskriver fire forskjelligeforstelser av den samme utviklingsmetode relatert til en aktuell utvikling. Den frste eren formell beskrivelse av systemet. De tre andre oppstr alle i den aktuelleutviklingsprosessen; nemlig det utvikleren tolker, metoden forsttt av utvikleren; hvordanmetoden blir brukt i organisasjonen, the adopted method; og hvordan den faktiskbrukes, metoden i bruk. Iflge rvik et al. (1999) vil disse forskjellige forstelsene av

metoden influere bruken av den.

En del av metodelitteraturens beskriver prosessene i utvikling av informasjonssystemersom mer eller mindre mekaniske prosesser som frer til gitte resultater. Ciborra (1999)tar ett oppgjr med Business Process Re-engineering og dets forsk p utryddeimprovisasjon fra konomiske organisasjoner. Han mener at improvisasjon er a wellgrounded process that can be leveraged to face those situations where rules and methodsfail. Systemutvikling er p mange mter forandring. Forandring i organisasjonen kanvre mer eller mindre planlagt, og er langt mer vanlig i dag enn tidligere (Orlikowski1996). Dersom systemutviklingsmetoder brukes uten tanke p forandring vil viktigeelementer i systemutviklingen g tapt. Orlikowski (1996) beskriver sm forandringer,


29/249


29

som improvisasjoner relatert til ny teknologi kan fre til store forandringer iorganisasjonen. Mathiassen et al (2000) skriver at metoder er viktige, men at godesystemutviklere kjennetegnes mer for erfaring og kompetanse de fr gjennom praktiskerfaring som den metodiske kunnskap de oppnr gjennom teoretiske studier.

Cockburn (2003) diskuterer en-metode framfor flere-metode bruk i systemutvikling.Noen mener at en metode lser alt, mens Cockburn hevder at det kan vre ndvendig bruke flere metoder for utvikle et system. Han er en eksponent for agile systemutviklingsom legger mindre stringente krav til metode i sin utviklingsprosess. Her vil det vrepent for den enkelte utviklers improvisasjon.

ProsesseneI dette kapitlet vil vi beskrive prosessene innen henholdsvis skapende teater ogsystemutvikling. Frst gir vi en oversikt tekstmessig over hvert av omrdene. Deretterlager vi en tabell med stikkord for de enkelte aktivitetene som inngr i prosessene.

PROSESS FOR SKAPENDE TEATERGrunnpilaren i det skapende teater er improvisasjonen. Szatkowski (1991) sier at Mleter, at s mange som muligt er s dybt som muligt involveret i en skabende tilstand, s

lenge som muligt. I en skapende teaterprosess vil arbeidsrollene deltagerne har kunneskifte fra dramaturg til scenograf til skuespiller. Det er et ml at alle som deltar skalkunne bidra med ideer i alle ledd i prosessen. Dette er en vanlig arbeidsmte i skalt frieteatergrupper (ikke tilknyttet institusjonsteatre).

Szatkowski (1991) har innfrt begrepet lre av lre lage teater. Det vil si at deter selve den skapende teaterprosessen og teaterforestillingen (produktet) som eressensielt. Det er der den viktige lringen foregr og ikke i hvilke tema som blir tattopp i forestillingen. Utgangspunktet for en slik prosess kan vre alt fra et konkret tema tilen abstrakt bevegelse (f. eks en gest).

En forunderskelse eller research kan g i forskjellige retninger. Det kan vre en ytreresearch hvor en undersker temaet/ideen/impulsen eller mlgruppen en har valgt, og pden mten gr dypere og bredere inn i stoffet for tilegne seg kunnskap. Det kan ogs

vre en indre research for huske assosiative hendelser, bevegelser eller bilder til denvalgte impuls for bruke dette som en ressurs i arbeidet fram mot forestilling. Indre ellerytre research kan ogs anvendes som igangsetting av teaterprosessen dvs. ideen tilforestilling kommer etter research og ikke fr.

Dette grunnlagsmaterialet bearbeides s gjennom teaterimprovisasjoner. Forutenkunnskap og erfaring med improvisasjonsteknikkenes virkemidler, er fantasi ogidrikdom grunnelementer i dette skapende teaterarbeidet. For Jacques Lecoq (2002)(startet egen teaterskole i Paris 1956) var det essensielt frigjre den enkelteskuespillerstudents skaperevner. Et sentralt begrep p hans skole er l auteur-acteur


30/249


30

(forfatterskuespilleren). Med dette mener han at skuespillere kan skape sin egenforestilling, og st inne for hele teateruttrykket, ikke bare som skuespiller. I hans systemm studentene fra frste stund prve ut egne ideer, og fr dermed erfaring med enhelhetlig arbeidsprosess. I improvisasjonsarbeidet har det vrt fokusert p muligheter oglsninger.

Innenfor hvert omrde i en prosess er det forskjellige faser hvor det er vesentlig haevnen til kunne velge eller velge bort, evnen til trre vre i kaos, evnen til taklemotstand og tvil; og se p dette som viktige ressurser i en skapende prosess. Det vilogs vre en dialektisk prosess mellom pne (opplsning av faste forestillinger ogspredning av energi og konsentrasjon) og lukke (strukturering og samling av ideer)

(Szatkowski 1991). ha mange ideer og muligheter kan fre til gode ideer. En god ide skaper ofte flere godeideer. Som basis for arbeidet er det en fordel med energi og entusiasme, men motstand ogkonflikter kan ogs fre til nye og kvalitativt gode lsninger. jobbe med skapendeteater innbefatter stor ide-produksjon. Det er formlstjenelig lete etter lsninger og ikkedvele ved problemer. Det blir viktig prve ut mange ideer (pne) for underske hvilkesom fungerer. Dette vil oppleves som en kaoslignende tilstand. Det er en fase meduforutsigbarhet og overraskelser hvor sensureringslyst og kontroll ikke br vre tilstede.Nr prosessen er mlstyrt av et produkt, m en s gjre valg (lukke) og foredle ideer for f framdrift i prosessen.

Denne vekslingen mellom vre i en skapende tilstand og strukturere/gjre valg ergjeldende i all skapende virksomhet som har et produkt som ml. Frst nr en kommer tilinnvingen av forestillingen br denne vekslingen i stor grad vre over. Men ingen regeluten unntak. Det kan ogs vre slik at valgene som taes under prosessen ikke kan sees psom 100% endelige. Et eksempel er hvis en skal lage en god slutt p forestillingen seint iprosessen kan dette f betydning for starten p sceneuttrykket som muligens m gjresom. Det er essensielt velge en struktur p dramaturgieni stykket som vil tjeneteaterideen best.

Ut fra improvisasjonsarbeidet m det skapes et konsept som det kan regisseres ut ifra.Etter dette kommer en rekke vinger med prving og feiling. Det vil s bli vist et mer

eller mindre ferdig resultat for prvepublikum, som gir tilbakemelding p det de har settog opplevd. Tilbakemeldingenebrukes som ressurs i en avsluttende fase. Forestillingenvises s for valgte mlgrupper. Selv om forestillingen n kan betraktes som ferdig, vil denallikevel leve sitt eget liv, og sm endringer og justeringer gjres underveis ut ifraresponsen til mlgruppene. Nr en er vant med jobbe p improvisatorisk basisopparbeider en kompetanse til raskt kunne endre og justere.

PROSESS FOR SYSTEMUTVIKLINGDet finnes mange forskjellige systemutviklingsprosesser innen systemutviklingsfagfeltet.Fossefallsmodellen er vel etter hvert blitt brukt mer som en pedagogisk framstilling avsystemutvikling. Vi har iterative metoder og n ogs Agile systemutviklingsmetoder. I


31/249


31

denne sammenheng vil vi frst kort beskrive fossefallsmodellen og s iterativ og agilesystemtviklingsmetoder. Men frst har vi en kort beskrivelse av aktrer i systemutvikling.

De tre viktigste aktrene i en systemutviklingsprosess er styringsgruppen som tarbeslutninger om rammer bde i forhold til hva som skal utvikles rent teknisk og hvilkeressurser som skal brukes. Systemutviklerne er aktive i hele prosessen. Brukerne ernormalt aktive i de analyse- og designaktivitetene samt innfring og bruk av systemene.De er mindre aktive i selve programmeringen.

En sammenfatning av systemutviklingsmetodene i Whitten, Bentley, and Barlow (1994)og Kendall og Kendall (2002) gir en standard utviklingsprosess kunne se ut som flger:

forunderskelse, analyse, design, programmering, implementering, bruk, videreutviklingog avhending. Vi vil i det flgende beskrive de enkelte fasene i denneutviklingsprosessen.

En forunderskelse kommer gjerne via en av flgende tre situasjoner: eget initiativ,ptrykk utenfra, for eksempel klager fra kunder eller p grunn av nye eller endringer aveksisterende offentlige reguleringer. Man prver finne ut av n-situasjonen, problemetog mulig framtidig informasjonssystem.

Dersom det blir satt i gang et prosjekt gr man i gang med en analyse som er videre ogdypere enn forunderskelsen. Man sker lage en kravsspesifikasjon for systemet. I

denne fasen er framtidige brukere av systemet sentrale sammen medsystemanalytikere/utviklere. Styringsgruppas ansvar er ta overordnede avgjrelser,srge for ressurser og gi tilbakemeldinger p forslag som mtte komme fraprosjektgruppa. Selve arbeidet utfres i prosjektgruppa og eventuelle undergrupper.

Man gr s over i en designfase for gi svar p hvordan behovene/kravene oppfylles. Idenne fasen er systemutviklerne sentrale siden de lager mye av designet. Brukerne girtilbakemelding om de synes kravene oppfylles. Det er ikke sjeldent at denne fasen pregesav skalte creeping requirements. Brukerne lrer mer om hva som er mulig gjremed systemet og vil derfor ha oppfylt flere og mer utfyllende ting enn de opprinnelignsket. Dette kan fre til at man m g tilbake til analysefasen igjen for spesifisere

kravene p nytt. Konsekvensene av dette er ofte forsinkelser og overskridelser avbudsjetter. Designet gjelder bde funksjoner som skal utfres, brensesnitt som skal brukesog design av databasen som er lagringsdelen av systemet. Denne baseres p en modell avvirkeligheten som tar hensyn til de oppgaver som skal lses av systemet og hvordan deskal lses. I denne fasen er det rom for kreativitet hvordan man kan lse oppgavene.

Nr designet er ferdig overlates det til programmererne som lager applikasjonen. Dennem forholde seg til brukerne og deres rutiner slik at den letter arbeidet for de som skalbruke systemet. Her er det stort sett programmererne som rr grunnen. Det er likevel ikkeuvanlig at de m snakke med designerne eller brukerne for forst hva de skal


32/249


32

programmere. Dette avhenger selvsagt av hvor godt designet er dokumentert og om det erkonsistent.

I implementeringen blir systemet satt i drift i organisasjonen som skal bruke det. Her erdet brukerne som igjen overtar hovedrollen bruker systemet for gjre sin jobb bedre ennde kunne uten et slikt system. The proof of the pudding is in the eating er sant i dennesammenhengen. I denne fasen blir det klart om systemet svarer til hva brukerne nsket.Det er nemlig ikke sikkert at det de nsket er det de har kommunisert. Ved bruk vil det blienda klarere om systemet lser de oppgavene det er konstruert for. Ettersom systemetbrukes kan det oppst behov for videreutvikling som m gjres i samarbeid mellombrukerne og utviklerne. Dette kan vre prosesser som flger samme mnster som

diskutert i det overstende, men for deler av systemet. Til slutt kan systemet bli avhendetog man gr over til et nytt system for lse de samme oppgavene.

Iterative systemutviklingsprosesser har gjerne elementer av alle de ovennevnteaktivitetene. Utviklingen gr i flere iterasjoner som til slutt utgjr et ferdig produkt. Agileutvikling er enda lsere i kravet til struktur og system under utviklingen. Metoden er detsom utviklerne blir enige om gjre i utviklingen av systemene (Cockburn 2003).

De forskjellige metodene har ulike grader av frihet avhengig av hvor utviklerne er iprosessforlpet. I fossefallsmetoden nsker man gjerne fastlegge kravene tidlig for fen totaloversikt over det endelige systemet. Det kan by p vanskeligheter siden verden

forandrer seg over tid og det kan vre vanskelig modellere systemet slik fremtidigebrukere ser det (Mathiassen 2000). Iterative metoder tillater definering avkravspesifikasjoner gjennom prosessens gang. Samtidig begrenser friheten seg etter hvertetter som avgjrelser tatt tidlig i prosessen vil kunne innvirke p moduler som lagessenere i prosessen (Omland 2004). Selv om utviklingen skjer iterativt eller ved bruk av enagile metode kommer det likevel en tid der frihetsgraden til forandringer blir mindre ogmindre avhengig bde av hvor mye man har kodet og hvilke konomiske rammerprosjektet har.

Den enkelte utvikler vil arbeide bde selvstendig, med ansvar for en gitt oppgave og igruppe. Hovedfokus i arbeidet er ofte p produktet selv om prosessen ogs vektlegges.

Det synes likevel vre relativt vanlig at systemutviklingsprosessene ikke flgerbestemte metodologier, men at utviklerne tar elementer fra forskjelligemetodologier/metoder og bruker disse ettersom det passer i utviklingsarbeidet(Kiely ogFitzgerald 2003).

I det flgende sette vi opp prosessene for bde skapende teater og systemutvikling i entabell med stikkord relatert til de enkelte aktivitetene i prosessen. Vi har valgt brukestikkord fra de to fagomrdene som de brukes innen omrdene Isystemutviklingsframstillingen har vi valgt inkludere stikkord fra alle tre metodene,fossefall, iterativ og agile utvikling. Disse tre metodene inneholder elementer av deforskjellige stikkord, men i forskjellige grad og i forskjellige deler av prosessen. Innen


33/249


33

fossefall vil f. eks analysefasen vre lokalisert i en gitt del av prosessen selv om det vilforeg analyseaktiviteter i hele utviklingsprosessen. I iterativ utvikling vil det kunne vreanalysefase innen hver iterasjon.

Skapende teater SystemutviklingForunderskelseResearch, ske kunnskap om ide,mlgruppe,Energi, entusiasme og nysgjerrighet erviktig

ForunderskelseUtgangspunkt i problemer, ting fungererikkeForetas enten internt, via konsulent ellerutviklere

Valg av utgangspunkt ide eller tekst,

impulsFra konkret eller abstrakt ideKaos - pen prosessMange muligheterFantasiIdemyldringImpulsivtSpontantTilfeldigheter oppstrLek-lyst-flytIntuisjon

UenighetIkke gjr valg for tidlig

Analyse

Gr dypere inn i situasjonendatainnsamlingIntervjuerStudere skriftlig materialeN-situasjon, nsket situasjonForhold til strategier og planer i bedriftenAnalysen forsker beskrive virkelighetenslik fremtidige brukere vil se den innen sittarbeidePrototypingBrukerkontakt/involvering

Valg av formDramaturgiske modeller lukkendeprosess:Aristotelisk (liner utvikling)Episk (minst to fiksjonslag-fortellende)Simultan eller visuell (samtidig-flerefiksjonslag)Metafiksjonell (fiksjoner kommentererhverandre)

Ironisk-logisk motivertBlandingsformer av ovennevnte (vanligst)

Dette valget kan taes i forbindelse medkonseptvalg

DesignUtgangspunkt i resultatet av analysenTegner og foreslr hvordan det nyesystemet skal se utDette inneholder bde grensesnittet,funksjonene og modellen (databasen)Designet m forholde seg til den virkelighetbrukerne er iM lse brukernes oppgaver

Brukerkontakt/involvering

ImprovisasjonUtprving - pen prosessIde-raffineringSkapergledeMotstand-frustrasjon-vegringFleksibilitet

ImprovisasjonFlere lsningsforslagTilbakemeldingGjelder i alle aktivitetene i utviklingen menspesielt innen analyse og design aktiviteter


34/249


34

Lytte scenisk, vre oppmerksom, ikkeblokkere andres ideerKunne kill your darlingsSamarbeide-samspill-involveringLage et konseptGjre valg lukkende prosessLage helhet samlet uttrykkLytte analysere se muligheterFlge konvensjoner bryte konvensjonerNotereGjenta

RaffinereEt skritt fram to tilbakeMotstandKonsentrasjonFokusEt dialektisk prosess mellom kaos og valg

ProgrammeringDesignet omsettes i praksisValg av plattformProgrammeringssprkLite kontakt med brukerneHer foregr ogs testingModultest

System testDisse i forhold til brukerne

Teatervinger med regiValg er tattvinger med prving og feilingTlmodighetVenting

UtmattethetKonsentrasjon

PrveinstallasjonTesting av kundenTilbakemelding om feilnske om forandringer

PrveforestillingVises for et utvalgt publikumTro p produktpen for innspill

ImplementeringSystemet settes i bruk i bedriftenOpplring av brukerneKonvertering fra gammelt systemGradvis, parallelt eller revolusjon

Teaterforestillingteater oppstr i mtet med publikum

hver forestilling ny opplevelseyeblikkets kunstinnlevelsemestringsuksess/fiaskokick

BrukBrukerne tar det i bruk i sitt daglige arbeid

The proof of the pudding is in the eatingHer mter man gjerne problemer som ikkevar forutsett nr systemet ble laget.


35/249


35

Videreutviklinggjentagelse skaper noe nyttkommunikasjon med publikum girny inspirasjonfor- og etterarbeidrefleksjon

VidereutviklingSystemet trenger forandringerFeil rettes oppBrukerne melder feil eller utviklerne finnerdem

AvslutningTeaterstykket tas av plakaten

AvhendingSystemet avhendesRutinerDestruksjon av sensitivt materiale (sikeretc)

Tabell 1. Skjematisk framstilling av utviklingsprosessene i skapende teater ogsystemutvikling

Produktene

Utviklingsprosessene sikter mot et produkt. Vi vil beskrive dette i det flgende:

TEATERPRODUKTETSkuespillerne har valgt en mlgruppe for sin forestilling. Teater oppstr i mtet mellomscene og sal. Ethvert mte vil vre unikt. Ingen forestillinger er like. Hver gang enforestilling spilles, skapes den p nytt. Det hele avhenger av den uuttaltekommunikasjonen mellom scene og sal. Teater er yeblikkets kunst. Publikum oppleveret produkt.

For kunne vre i en prosess og produsere dette produktet m en ha kunnskap omteatrets virkemidler. Hver enkelt publikummer fr sin spesielle opplevelse. Somteaterarbeider kan en aldri vre sikker p at teatergruppens intensjon har kommet overscenekanten. Det er i mellomrommet medskapningen fra publikum sin side skjer.Forestillingen skapes i et samspill mellom skuespiller og publikum. En hovedintensjonkan vre gi publikum en interessant opplevelse. Det vil vre stor forskjell p responsen(den sagte og usagte) ut ifra i hvor stor grad publikum kan noe om teater. Et teatervantpublikum vil kunne lese teaterkodene og konvensjonene lettere. Skuespillerne kan f enerkjennelse ved utfre en form. Det vil ogs som oftest gi et flelsesmessig kick somogs innbefatter en mestringsflelse, og som brukes som energi ved neste forestilling. Enforestilling m spilles flere ganger for kunne utvikle seg. Refleksjonen og evalueringenav hver oppsetning kan fre til videreutvikling av produktet. Utviklingspotensialet frersom oftest til bedre kvalitet.

INFORMASJONSSYSTEMETEt informasjonssystem bestr av mennesker, rutiner, applikasjon og maskiner. Disse fireinngr i et samspill for lse de oppgaver som bedriften trenger utfre. Utfordringene


36/249


36

er at et slikt system med disse 4 forskjellige bestanddelene har forskjellig oppfrsel ogforskjellige krav til hvordan de kan oppfre seg. Det maskin- og applikasjonsrelatertekrever at all input m vre p en gitt form. Mennesker kan utfre sine rutiner med mereller mindre nyaktighet. Applikasjonen som kommer ut av en systemutviklingsprosess,spesielt hvis det er skreddersydd for bedriften, skal vare en del r. Brukerne vil derforkunne slite med mangler i produktet over tid eller m gjre forandringer p et relativt nyttsystem. Det skjer ofte at produktet oppgraderes og videreutvikles. Feil rettes mer ellermindre fortlpende med utgivelse av enten korrigerte programdeler eller nye versjoner. Idagens situasjon vil sikkerhet vre i hysetet og eventuelle sikkerhetshull tettesfortlpende i mange systemer. Informasjonssystemet er bde fysisk, synlig og varigsamtidig som det er usynlig. Det formelle, automatiserte systemet er implementert i

rutiner, programvare og maskinvare. Informasjonssystemet m ogs skapes i kontakt medsine brukere for kunne vre av god kvalitet. Samtidig kan slik kontakt vreproblematisk siden bde utviklere og brukere utvikler seg og lrer gjennom kontakten.Det kan fre til at systemspesifikasjonene forandres over tid.

Det kan vre forskjellige personer som deltar i forskjellige deler av utviklingsprosessen.

DiskusjonI diskusjonen diskuterer vi frst produktet deretter prosessen. Produktet diskuteres underto overskrifter, hensikt og varighet, mens prosessen diskuteres i relasjonen mellombrukerne, utviklerne og produktet. Innen skapende teater brukes ofte betegnelsene

skuespillere og publikum. Tilsvarende brukes ofte betegnelsene utviklere og brukereinnen systemutvikling. I denne sammenhengen velger vi bruke begrepene utvikler ogbruker for begge fagomrdene.

PRODUKTVi kan se produktet fra forskjellige perspektiv. Vi begynner med hensikten med produktetog skriver deretter om varigheten.

HensiktenTeaterforestillingen har til hensikt gi brukerne en kunstopplevelse. En kunstnerisk formformidles. Denne formen kan framkalle sanseopplevelser, tanker og flelser. Disse

erfaringene kan skape nye erkjennelser. Brukeren kan vre meddiktende i forestillingenved at forestillingen danner indre bilder hos bruker. Teater kan gi virkeligheten enfortolkning, vre en stilisert utgave av verden som gjr at en ser nye aspekter og finnernye sammenhenger i tilvrelsen. En teaterforestilling kan gi en god og viktig opplevelseselv om brukeren ikke har forsttt forestillingen intellektuelt. Brukeren kan ha skapt nyesymboler og sett andre sammenhenger enn utvikleren har tenkt. Det viktigste er atproduktet kommuniserer. En teaterforestilling er et mte mellom bruker og utvikler.Begge parter har en innvirkning p, og ansvar for kommunikasjonen.


37/249


37

Systemutvikling handler prinsipielt om forandring. Et nytt system utvikles gjerne for forbedre lsningen av eksisterende problem eller lse enten nye problem. Etinformasjonssysstem har derfor ingen hensikt i seg selv. Brukerne av systemet vil lsesine arbeidsmessige problemer ved hjelp av systemet. Det betyr at utviklere og brukeretrenger ha tett kontakt siden brukerne vil bli vrende med systemet i lang tid.

VarighetTeater er yeblikkets kunstart. Produktet er tilstede i her og n dimensjonen. Menforestillingen kan gjre noe med brukeren over tid. Produktet kan ha kommunisert p enslik mte at opplevelsen lever videre og skaper noe nytt i ettertid. Bruker kan assosiere ogfabulere videre p forestillingen. Utviklerne spiller oppsetningen en viss tid. Etter

refleksjon og rapport er forestillingen ferdig og taes kun i sjeldne tilfeller opp igjen pet seinere tidspunkt

Brukerne av systemet nsker en enklere hverdag der systemet hjelper dem i utfre detarbeid de er ansatt for gjre. Det er derfor viktig at systemet er tilpasset denarbeidssituasjon som brukerne er i til enhver tid. Det leder til mulig videreutvikling avsystemet. Et informasjonssystem er vellykket i den grad det over tid lser de problembrukerne er interessert i lse. Et system kan vre i bruk i en rrekke i sammeorganisasjon og vil derfor vre med pvirke hvordan brukerne arbeider.

Brukerne av et informasjonssystem er ofte avhengige av systemet og vil derfor vre

opptatt av at det er i drift og fungerer etter det de skal bruke det til. Det kan vre alt fra taste inn data, gjre regnskap eller ta ut rapporter til bruk i beslutningssituasjoner.

PROSESSEn teaterprosess veksler mellom vre en lukket og pen prosess (Szatkowski 1991).Prosessen er en kunstnerisk prosess hvor mange muligheter og forslag prves ut gjennomimprovisasjon og vil kunne betraktes som pen og uforutsigbar. Denne delen vil ogsha elementer av kaos i seg. Men i prosessen m det gjres valg, og dermed lukker maneller strukturer deler i prosessen skaper orden i kaos. En skapende teaterprosess erlsningsfokusert. Prosessen kan starte med en pen problemstilling. Viktige ressurser for utvikle en forestilling er kunnskap og skaperglede. Teaterprosesser er aldri like. Men

felles er at de frer til et produkt. Fra den pne problemstillingen kommer man gjennomprosessen fram til et konsept for s skape et produkt.

Prosesser som beskrives til bruk i utvikling av informasjonssystemer brukes ofte ikke slikde er beskrevet (Mathiassen 2000). Utviklerne gjr utvalg ettersom de mener det tjenerutviklingsarbeidet. Dette kan avhenge av blant annet strrelsen p systemet, utviklerneskompetanse og erfaring, tilgang p programvare, krav fra brukerne/oppdragsgiver etc. detsom faktisk skjer i utviklingen vil derfor avhenge av disse faktorene og man kan fforskjellig prosess for hvert enkelt utviklingsprosjekt.


38/249


38

Mye av utviklingen skjer i prosessen som finner sted mellom utviklere og brukere,brukere og produkt samt mellom utviklere og produkt. Vi vil derfor diskutere disseforskjellige relasjonene i det flgende.

Utviklere - brukereDet er viktig ha kunnskap om mlgruppen generelt. Ved henvende seg til brukerne ogunderske hva som opptar dem kan en f materiale til starte en teaterprosess. Dette kanen gjre ved intervjue, samtale, observere, men ogs ved ta tidsnden som kommerfram i forskjellige medier.En teaterforestilling trenger ikke direkte hente impulser fra mlgruppen. En teateridsom utviklerne har kan prves ut hos mlgruppen, og p den mten bli testet og f

respons.S snart en prveforestilling er klar kan den vises for brukerne. De gir s innspill tilutviklerne om endringer som med fordel kan gjres for at brukerne skal kunne f merigjen for forestillingen. Dette skjer i samtale med de som har utviklet forestillingen. Deter imidlertid ingen selvflge at alle forslag bygges inn i forestillingen. Det er flerehensyn ta. Men responsen taes vare p, og forslag videreutvikles. De sammebrukerne/prvepublikum/ ressursgruppe kan komme flere ganger, og p den mtenutvikles et samarbeid.

Enhver utvikling av et IS m ta hensyn til brukerne og deres behov. Det kan fre til ennr kontakt mellom de to partene. Ofte vil det vre motsettende interesser siden en

utvikling ofte vil involvere ressursbruk og krav til lsninger. I tillegg vil brukerne oftelre under utviklingsprosessen. De ser hva som er mulig f til. Dette kan fre til strrekrav i forhold til lsningen som igjen kan lede til strre press p utviklerne.

Utviklerne kan st i fare for tenke p hva de er i stand til gjre rent teknisk og bliopptatt av egne lsninger uten at dette ndvendigvis gir seg utslag i annet enn endemonstrasjon av egen fortreffelighet.

Brukerne kan gi respons p utviklingen og produktet til utviklerne. En utfordring her erom utviklerne forstr responsen. En annen er om de er villige eller i stand til forholdeseg til den. En tredje er om de er i stand til gjre noe med den som blir til fordel for

brukerne. Dette vil nok variere med utviklernes involvering og interesse i prosjektet.Brukere - produktEn teaterforestilling er som en levende organisme. Selv etter premiere vil mlgruppensresponser kunne pvirke forestillingen, og endringer gjres. I en forestilling som erimprovisasjonssbasert vil det ogs under selve forestillingen kunne gjres sm endringerut i fra publikums respons. En teaterforestilling fr ofte en umiddelbar og direkte respons- applausen. Hvordan applausen er er ogs et signal en m lre seg tolke. Det krevesat utviklerne utarbeider et kunstpedagogisk for- og etterarbeid til forestillingen. Dette forat brukerne skal kunne bli kjent med elementer av forestillingen i forkant, og bearbeide


39/249


39

inntrykk i etterkant. Noe som igjen kan sette i gang prosesser hos mlgruppen som skapernye opplevelser og erkjennelser.

Vanligvis blir brukerne vrende med informasjonssystemet som er utviklet. Det kan vrei bruk i organisasjonen i flere r. Dette kan fre til at brukerne stiller krav til utviklerneom bruk hvordan systemet skal vre. Brukerne fr ogs, i alle fall om det er snakk omskreddersm, ofte se prototyper av systemet og gi tilbakemeldinger p disse.

Utviklere - produktFor komme fram til et teaterprodukt m utviklerne i fellesskap ha skapt dette. Menproduktet kan ha blitt til med mye motstand i enkelte faser. Motsand er imidlertid ofte

vesentlig for komme fram til et kvalitativt godt produkt. Det vre seg motstand frahverandre eller motstand fra materialet de har arbeidet med. Det ha skapt et nyttprodukt gir mestringsflelse og en form for kick som gir energi og glede, og som msees p som viktig lring.

Informasjonssystemet utvikles ved hjelp av verkty som utviklerne bruker. Utviklerne eravhengige av arbeid sammen for n et ml, nemlig lage et informasjonssystem. Dethender likevel at de enkelte utviklerer har egne agendaer og disse kan i noen tilfeller vresterkere enn de felles agendaene som prosjektet som helhet har.

Konsekvenser for lringsmiljetGjennom studiet skal studentene forberedes for bde beherske prosessen og gjennomden framstille et produkt. Vi vil i det flgende kort vise hva vi mener de to fagmiljenekan lre av hverandre i forhold til lringsmilj.

PRODUKT

HensiktBde en teaterforestilling og et IS-system gir en opplevelse. Det er opplevelser medforskjellig kvaliteter. Teater er som nevnt yeblikkets kunstart og opplevelsen er tilstede imtet mellom bruker og utvikler. Et IS-system brukes muligens hver dag og opplevelsen

ligger p et annet plan, men en kan i begge tilfeller snakke om god eller drligopplevelse. I begge tilfeller kan kvalitetsbegrepet anvendes, analyseres og kritiseres.

Det er derfor viktig gjre studentene oppmerksomme p konsekvensene avopplevelsene bde intellektuelt, estetisk arbeidsmessig. Dette vil kunne gjre dem merbevisst p egen rolle i utviklingen og p de konsekvenser brukerne sitter med ved godeller drlig kvalitet p opplevelsen.

Varighet


40/249


40

Teaterforestillingen er fysisk tilstede over kort tid (1-2 timer). Opplevelsen kan levevidere i brukeren bde rasjonelt og emosjonelt. Hvis forestillingen ikke har hatt kvaliteterfor brukeren, er det ute av ye ute av sinn effekten. Teateret kan kanskje lrehvordan produktets varighet kan utvides for eksempel ved at det kan tas opp igjen senereog spilles p nytt.

Et IS-system kan ikke velges bort. Det er fysisk tilstede hver dag. Fokus p varigheten avproduktet frer til at studentene trenger oppmerksomhet p sin egen rolle og sitt egetarbeid og hvordan sette brukerne i sentrum for utviklernes aktiviteter.

Generelt kan vi si at et informasjonssystem kan involvere strre risiko i alle fall dersom

det er snakk om et strre system og en mislykket utvikling vil kunne gi store tap bde forutvikler og bruker.

PROSESSI begge prosessene kan vi anvende begrepet lsningsfokusert. For komme fram til enbest mulig lsning m muligheter og ideer arbeides med. Det m gjres valg for s utvikle formlstjenelige muligheter videre. Det stilles i begge prosesser krav tilhndverkskompetanse for f best mulig kvalitet. I en slik prosess hvor produktet er etml kreves det bl. a. nysgjerrighet, engasjement, energi, en pen innstilling ogsamarbeidsevne. Dette gjelder bde utviklere og brukere.

For kunne delta i slike prosesser er det viktig at studentene i begge fagomrdene lreret godt hndtverk, kommunisere, vre bevist p den estetiske dimensjon av arbeidetsamt lre seg selv bedre kjenne samt hvordan ens vremte kan pvirke brukerne avproduktet bde i utviklingsprosessen og i bruksfasene. I tillegg er det viktig vge bruke egne kreative ressurser. Her kan skapende teater og systemutvikling lre avhverandre.

En viktig forskjell mellom prosessene i skapende teater og systemutvikling er at skapendeteater har stort sett de samme aktrene under hele utviklingen. I systemutvikling kan detvre forskjellige aktrer som analytikere, designere, programmerere osv. Det kan vreen stor utfordring for kommunikasjonen i prosjektet siden de enkelte aktrer er avhengig

av informasjons fra aktrer de ikke har sett.

En interessant aspekt i begge prosessene er det som kalles pne og lukke iteaterprosessen. Disse prosessene forekommer i begge fagfeltene, men har muligensforskjellig betydning og premisser/konsekvenser i utviklingen.

KonklusjonVender vi tilbake til forskningssprsmlet kan vi kort konkludere med at de tofagomrdene kan lre noe av hverandre.


41/249


41

Utviklere av IS-systemer kan lre bruke mer av egne menneskelige ressurser, og f enstrre bevissthet om at mer enn rasjonelle egenskaper kan anvendes i en prosess fram motet produkt.

Utviklere av teaterforestillinger kan opparbeide en kompetanse for kunne forlengevarigheten av et produkt. En kan med fordel utvikle en plan for raskt kunne ta opp igjenet produkt, og p den mten forlenge en forestillings levetid.

En kan lre av hverandre ved formidling og utprving av metoder, for utvide og erfareflere muligheter og lsninger i prosessarbeid. Vi ser det som faglig interessant starteopp et samarbeidsprosjekt mellom studenter som utvikler IS-systemer og studenter som

utvikler teaterforestillinger. Et av mlene for et slikt prosjekt vil vre ke forstelsenfor hverandres prosesser og produkter. En vil ogs kunne utvide kunnskapen om prosessog produkt generelt. Det kan ke bevisstheten om fagfeltet og studentene vil lrehverandres begrep og koder. Ved analysere hverandres kreative prosesser vil en kunnese flere sider ved arbeidsmetoden, og p den mten vil begge grupperingene av studenterkunne profitere p hverandres erfaringer og kunnskaper. For f best mulig kvalitet pdette prosjektet br studentene kunne observere deler av hverandres prosesser ogreflektere over observasjonene. Vi ser at dette kan fre til et fruktbart samarbeide og verd prve ut i praksis. Det kan ogs vre inspirerende samarbeide i forhold tilbevisstgjring av de ovennevnte forhold.

pne og lukke aktivitetene i utviklingsprosessene br ogs vre interessante omrder forvidere studier innen de to fagfeltene.


42/249


42

Kildehenvisninger

Avison, D. E., Fitzgerald, G. (1988) Information Systems Development. Methodologies,Techniques and Tools, Blackwell Scientific Publications.Avison, D. E., Fitzgerald, G. (1995)Information Systems Development: Methodologies,Techniques and Tools. London, McGraw-Hill Book Company.Braanaas, N. (1999)Dramapedagogisk historie og teori, Tapir TrondheimCiborra, C. (1999) Notes on improvisation and time in organizations.Accounting,Management and information Technologies 9 pp. 77-94.Cockburn, A. (2003) People and Methodologies in Software Development, Ph. D,University of Oslo

Guss, F.G. (2001) Drama Performance in Children s Play-culture: The Possibilities andSignificance of form.HiO-report 2001 nr.6Heathcote & Bolton (1994)Drama for learning, Heineman, PortsmouthHuisman, M., and Iivari, J. (2002) The individual deployment of systems developmentmethodologies, CAiSE2002, Springer-Verlag Berlin.Iivari, J., and Hirschheim, R. (1996) Analyzing information systems developm

nokobit 2004 siste

Documents