Session 1

Introduction to Software Systems

810:171

Software Systems

Exercise 1: Beginning to Understand Software Systems

Goals

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.

Tasks

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:

• I will do little or no lecturing. I will sometimes introduce a topic; I will often summarize the results of an activity at the end of class; I will always try to answer any questions you have; I will even comment on issues that you think are germane to the course. But I do not plan to lecture.

• We will do a diverse mix of exercises in and out of class. The out-of-class exercises will often be called "homework" and collected and graded at a later date.

• We will integrate the various themes of the course throughout the semester. Knowledge and experience do not reside in easily-labeled compartments, no matter what your school experience tells you.

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.

• It turns out that this second goal is really part of achieving the first! Each individual is responsible for his or her own learning. You don't learn what the professor lectures; you learn what you do and what you integrate into your existing knowledge.

• As mentioned earlier, we will do a diverse mix of exercises in class. These exercises will require you to do something, often in conjunction with a group of classmates, and then reflect on the result and the process that led to it. We'll try to do different things. If there is something that you'd like to see us try, please let me know!

• This approach may seem uncomfortable at first. What is different is often threatening. When doing problems in the absence of a preceding lecture, you will occasionally feel lost. Be assured that lecture is usually a worse alternative. You can usually learn the same material as well by reading it and studying it. But then you are stuck doing homework problems at home, in isolation -- and you'll sometimes feel lost. It is sometimes more comfortable to be lost all alone, but it is rarely more productive than being lost together.

• This approach places different burdens on you and me than the more traditional set-up.

  • You must read -- really read -- assigned material. You must wrestle with it. You must come prepared to discuss what you do and don't understand about it. You must ask questions, of me and your classmates. You must participate actively in class exercises, in the spirit of trying to learn something and not in the spirit of "just getting it done".

  • I must read -- really read -- assigned material. I must wrestle with it, trying to tease out key points and processes. I must prepare insightful exercises that give you enough guidance to be educational but also enough flexibility to be useful to you, in your current state of knowledge, and everyone else, in theirs. I must be prepared to answer many questions of fact and opinion. I must be able to help you find answers to questions of fact when I do not know the answer. I must be able to help you find a way to experience issues for which their are no pat answers. I must serve as a consultant in class and pay attention to your work without trying to "give away" answers.

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.

Goals

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.

Tasks

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.