Session 1

Introduction to Software Systems


Software Systems

Exercise 1: Beginning to Understand Software Systems


  1. To think about software systems in several different ways.
  2. To (re)acquaint yourself with members of the class.
  3. To learn what the rest of our sessions this semester will be like.


  1. Make a list of at least three different software systems that you have used. Make sure that the systems on your list are as different from one another as possible. Then, rank them along two dimensions of your own choosing. For example, you might rank them on ease of use, from easiest to use to hardest to use.

  2. Organize yourselves into groups of four or five people. Make sure that your group contains at least one person you don't already know. Introduce everyone in the group. Make a master list of the software systems on your individual lists.

  3. Discuss the dimensions that you used in Step 1 to rank your systems. How many different dimensions were used among the group? In what ways are the dimensions similar? In what ways are they different? Rank all of the systems on your new master list along each of the dimensions.

  4. As a group, identify two dimensions different from the ones you discussed in Step 3. Try to make them as different in perspective as possible. Rank the systems on your master list along each of the new dimensions.

  5. Select a spokesperson. If your group is asked, the spokesperson will present informally the results of your group's work to the class.

At the End

  1. Turn in a write-up showing your master list of software systems, a summary of your discussion of the dimensions you used to rank the systems, and your group's rankings along each of the dimensions.

Summary from Exercise 1

What is a software system?

Software systems are ubiquitous. Software systems are diverse in nature: editors, operating systems, programming tools (but not languages, mostly), networking systems, "productivity" tools, less obvious applications such as GPS, ATMs, and voice mail.

Comparing systems across categories (e.g., operating systems versus compilers versus word processors) is like comparing apples to oranges. So, understanding software and its interface may require a lot of task- and domain-specific knowledge.

One can view software systems in many different dimensions: ease of use, age, reliability, aesthetic value, complexity, robustness, learning curve, time to complete a (typical) task, portability, cost, maintenance, user support, hardware requirements, availability.

People do not always agree with one another when assessing software. There is a difference between "I feel ..." and "I think ...". Feelings are unavoidable when evaluating things, and they can even be good ways to get started. But we will strive to find objective criteria for evaluating software systems.

A Quick Course Introduction

I am Eugene Wallingford, and I'll be your instructor for Software Systems. Please call me "Eugene". This course will probably differ from every other CS course you have had, even if you have had me for an instructor before.

Some of the guiding ideas of this course will be:

Today is representative of what our class sessions will be like this semester. Our primary goal is that you learn about software systems from a different perspective. A secondary goal is that you become more independent as learners.

The course is different, but it should be interesting and more productive -- if you let it!

The course syllabus is on-line in this web space. Read it. Re-visit it occasionally if I announce changes. The course web page and the course e-mail discussion list will be our primary means of communication outside of class time.

Exercise 2: Understanding Ways to Evaluate Software Systems

In the previous exercise, we identified kinds of software systems and some criteria by which software can be classified. This time, we will finish up the exercise by thinking about the kinds of criteria available to us.


  1. To build a framework of criteria for evaluating software systems.
  2. To think about how software relates to the world in which it lives.


Work in the same teams as you did for Exercise 1.

  1. Together, review the following list of criteria that I generated based on typical student responses to Exercise 1. Feel free to add any other criteria that you think are missing from the list.

    "One can view software systems in many different dimensions: ease of use, reliability, aesthetic value, complexity, robustness, learning curve, time to complete a (typical) task, portability, cost, maintenance, user support, hardware requirements, availability."

  2. Organize these criteria into groups. That is, place similar criteria into the same group and different criteria into different groups. Decide as a group what counts as similar. If one group is more like a second group than a third, describe that relationship in your solution.

    An example of how to group criteria: by the first letter of their names. Of course, this grouping doesn't shed much light on what the criteria mean.

    Do the same thing again using a different organization scheme.

At the End

  1. Turn in a sheet that lists your groupings and shows any relationships among them. Somewhere on the page, write a one-sentence description of the two schemes that your team used to group the criteria.

  2. Each group will present its findings.

Eugene Wallingford ==== ==== January 9, 2001