CMPT 376 (Spring 2008): Assignment 4—Describing a process

Revision history

Due

Turn in

Rubrics (will become links when available)

Writing goal

Select a process that arises in computing science and describe it. Because computing is a design and engineering discipline, processes arise all the time. Examples include resolving a page miss in virtual memory, the stages in a POSIX pipe script, compiling a programming language, the steps of a sorting algorithm, or the cycle of an agile development method. A process is characterized by a series of steps performed by an agent or a series of stages through which some data passes. For example, in an agile development process, a developer might do four steps: write user stories, develop one incremental feature, do an integration test, and check the feature in to the production system. An email message passes through stages on its way from sender at SFU to recipient at Gmail: in the sender's outgoing mail queue, in the SFU server's outgoing mail queue, in the Gmail incoming server, in the recipient's inbox queue.

Processes are superficially easy to describe but can be hard to describe well. The easy route is to simply churn through the steps one at a time, inviting the reader to envision themselves as performing the steps themselves or being the object the steps are performed upon (perhaps not a good identification if you are describing the steps of sewage treatment). But this approach is ultimately writer-centered rather than reader-centered.

A reader-centered approach seeks to maintain the reader's interest, and the reader's interest is often not focused on the first steps. The preparatory steps are often the least interesting, however vital they may be for ultimate success. As a chef, are you fascinated by techniques for chopping vegetables or would you really rather read about simmering the main course? If you were writing a cook book, you would probably want to tease the reader with the interesting part before chopping through the details of knife-meets-zucchini. Perhaps a photograph of the whole meal, together with an opening paragraph describing its taste.

A reader-centred approach may also require starting with ideas familiar to the reader and moving to unfamiliar readers. Once again, the reader may only see the need for preparatory steps after later steps have been described. Returning to the agile development example above, the step "write user stories" may seem unecessary or perhaps the reader agrees on their need but doesn't see what details to include, only becoming clear to the reader when they see how the stories will be used in actual development. Thus the writer may choose to begin by describing development and only then backtrack to describe writing user stories. (This technique is also used in literature.)

Selecting a process to describe

You may pick any process that falls under the large heading of "computing science". It does not need to be a topic in a course you are taking this semester, and in fact does not need to be a topic in any course you've taken. It could just be something that interests you.

Some processes make better topics than others. You'll need something with rich detail to sustain this many pages of description. Large topics such as "software engineering" are likely too abstract. Indeed, "software engineering" itself isn't a process, but a collection of processes such as development cycles, testing strategies, estimation procedures, and so forth. Very small processes only rarely have the same problem of insufficient detail. Almost any technical topic has enough complexity to fill several pages. Although you should be careful not to pick a process that is too small, the greater risk is to pick a topic too large.

Processes are natural candidates for description by diagram. Your final description must include at least one diagram, and your text must be organized around the diagram. You may wish to include several diagrams. For example, you might wish to show a system's progress through several stages, with a separate diagram for each one.

Diagrams do not count towards your page count.

Audience

Goal and structure of draft

As with any writing, you will choose the order in which you make your points based upon your understanding of the audience, the structure of the material, and what the audience expects and already knows about the material. It is best to try out several different approaches before selecting your final sequence. Chances are, as soon as you imagine describing this process, you think of a "natural" way to describe it. For the draft, I want you to consider several "less natural" alternatives. These will give you some insights into your final presentation.

There are several strategies you might use for describing a process:

• Describe it as a series of steps: First this happens, then that, and finally this other thing.
• Describe it as movement through a series of locations: Start here, then go there, then go this third place. In computing science, the "locations" are often data structures rather than physical locations.
• Describe it as a series of human or machine actors: First this person works on it, then this person, finally this one.

Example of the three approaches

Consider the POSIX pipeline

tr '\n\t' ' ' | tr -s ' ' | tr ' ' '\n' | sort

The example pipeline is too simple to require much descriptive detail. I needed something short enough to describe three times in a row. With a richer process to describe, the differences between the descriptive approaches would be more dramatic.

Format of draft

For your draft, describe your process using the three different approaches to sequencing the points. Include a different diagram for each approach. Organize your draft in the following structure:

1. Describe your intended audience. Write this section in italics. You only need one paragraph.
2. Name the process you are describing. This should only take a sentence.
3. Describe the process as a series of steps. Include a diagram.
4. Describe the process as a series of data structures or locations. Include a second diagram.
5. Describe the process as a series of actors (human or machine). Include a third diagram.

It is likely that one of the organizations will seem strained. That's fine. The goal of the draft version is to (once again) get you to look at your topic through several lenses, seeing different details each time. For the final version, you will likely pick elements discovered by each approach.