The Case for Teaching “Tool Science” - IEEE Xplore

The Case for Teaching “Tool Science” Taking Software Engineering and Software Engineering Education beyond the Confinements of Traditional Software Development Contexts Christian Wolff Media Informatics Group University of Regensburg Regensburg, Germany [email protected] Abstract—In this paper the need for tool science, a discipline dedicated to the problem of developing, selecting, adapting and teaching about software tools for research is discussed. Starting from a general description of this field a short overview on the state-of-the-art is given. Core problems for tools research are discussed and several open research issues are identified like the need for case studies in research tool usage or making economic benefits of better usability and user experience for research tools evident. In addition, aspects of teaching concepts for tool developers and users outside the core disciplines of computer science and software engineering are presented. Keywords—scientific software tools; software engineering in research; user experience; typology of software tools in research

DEDICATION On the occasion of his 60th birthday, the author dedicates this paper to his revered teacher Professor Gerhard Heyer, Leipzig, who taught him about establishing software engineering in teaching as well as research contexts. I.

INTRODUCTION

In this paper, I argue in favor of establishing “tool science” as a specific subfield of software engineering as well as of related fields like information behavior. Tool science deals with all aspects of software development in research and appears to be relevant in all research domains (life science, natural science, arts and humanities, engineering disciplines) including teaching tool science to researchers engaged in development, usage or evaluation of scientific tools. In the following, the focus as well as examples and case studies will be drawn from the recently thriving field of the “digital humanities” as the author is wellacquainted with this domain. It should become clear, though, that most arguments should hold for other fields of research as well. The ideas laid out in this article are based on the following assumptions: Software Development is nowadays an almost ubiquitous endeavor in which many people participate, many of them lacking formal computer science and / or software engineering training. Nowadays, for many fields in the sciences as well as in the humanities research is software-based and dependent on the availability of adequate software tools. Among the examples for

this situation may be counted projects as prominent as the large hadron collider (LHC) in particle physics which is not only the largest tool man has ever built but at the same time is an innovation driver for distributed software development as well as for infrastructures for big data distribution and analysis. In many fields in the humanities [2] as well research practices are being changed by the obvious effects of data becoming digitally available. It is not daring to predict that in a few years research hardly will be possible anymore without the use of advanced (software) research tools in all fields of research. While it is clear that certain types of standard software like office and communication tools are nowadays used by virtually every researcher, the situation for more specific research tools is less clear. Research can be seen not only as the driver for a digital society but at the same time a field that is itself being transformed by the effects of digitization. [14] observe the following gap: “Nowadays modern software development processes are well established and are one of the mayor [sic! CW] success factors for software projects. However, many software projects in scientific organizations have serious quality issues since they lack a feasible development process.” Although there is little knowledge available on this issue, I argue that the software development context for scientific tools is so different from the established standards of software engineering that establishing tool science as a field of research is a worthwhile endeavor. Traditional software engineering development is focused on industrial strength software as Jalote puts it in his software engineering textbook [17]. While Jalote describes a contrast between “student software” and “industrial strength software”, a similar difference can be made out for software development in the tool domain. Especially the aspect of teaching tool science is a great challenge as the audience – everybody in charge of developing scientific software tools – is quite different from the typical computer science student learning about software engineering as a typical and regular part of an ordinary academic curriculum. Two caveats for the understanding of this paper should be mentioned in advance: First, parts of the argumentation below comes ex negativo as – in the author’s view – there is little documented evidence in the literature for the topic dealt with here, i. e. tool science for research software and what it means

978-1-4799-1908-6/15/$31.00 ©2015 IEEE 18-20 March 2015, Tallinn University of Technology, Tallinn, Estonia 2015 IEEE Global Engineering Education Conference (EDUCON) Page 932

for software engineering teaching. Such argumentation (“there is no …”, “we do not know …”, “… has not been studied yet”) is risky as it may well be an indicator of sloppy research (“I haven’t found it” does not mean something does not exist). Still, from long-term experience in research tool development as well as in the field of library and information system (LIS) strategy management [20], the author is quite optimistic that the arguments below stand up to closer scrutiny. The second caveat relates to the fact that in this paper the main focus is not on result presentation but rather on laying out ideas for research that has yet to be done. The reader may judge whether these ideas are worthwhile being considered for future research projects. The rest of this paper is organized as follows: In ch. II, the state of the art is briefly described, followed by an overview of the main issues and problems of tool science which are discussed in more detail in the sub-sections of ch. III. Finally, in ch. IV the specific context of teaching tool science is discussed along with suggestions for adequate learning scenarios. II.

STATE-OF-THE-ART

Today, software engineering is a well established field in computer science with a rapidly expanding body of knowledge (see the current version of the Software Engineering Body of Knowledge (SWEBOK) as a reference for this, [13]). Most of research and knowledge is focused at traditional software development scenarios, though. At the same time, the field of software engineering is virtually being reinvented every other couple of years, the recent pledge by Ivor Jacobson for a “New Software Engineering” [16] being just one example for this style of development of the field. It can be argued that at the same time, the debates on core issues of software engineering and project management methodology like the “battle” between management-oriented planning-focused traditionalists on the one hand, and agile or guerilla-style progressive developers on the other hand both do not touch the problem of non-standard or “non-professional” scenarios of software development as they are typical for many fields of tool development in research. In other words: There are large areas of software development which are not really in the scope of the established computer science and software engineering community, neither with respect to SE research nor with respect to teaching adequate SE practices to developers in these fields. Historically, science and engineering have been forerunners as far as software usage in research is concerned. Thus, it does not surprise that for these research domains, scientific journals like Computing in Science & Engineering exist which also publish on software engineering for scientific software topics. From 2008 to 2010, an international scientific workshop series under the title International Workshop on Academic Software Development Tools and Techniques (WASDeTT) existed, but was discontinued in 2011.1 In this context, a broad range of tool development issues are discussed with a strong focus on the transformation of research-driven software prototypes into industrial-strength tools. While this is an obvious problem for software developed in research contexts, as proof-of-concept status may be sufficient from a scientific perspective, in this

paper we look at different types of academic software tools: Those tools which directly support the research process – given the comparison mentioned above, their industrial strength has to be proven within the context of research. Another obvious focus of this strand of research is the question which software engineering methods might be applied for scientific software and scientific tools. III.

OVERVIEW: THE MAIN ISSUES IN TOOL SCIENCE

Tool science can be seen as a subfield of software engineering; at the same time there are plentiful cross-disciplinary relations. Among the most important issues and problems tool science should deal with are: • A basic typology of scientific software tools and tools development practices. • Knowledge about scientific information behavior and actual tool usage. • Issues related with the interface between software engineering and the field of application (here: the specific field of research for which a tool is developed). • Preservation, dissemination and communication with respect to scientific research tools. • Interaction and usability engineering for scientific tools. • Economic issues for tool science. • Concepts for teaching tool science. In the following sections, each of these fields will be discussed in more detail including examples and suggestions for further research are offered. A. A basic typology of scientific software tools and tools development practices The following basic typology is suggested as a starting point for analyzing scientific tools: Generic Development tools including programming and scripting languages as well as the support software like compilers, interpreters, and integrated development environments (IDEs) employed for their usage. Domain specific languages like the R packages for statistics belong to this category as well. Standard commercial off-the-shelf (COTS) software used for research purposes. Packages like Microsoft Office or the open source bundle LibreOffice are the most prominent examples. It can be argued that Microsoft Office is by far the most important and most widely used (if not the best) research tool across all disciplines with researchers managing data with Excel, using Word for simple text analysis purposes or producing visual representations of their research in Powerpoint. Software Infrastructures provided for research and researchrelated communication. In this category virtual research environments (VRE) play a major role ([24], [31]). Although there are already numerous virtual research environments for

1

See https://www.info.fundp.ac.be/wasdett2010/ and http://wasdett2011.wikispaces.com/.

978-1-4799-1908-6/15/$31.00 ©2015 IEEE 18-20 March 2015, Tallinn University of Technology, Tallinn, Estonia 2015 IEEE Global Engineering Education Conference (EDUCON) Page 933

various disciplines, some of them better to be characterized as flexible frameworks to be adapted to the specific needs of a certain field of research or even a concrete research question, their usage by researchers has not met expectations yet. At the same time, there is little or no literature on the systematic development and / or adaptation of such tools. Other examples are data analysis tools used in statistics (e. g. SPSS2) or AtlasTI3 for qualitative data analysis. Software specifically designed for specific research projects or research questions. This is the only category in this scheme where software is developed from scratch with the sole designation of research support. At the same time this category appears to be the most problematic as for this type of research tool one may assume less software engineering knowledge as more non-SE-trained domain experts are involved in the development. This is an initial categorization only; more classification criteria include • the actual technical basis and architecture of the software (stand-alone application; web-based tools; mobile tools; Web 2.0 features; cloud services etc.); • the relevant step in the research process for which a tool is used; • the functional aspect – what are the main functional features of a tool; • the intensity of human interaction that is involved in using a tool and the interface style that is provided for this purpose; • any explicit focus on a specific research problem that is addressed by the software; • the type of technical knowledge needed for handling the tool; • degree and type of adaptation, scripting or additional programming that is needed for the software to be used for a specific research problem; • the legal status of the tool (free and / or open source software; commercial application; licensing model) • support services for the tool (commercially offered; community-driven). Beside these additional categories the development methodology employed is an interesting aspect: Different “configurations” of cooperation in developing scientific tools coexist, the “ideal” variant being that where well-established software engineering practices are applied and teams with adequate training and expertise cooperate. This may be true for larger and functionally generic tools. In many cases, though, tools are going to be developed by people with an (academic) background mainly in their respective area of expertise. A study presented by Carver et al. 2013 [7] shows that for scientific software development projects, scientists (as tool developers) are interested in roughly the same software engineering issues as software engineers like versioning tools or documentation 2

http://www-01.ibm.com/software/analytics/spss/

aspects but on average have less knowledge about them which is in line with the assumptions made above. Structurally, the software engineering aspects of adapting existing software or scripting for standard software is quite different from the standard software development (and maintenance) process where the software itself is under control of the development team. In other words: How to systematically support these non-standard software development processes is an open question. How do you go about setting up a collection of Word macros? Which scripting language can be used in the context of a specific virtual research environment? How can quality management aspects (versioning, documentation etc.) be performed for such smaller-scale development efforts? Compared to tool adaption and scripting, the development of new tools is closer to the traditional software engineering profession. This should be seen as some kind of last resort, though, as in most cases tools for almost any purpose already exist. The status of computer science as a science of abstraction makes a strong case for the fact that in many circumstances, available tools should have the prerogative over the development of new tools. B. Knowledge about scientific information behavior and actual tool usage If at least some knowledge on existing tools is available in a structured way, this can hardly be said of actual tool usage in different disciplines and for different types of project. In other words, the “evidence turn” [19] in science has not reached scientific tools usage yet: Neither do we know a lot about which tools are used for what purpose nor do we have precise insight into the development practices in research. Developing and using software tools for research can be seen as a variant of information behavior [8]. For the field of humanities, only a few studies on actual tool usage exist ([32], [5]). While these studies give a first impression of current software usage in (humanities) research, they do not go beyond a rough first impression as far as aspects of software engineering are concerned. The study presented by Burghardt et al. 2014 [5] was conducted among all humanities researchers at Regensburg University who were asked to fill out a questionnaire concerning their tool usage. With a response rate of ca. 25 % a major subset of the addressees replied. The results show values for the relative percentage of the use of a specific type of software during the different steps in the research process, modeled as: • communication/collaboration • search aspects • conceptualization • data acquisition • data management and preparation – data analysis • text and media production • publishing. 3

http://atlasti.com/

978-1-4799-1908-6/15/$31.00 ©2015 IEEE 18-20 March 2015, Tallinn University of Technology, Tallinn, Estonia 2015 IEEE Global Engineering Education Conference (EDUCON) Page 934

Fig. 1 (translated from the original German conference poster) shows the results for the rather automation- and software prone data analysis phase:

• Good development practices – tools are developed according to current standards in software engineering and usability engineering / user experience. • Tool usage is efficient and effective – available resources are used in an optimal way. • Tool usage is fun – Good user experience as well as gamification elements [18] strengthen motivation to use the tool and may preserve overall user satisfaction. At first sight, many scientific research tools are at level 0 which means they hopefully provide the functionality they are made for, but neither meet technical software engineering standards nor do they provide a satisfactory level of usability and user experience. The dimension of analyzing actual tools usage is closely related to the aspects of evaluation the tools used for research. From the viewpoint of empirical software engineering [33], an experimental setup comparing different tool solutions for the same research problem in a long-term study is the ideal instrument of introspection. Unfortunately, the effort needed and the actual cost involved in that kind of research are forbidding.

Fig. 1. Tool Usage for Data Analysis in the Humanities [5]

There are few studies that give more detail on the development process for scientific tools as well as on the actual tool usage practice. For example, little or nothing is known about the aspects driving tool and development method selection in research. Certainly, prior experience, availability of information on tools or availability of the tools themselves can seen as relevant factors. Also, institutional support for tool usage given by computing centers or research libraries might be a factor. This information could be a valuable basis for optimizing tool support. Two suggestion might foster this kind of research: First, the establishing of capability maturity models (as they are well known in certain fields of software engineering, see CMMI or SPICE as the most influential standards, [9]) for tool development might help. A maturity model should be used for analyzing and classifying non-standard software development practices in research as well as actual tool usage. Such a model should focus on software engineering as well as user experience as important aspects and quality indicators beyond the basic provision of tool functionality. The abstract quality levels as defined for CMMI (initial – managed – defined – quantitatively managed – optimizing) can be applied to the research tool development process as well as the tool usage analysis. In addition, a simple status hierarchy evaluation might be added and combine both, development as well as usage aspects: • Basic functionality – goal: the tool does what it is intended for

This leads to the second suggestion: Establishing case study research [25] for scientific tool development and usage. Along with adequate description formats for tools (see above) case studies can help identifying good development practice as well as benefits of choosing the right tools and using the tools correctly. [21] gives an example for this kind of empirical research on software usage. Given a simple tool description scheme along with models for describing the research process as mentioned above, collecting case studies could also be established as a community-based and crowdsourced effort. C. Interface between software engineering and the field of application Bridging the chasm between the application domain and its language and the technical and / or interaction related domain is a well known problem and one of the core issues in requirements engineering as understanding the actual needs in a project involves understanding (here) the language of research as the filed of application. While for “traditional” IT projects, i. e. projects where the IT parts are performed by IT professionals, different language or language use as well as different cultures (of work, of planning, project management and communication) are examples for problems ([11], [10]). In the case of research tool development and usage with non-standard composition of IT development teams misunderstanding or misapprehension may take another direction: Instead of IT experts misunderstanding issues of the application domain we may find domain experts (researchers) misunderstanding IT issues, specifically in the software engineering domain: In many cases there is a lack of awareness for the benefits of good software engineering practice. The same may hold for project management in scientific research projects. In addition, for many practitioners (“researchers”) issues like usability, joy of use and user experience are seen as nice-to-have features or soft topics which – in their view – do not touch the core problems to be solved by research tools. The problem of different stakeholder perspectives in user experience and usability engineering has been studied in depth by Sharon 2012 [27]. In some cases, fear of

978-1-4799-1908-6/15/$31.00 ©2015 IEEE 18-20 March 2015, Tallinn University of Technology, Tallinn, Estonia 2015 IEEE Global Engineering Education Conference (EDUCON) Page 935

losing an exclusive position as tool developer and user may add to the problem: The non-technically trained technical expert fears to lose his position or standing in a specific project context. This is a misunderstanding which is not easy to get out of the way.

This experience can easily be transferred to professional contexts: What users have learned to appreciate, they will expect from any type of software sooner or later. In addition, usability is not just about users liking to work with a specific type of software but can have relevant economic consequences:

D. Preservation, dissemination and communication with respect to scientific research tools As many scientific tools are developed for very specific projects, there is a need for aggregating and disseminating knowledge about their specific features which helps prospective tools users in selecting the right tools. For some areas like computational linguistics or electronic publishing, such tool overview platforms have been created: In the Carpet project, a “Community for Academic Reviewing, Publishing and Editorial Technology” was established (http://www.carpet-project.net/), resulting in a community-based structured overview of tools available for electronic publishing [26]. Another example is the Systems in Language Technology overview which is part of the Language Technology World platform giving keyword-based short descriptions of tools and links to the tools internet sites (http://www.lt-world.org/kb/resources-and-tools/languagetools/).

F. Economic issues for tool science Economic aspects of software engineering have been established by Barry Boehm’s seminal work on cost models in the 70ies already [3]. While models as those proposed by Boehm focus on large-scale industrial software production, they are less apt for modeling the economic effects occurring in scientific software projects. Especially for interaction-intensive tools as they are typical for many tasks in arts and humanities research, another version of economic analysis could be fruitful: The gain in efficiency that comes along with better software engineering practices and which is a direct outcome of better usability and user experience can be measured (productivity / efficiency gain as more data can be processed in less time, or better quality of analysis / effectiveness can be attained with the same resources). Especially for corpus-based projects (content analysis, digital editions, and linguistic annotation) where a lot of tool interaction takes place over a long range of time, usability optimization has a strong leveraging effect, as every keystroke or mouse click less for the same task is repeated thousands and thousands of times. This economic argumentation should be helpful in transforming the “usability and joy of use is a soft topic / issue”-trap which rarely is made explicit.

What is missing, though, is a generic (and possibly XMLbased) scientific tool description language which might be used for all fields of research as well as all types of tools. Such a language should be flexible enough to describe a broad variety of tools and tool functionality. At the same time, as will be argued below, it is not only tool descriptions that are needed, but in-depth case studies and descriptions of actual tool usage experiences which could be supported by a common description format. A good starting point for such a standard could be the SWRC ontology developed for describing research communities [30]. E. Software Engineering and Usability Engineering In the relationship between software engineering and usability engineering, the latter can be interpreted as being part of a broader field of software engineering. Many scientific tools, especially in the humanities, require intensive interaction between the user (researcher) and the data or the computer presenting and analyzing the data. Research tools do not render intellectual work like image interpretation, text analysis or linguistic annotation superfluous but rather support the research process actually performed by human intellect. This means that a lot of interaction between research, the research tool and the data takes places. While the overwhelming trend for using computing systems in everyday usage scenarios has stressed the importance of usability and user experience in recent years, this is not (yet) the case for scientific tool development and evaluation where lack of usability knowledge or simple misunderstandings on the nature and the importance of this field have hindered more willing adoption of good usability engineering practices. As can be observed in many fields of software development, the recently established users’ practical knowledge about the qualities of well designed interactive tools can be expected to be very helpful: Users know from their everyday experience how good software tools (games, social media software, communication tools used on mobile phones etc.) work – they would not use them if user experience is bad.

More than 25 years ago, as usability engineering practices were comparatively new in the software engineering field and empirical research in the context of user centered design (UCD) appeared to be costly and resource demanding, Jacob Nielsen ([22], [23]) introduced the idea of discount usability showing that with little effort in usability analysis, impressive results may be obtained. For fostering better tools in research, a combination of both approaches mentioned above is advisable: The low threshold of discount or “guerilla” usability practices helps getting UX established (at all), the economic benefits and leveraging effects of better tool usability help making the case for development resources for usability engineering. Currently, only few articles on the relationship between economics and HCI can be found ([28], [29]). What is needed, are case studies and experience reports that deliver proof for the analytically plausible leveraging effect of better usability in interaction-rich research tool usage scenarios. IV. HOW TO TEACH SOFTWARE ENGINEERING FOR SCIENTIFIC TOOLS DEVELOPERS (“TOOL SCIENCE”) From the discussion of key problems of a future tool science it should have become clear that there is not a single “silver bullet” of best development practices. At the same time, this holds true for teaching software engineering to research tool developers: From traditional teaching scenarios where software engineering becomes part of an academic curriculum to “snack learning” of key software engineering elements “on the project” a broad variety of approaches can be adequate. In the following paragraphs, I would like to focus on suggestions for teaching

978-1-4799-1908-6/15/$31.00 ©2015 IEEE 18-20 March 2015, Tallinn University of Technology, Tallinn, Estonia 2015 IEEE Global Engineering Education Conference (EDUCON) Page 936

practices which go beyond the standard classroom / lecture model. First of all, one should look beyond elementary programming techniques and practices: Many issues in software engineering as well as usability engineering focus on topics beyond programming techniques and issues. The less time for SE training is available in a certain scientific tool development context, the more the focus will be set on the more basic technical issues related to specific programming languages or software development tools and frameworks. A. Taking up SEMAT Proposals Ivar Jacobson and others ([15], [16]) recently have proposed a concentrated and small body of software engineering knowledge they call the SEMAT (Software Engineering Method and Theory) kernel as the essence of software engineering. This focused kernel is proposed as an actionable, extensible and practical set of knowledge about software engineering, bridging the gap between experienced craftsmanship in software engineering (practice) and software engineering theory by a modular system of core activities (“alphas”) related to the basic perspectives of customer (opportunity / stakeholder), solution (requirements / software system) and endeavor (work / team / way of working). This novel approach has yet to be applied to scientific tool development and usage; its simplicity on the one hand and the hands-on practice-driven approach on the other make a promising framework to research tool projects. B. Project-oriented Teaching Formats Integrated models of teaching software engineering aspects along with domain knowledge in project-oriented teaching scenarios appears to be a promising model for better research tool development practices. In the media informatics M. Sc. program at Regensburg University, such hybrid class formats where knowledge diffusion by the lecturer goes hand in hand with participants’ project work are a core element of several courses, among them an advanced class on digital humanities. Results from these seminars are documented in [6]. Recent experience shows that this format is especially fruitful for interdisciplinary design and project teams where media informatics students work along with media / cultural studies or linguistics students. C. Provide Best Practice Information Tool description collections as an important means of communication about research tool usage have already been mentioned above. An additional – and more structured way of presenting knowledge on scientific software tools are pattern collections: The design pattern approach ([1], [12]) has been quite fruitful in software engineering as well as in usability engineering. Patterns can be used as an easy-to-use semi-formal approach for describing proven solutions for recurring problems. They have been used widely especially for interactive tools. Pattern collections are also becoming a means of documenting the research tool landscape for different fields. One recent example (from my own scientific context) is the pattern library for linguistic annotation tools that Manuel Burghardt has developed in his dissertation project [4]: The problem of linguistic annotation is a very old methodological problem in linguistics, as for almost any linguistic research question,

available data have to be annotated: The existing tool landscape is very broad at the same time. In this pattern collection, best practice patterns for all functional aspects of annotation software are explained and can be used for future software design. Fig. 2 shows an example of this wiki-based online platform:

Fig. 2. “Mode for primary data”: Example for a pattern-based functionality description (source: http://www.annotation-usability.net/pmwiki.php?n= PmWiki. ModeForEditingPrimaryData )

While this type of information is relevant for tool developers, similar information formats (pattern collections, communities of practice etc.) are needed for tool usage reports: What tools do researchers opt for? What are the criteria for tool selection? What experiences are being made? What recommendations can researchers make? Do alternative ways of research tool usage become evident? D. Establishing institutional support for tool science Given the heterogeneity of tools and tool functions, the different CS / SE background of researchers using and / or developing tools as well as the general complexity of the research process, institutional support given by “tool consultants” appears to be a reasonable desideratum: In the last years, a lot of resources have been invested in the development of all kinds of research tools and virtual research environments, reducing the actual need for the development of new / additional tools. At the same time, actual usage of such advanced research tools lags behind expectations. If one accepts that it cannot be expected from every researcher in every field that she or he has the necessary set of competencies to develop project-specific tools, a provision of research tool counseling could foster better tool usage, and, in the log run, better project results. Research libraries, media and computing centers could be natural carries for this kind of task. At the same time, computer science, (empirical) software engineering as well as information behavior research in information science can contribute the necessary knowledge, e. g.: What is the actual intellectual profile a research tool consultant need? How much understanding of the target domain in research is necessary? What kind of adaptation is necessary for the tools? Is it possible to estimate the elementary project characteristics (time / effort / scope)?

978-1-4799-1908-6/15/$31.00 ©2015 IEEE 18-20 March 2015, Tallinn University of Technology, Tallinn, Estonia 2015 IEEE Global Engineering Education Conference (EDUCON) Page 937

V.

CONCLUSION AND OUTLOOK

Summing up, the field of scientific research tools offers manifold research opportunities, some of which have been sketched above. As advanced software tools usage in research will become something no reasonable research project can do without, the need and pressure for more and better information on tool characteristics will rise as will the need for teaching tool skills to researchers. Well-established skill types like information and communication technology (ICT) skills as well as information literacy will have to be redesigned to include scientific research tool development, selection, adaptation and usage. At the Institute for Information and Media, Language and Culture, University of Regensburg, information behavior research is an important focus of research. This includes aspects related to tool science like analyzing the actual interaction behavior and tool usage in research. Another challenge we are working on is teaching the necessary software engineering aspects of research tools to those who develop or adapt those tools but are not software engineers themselves: Teaching tool science. REFERENCES [1]

C. Alexander, S. Ishikawa, and M. Silverstein, A pattern language : towns, buildings, construction. New York: Oxford University Press, 1977. [2] D. M. Berry, Understanding digital humanities. Houndmills, Basingstoke, Hampshire; New York: Palgrave Macmillan, 2012. [3] B. Boehm, Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981. [4] M. Burghardt, "Engineering annotation usability - Toward usability patterns for linguistic annotation tools," Ph.D. Dissertation, Institute for Information and Media, Language and Culture, University of Regensburg, Regensburg, 2014. [5] M. Burghardt, A. Schubert, M. Traber, and C. Wolff, "Empirische Untersuchung zu digitalen Arbeitspraktiken in den Geisteswissenschaften an der Universität Regensburg (Poster) [empirical investigation on digital practices in the humanities at Rewgensburg University]," presented at the 1. Jahrestagung der Digital Humanities im deutschsprachigen Raum (DHd 2014), Passau, 2014. [6] M. Burghardt and C. Wolff, "Digital Humanities: Buzzword oder Strukturwandel in den Geisteswissenschaften? Stand und Perspektiven anhand Regenburger Beispiele [Digital Humanities – buzzword or structural change in the humanities? State and perspectives explained using examples from Regensburg University]," Blick in die Wissenschaft: Forschungsmagazin der Universität Regensburg, vol. 23, pp. 39-47, 2014. [7] J. Carver, D. Heaton, L. Hochstein, and R. Bartlett, "Self-Perceptions about Software Engineering: A Survey of Scientists and Engineers," Computing in Science & Engineering, vol. 15, pp. 7-11, 2013. [8] D. O. Case, Looking for information : a survey of research on information seeking, needs and behavior. Bingley: Emerald, 2012. [9] CMMI Product Team, "CMMI for Development, Version 1.3," Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-2010-TR-033, 2010. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9661 [10] S. Cormack and A. Cater-Steel, "Prescription to remedy the IT-business relationship," in Socio-technical and human cognition elements of information systems, S. Clarke, E. Coakes, M. Gordon Hunter, and A. Wenn, Eds., ed Hershey, PA: IGI Publishing (IGI Global), 2003, pp. 181202. [11] S. Cormack, A. Cater-Steel, J. H. Nord, and G. D. Nord, "Resolving the troubled IT-business relationship from a cultural perspective," presented at the 12th Australasian Conference on Information Systems (ACIS 2001), Coffs Harbour, NSW, Australia, 2001.

[12] E. Gamma, Design patterns : elements of reusable object-oriented software. Reading, Mass.: Addison-Wesley, 1995 [13] IEEE Computer Society, P. Bourque, and R. E. Fairley, Guide to the Software Engineering Body of Knowledge (SWEBOK(R)): Version 3.0: IEEE Computer Society Press, 2014. [14] V. Hoffmann, H. Lichter, and A. Nyßen, "Processes and Practices for Quality Scientific Software Projects," presented at the Third International Workshop on Academic Software Development Tools and Techniques (WASDeTT-3), Antwerp, 2010. [15] I. Jacobson, P.-W. Ng, P. E. McMahon, I. Spence, and S. Lidman, The Essence of Software Engineering: Applying the SEMAT Kernel: Addison-Wesley Professional, 2013. [16] I. Jacobson and E. Seidewitz, "A new software engineering," Commun. ACM, vol. 57, pp. 49-54, 2014. [17] P. Jalote, A concise introduction to software engineering. London: Springer, 2008. [18] K. M. Kapp, The gamification of learning and instruction : game-based methods and strategies for training and education. San Francisco, CA: Pfeiffer, 2012. [19] B. A. Kitchenham, T. Dyba, and M. Jorgensen, "Evidence-Based Software Engineering," presented at the Proceedings of the 26th International Conference on Software Engineering, 2004 [20] Kommission Zukunft der Informationsinfrastruktur, "Gesamtkonzept für die Informationsinfrastruktur in Deutschland. Empfehlungen der Kommission Zukunft der Informationsinfrastruktur im Auftrag der Gemeinsamen Wissenschaftskonferenz des Bundes und der Länder [comprehensive concept for the future information infrastructure in Germany. Recommendations given by the commission Future of the Information Infrastructure]," GWK / WGL, Berlin, 2011. [21] S. Minocha, "A case study-based investigation of students’ experiences with social software tools," New Review of Hypermedia and Multimedia, vol. 15, pp. 245-265, 2009/12/01 2009. [22] J. Nielsen, "Usability engineering at a discount," presented at the Proceedings of the third international conference on human-computer interaction on Designing and using human-computer interfaces and knowledge based systems (2nd ed.), Boston, Massachusetts, USA, 1989. [23] J. Nielsen. (2009, January 7, 2015). Discount Usability: 20 Years. Available: http://www.nngroup.com/articles/discount-usability-20-years/ [24] T. Reimer and A. Carusi, "Virtual Research Environment Collaborative Landscape Study," JISC, London 2010. [25] P. Runeson and M. Höst, "Guidelines for conducting and reporting case study research in software engineering," Empirical Software Engineering, vol. 14, pp. 131-164. [26] F. Schüle, "Provide, obtain and exchange information: the e-publishing technology information platform CARPET," Insights: the UKSG journal, vol. 25, pp. 305-310, 2012. [27] T. Sharon, It's Our Research. Getting Stakeholder Buy-in for User Experience Research Projects. Waltham, MA: Morgan Kaufman, 2012. [28] M. Sikorski, "HCI and the Economics of User Experience," in Maturing Usability, E.-C. Law, E. Hvannberg, and G. Cockton, Eds., ed: Springer London, 2008, pp. 318-343. [29] H. Sun, "Developing an Interdisciplinary Area of Economics and HumanComputer Interaction," AIS Transactions on Human-Computer Interaction, vol. 2, pp. 151-166, 2010. [30] Y. Sure, S. Bloehdorn, P. Haase, J. Hartmann, and D. Oberle, "The SWRC Ontology – Semantic Web for Research Communities," in Progress in Artificial Intelligence. vol. 3808, C. Bento, A. Cardoso, and G. Dias, Eds., ed: Springer Berlin Heidelberg, 2005, pp. 218-231. [31] F. van Till and J. Redfearn, "What is a Virtual Research Environment? Experience from the JISC VRE programme," JISC, London2010. [32] E. G. Toms and H. L. O’Brien, "Understanding the information and communication technology needs of the e-humanist," Journal of Documentation, vol. 64, pp. 102-130, 2008. [33] C. Wohlin, P. Runeson, M. Höst, M. Ohlsson, B. Regnell, and A. Wesslén, Eds., Experimentation in Software Engineering. Heidelberg: Springer, 2012..

978-1-4799-1908-6/15/$31.00 ©2015 IEEE 18-20 March 2015, Tallinn University of Technology, Tallinn, Estonia 2015 IEEE Global Engineering Education Conference (EDUCON) Page 938