Turning the Tables: Introducing Software Engineering ... - CiteSeerX

Turning the Tables: Introducing Software Engineering Concepts in a User Interface Design Course Julie Barnes and Laura Leventhal Computer Science Department Bowling Green State University Bowling Green, OH 43403 {jbarnes,leventha}@cs.bgsu.edu Abstract

minimal HC concepts in a traditional SE course, we propose a different approach. In our curriculum, we have integrated software engineering topics into our projectoriented HC course. This paper will describe our course and how we integrate the topics from the two areas of SE and HC.

The most recent report of the Computing Curricula 2001 (CC2001) suggests that updated curricula must reflect the broadening nature of our discipline. Two areas that are included in the strawman draft of CC2001 are software engineering (SE) and human-computer interaction (HC). While the first inclination might be to incorporate these minimal HC concepts in a traditional SE course, we propose a different approach. This paper outlines a project oriented HC course in which we are able to emphasize SE in the context of HC concepts. We include an overview of course content that illustrates our approach. 1

2

Introduction

The Computing Curricula 2001 (CC2001) project’s mission is “… to develop curricular guidelines for undergraduate programs in computing.” In the most recent report [4], the steering committee notes that the proposed curriculum must incorporate the broadening nature of the discipline and at the same time not so overload the curriculum with new topics as to make it intractable.

Our HC course is a project-oriented course. The students in the course complete several small individual projects and one large, team project. The goals of the course are:

One strategy to accomplish the broadening of the curriculum within reasonable time limits is to integrate several concepts within the same course. Later courses might then expand on some of the concepts. Two of the core areas specified in the current report of curriculum 2001 are software engineering and humancomputer interaction. Specifically, the strawman draft of the Computing Curricula 2001 proposes 30 hours dedicated to software engineering (SE) concepts and 3 hours of human-computer interaction (HC) concepts in its core. While the first inclination might be to incorporate these

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGCSE 2001 2/01 Charlotte, NC USA Copyright 2000 ACM 1-58113-329-4/01/0002 ... $5.00

Background

We have taught HC at the graduate level since about 1983. We first introduced an undergraduate HC course in 1988 and made the course a part of our core curriculum in 1994. As a core course, it is required for our degree. It is a threehour, semester-long course and students typically take it in their junior year.

•

To introduce students to the basic concepts of HC, including a variety of interaction styles.

•

To increase students’ awareness of the importance of user interfaces in software development.

•

To encourage the development of team skills among the students

•

To introduce students to the process, concepts and skills of software engineering and to apply them to the development and evaluation of a user interface (UI).

3

Course Content

Our course contains 6 modules. Introduction: We introduce the concept of the user interface. For this unit, we introduce the psychology of everyday things concept from D. A. Norman [8]. We also introduce definitional notions of usability, usefulness, usability models, standards, and guidelines. Finally, we discuss the historical forces that have influenced the computer industry in the context of usability. We typically spend about 2 weeks on the general concepts and 1 week on standards and guidelines. Projects: Students are expected to complete paper-and-pencil exercises where

214

they identify user interfaces of everyday devices and to identify characteristics of those interfaces that relate to usability.

phenomena. We spend 2 weeks on this unit. Project: At this point during the course, the students are finishing their large group project.

Tools: Students are exposed to the development tools that we will use throughout the semester. (We have used Visual Basic® (VB) to our advantage as a prototyping tool. Most of our students have learned some VB in our introductory programming course.) We also describe development tools for other environments, such as Tcl/Tk and Visual C++®. We spend about 1.5 weeks on development tools. Project: Students are expected to complete a tutorial and develop a simple UI of our specification using the tools.

Materials: Our primary textbook for our course is Developing User Interfaces: Ensuring Usability Through Product & Process by D. Hix and H. R. Hartson [2]. We supplement the text with readings from [7], [8], [3], [5], and our own materials. 4

Integrating SE concepts in a UI Course

We integrate software engineering into our course through our third unit and through our large term project. Our first major hurdle is overthrowing the misconceptions that they have developed about project development.

Process of UI development: In this module, we focus on the process of UI development and the parallel activities that occur during software development. The students use the concepts from this unit as they complete their large team project. We spend about 3.5 weeks on this unit. Projects: After completing this unit, students are assigned to small teams of 2 or 3 to work on their UI development project. During this specific time period, groups develop a task analysis for their project and start the development of their prototype UI.

The typical student entering our course has completed two or three programming courses (2 semesters of C++) and maybe a topic-specific course or two. The students enter the course with the common misconception that computer science is writing programs. When we informally survey the students about the distribution of effort across the software lifecycle, a majority (sometimes almost 100%) believe that the most resource intensive phase of a project is implementation and that about 90% of the resources for a project is spent on implementation. As a consequence of having programming courses as their primary exposure to computer science thus far, most students are simply not aware of their instructors’ efforts in creating clear, detailed specifications for each of their projects in previous courses. As for testing, most students believe that if their programs work for the data set given to them by their instructor, then the project is finished. When our students leave our course, we find that they have greatly matured relative to these misconceptions.

Interaction Styles: In this unit we present an overview of several different interaction styles, including commandline, form fill-in, menu-based, direct manipulation, haptic, and windowed. For each style, we highlight when the style is most appropriate in terms of task and user group. We also discuss some “rules of thumb” for the design of each interface style. Finally we discuss some guidelines for visual design. We spend 2 weeks on this unit. Projects: At this point, students are still working on their large UI development project. In particular, they are designing both the interaction style and specific look and feel of their interface. They will begin implementation of their interface as well. Because the students are busy outside class with their project, we also do a number of small-scale in-class exercises with this unit. These in-class exercises typically involve evaluation and re-design of interfaces across a number of interface styles.

4.1 Specific SE concepts

Our presentation of software engineering concepts includes the following topics:

Evaluation: We briefly present some common usability evaluation techniques and discuss the appropriateness of different data gathering techniques for different phases of development. We spend 1.5 weeks on this unit. Projects: Groups are required to perform a usability assessment on their large interface development projects. In order to accomplish this, each group develops some assessment materials and collects feedback from potential users. Each student must also serve as an evaluator for another group. Cognition: Our last unit presents a series of “rules” and explanations for cognitive phenomena as it relates to UI design. We follow a human information processing model of cognition where we present cognition in terms of human inputs/outputs, memory and storage, and information processing. In particular, we highlight some of our design guidelines and “explain” them in terms of cognitive

215

•

Lifecycle – We introduce the lifecycle concept. We emphasize the traditional waterfall model and describe its advantages and disadvantages. We explain what it means for a development project to follow a lifecycle model. We introduce alternative lifecycle models, including the spiral model [1] and the star model [2].

•

Lifecycle phases. We define the typical phases of a development project. We describe the development activities for each phase for software engineering and for UI design? We show how the phases for the two components of a software project are interrelated. (Hix and Hartson [2] give a detailed comparison between the software development lifecycle and the UI development lifecycle.) We present the average effort expended for each phase of the lifecycle.

•

Artifacts. We discuss the specific artifacts produced for each phase of the corresponding lifecycles. During

the project, the students actually produce some of these artifacts. •

For our large project, each group must do a hierarchical task analysis for their interface. If a group’s specification is found to be incomplete, we give a specification to them before they start implementation.

Software engineering methodologies. We introduce the students to a number of integrated methodologies and that there are CASE tools to support these methodologies.

•

Phases of the LifeCycle: We emphasize the phases of the prototyping lifecycle model that is shown in Figure 1. This model of Figure 1 is a simplification of the model that is presented in [2].

•

Systems Engineering: We introduce the students to the idea that before beginning any project, it is important to understand if the project is feasible within the confines of the development environment.

•

Requirements and Specification: Here we stress the importance and difficulty of developing a complete specification for any project. In a UI development effort, some of the specification activities might include an enhanced needs analysis, user analysis and task analysis, describing the target features, users and task breakdown of the proposed interface, respectively.

Requirements Specification SE development activities

•

Design and Implementation: In class, we draw parallels between the high-level architectural design that happens in general software development and the high-level interaction design of a UI. The low-level design activities for both a full software development effort and a UI include the design of modules, data structures and algorithms. We discuss the importance of standards and guidelines for the design phase. We introduce the concept of rapid prototyping to develop a UI. For the student’s large-scale project, each group must design and prototype a UI for their project.

•

Testing and Evaluation: We discuss the testing phase in class, but no in-depth examples of black-box testing, etc. are given. We do give examples of some methods for usability evaluation and the groups are required to do a small usability test as part of their project.

Design

Architectural Design

Low-level Design

Interaction Design

Interface Design

Implementation

Testing

Implementation

User Testing

System Engineering & Context Setting

UI development activities Task Analysis

Design

Figure 1: Parallel SE and UI development activities

216

5

Why a UI Course and not a SE Course?

Clearly SE concepts could also be a figural topic in other courses such as networking or operating systems. We have chosen the HC course specifically because UI development has such clear SE parallel activities, such as task analysis.

We do offer a full course in software engineering as a senior-level elective. The students who take this course get in-depth software development experience. Specifically they must work in moderate-sized groups (6 - 8) to specify, design, develop and test a software product that has both complex internals and a significant UI. Our HC course is a prerequisite to this course.

7

Student response to our course has been positive. Many students incorporate their UI project into their portfolios. Some graduates have told us that their current employment draws heavily from the concepts that they learned in this course and that they would strongly recommend both our HC and SE courses to current students. Also, since we have included the HC course in our core, we have found that the number of our majors who choose our SE course as an elective has increased dramatically.

So why do we not simply require our students to take the SE course and try to squeeze some HC concepts into it? First, we believe that the project in the UI course is more tractable to the students as a first time exposure to the phases and artifacts of the lifecycle than the project in the SE course is. By requiring only the development of the UI, the project is smaller and more interesting to the students. The students have a visual artifact to share with others of what they have accomplished in the class.

8

Secondly, our HC class is a maturation class. In this course, we help the students make the transition in their beliefs that computer science is all about coding to a wider world view. When students get to the SE course, they are much more open to the importance of non-coding activities in software development. When given the relatively difficult project, they are able to focus on the non-coding activities.

Conclusions

In the light of the discussions of CC2001, we believe that, as educators, we will have to be open to new distributions of concepts in the computing curriculum of the future. At first glance, CC2001 would seem to promote the idea that it should be easy to squeeze a minimum number of HC concepts into a traditional SE course. We proposed a different strategy where a UI design course can easily introduce the majority of SE concepts specified in CC2001. A project-oriented UI course not only introduces these concepts, but reinforces them with practice. Incorporating SE concepts into an HC course is a good introduction to a full SE course.

Finally, our integration of SE into our HC course is practical. Our major consists of 30 semester-hours of computer science courses. Were we to require an SE course, we would likely still need to require a HC course to fit into the CC 2001 guidelines. While we do not completely cover all of the recommended hours for both areas, we believe that students do get an adequate introduction to the concepts. Class time includes approximately 18 hours of instruction on SE concepts that are outlined in [4]. We also include about 18 hours on HC concepts that are outlined in [4]. 6

Student Feedback

References [1] Boehm, B.W. “A Spiral Model for Software Development and Enhancement.” IEEE Computer (May 1988), 61-72. [2] Hix, D. and Hartson, H.R. Developing User Interfaces: Ensuring Usability through Product & Process. John Wiley & Sons, Inc., New York, 1993.

Why not SE in another course?

A number of authors have suggested integrating SE concepts into introductory programming courses [9]. We also support the idea of introducing ideas at an earlier stage. One barrier to introducing more design issues in our early programming courses entails the use of C++ as the primary programming language for our curriculum. We seem to be constantly introducing new syntax structures to our students. The students concentrate on mastering the syntax of the language construct at hand and never find the time to reflect on the design issues. At this level, the instructors carefully layout the proposed solution to the problem specified in a lab assignment to enhance the probability of success for the student. This is one reason why we find that our students are not mature enough at these early stages to buy into the SE ideas. They are more receptive in their junior year.

[3] Horton, W. “Top Ten Blunders by Visual Designers.” Computer Graphics (November 1999), 20-23. [4] Joint Task Force on Computing Curricula. CC2001 Strawman Report 9 March 2000. Online. Internet [Accessed 31 August 2000] Available WWW: http://www.computer.org/education/cc2001/report/inde x.html. [5] Lindsay, P.H. and Norman, D.A. Human Information processing: An Introduction to Psychology, Second Edition. Academic Press, New York, 1977. [6] Myers, B.A. “A Brief History of Human-Computer Interaction Technology.” interactions (March-April 1998), 44-54.

217

[7] Norman, D.A. “Affordances, Conventions, Design.” interactions (May-June 1999), 38-43.

and

[8] Norman, D.A. The Psychology of Everyday Things. Basic Books, USA, 1988. [9] Sobel, A.E.K. Empirical Results of a Software Engineering Curriculum Incorporating Formal Methods in Proceedings of the Thirty-first SIGCSE Technical Symposium on Computer Science Education, (March 2000), ACM Press, 157-161.

218