Introduction

The semester project for this instance of the class address the design and implementation of a pair of realted GUI based interface tools to work with the provided Data Streams post processing software. The two GUi based tools are related because a significant portion of the first's features are capabilites that will also be required by the second. The first is a fairly simple browser/editor for data source name spaces and their corresponding specification files. The second tool is a GUI providing a view of the available set of post-processing filters to the user and enabling the user to specify sequences of filters to apply, as well as the ability to configure the parameters of filters in a sequence. The unexpected turnover in the grader for the class, as well as other factors, delayed the availability of the post-processing framework software by a week or so, and we have thus decided to combine GP0 and GP1 in a modest way. The intent of GP0 was always modest, being restricted to a minor extension to the software based largely intended to ensure that each group would have to read and work with the software at or above some minimum level. At this point, I simply suggest that developing the human readable output format would be a good thing to do earlier rather than later. It will be a required part of the final software, but you will not have to hand it in in a formal way.

However, the purpose of your semester project is not to develop the definitive user interface for data streams post processing. The purpose is to expose you to a realistic design and implementation challenge. It is thus important for you to constantly devote a resonable portion of your time and attention to how you are working as well as what you are doing. Another way to make this point is to remind you that the major purpose of the class is to expose you to good SWE practice. How you do the projet is thus more important than what the project does.

One way to look at this the class projects is as a progressive broadening of your responsibilities through the EECS programming sequence:

  1. 168: Work with small problems representing specific programming and problem solving techniques.
  2. 268: Work with problems which require assembling three or four of the kinds of component solutions used in 168 into a solution for a larger problem.
  3. 448: Scale up to larger problems requiring the combination of a fairly large number of component problems into an integrated solution. Work in groups, and begin with a problem which must be broken into components before developing solutions to the components and assembling them into a solution for the problem as a whole.
You are thus faced with a new challenge. How to take a realistic problem, and disassemble it into components of size and character which are (or ought to be) familiar from earlier classes, and then assemble the component solutions into an integrated solution for the original problem. What you have done before is a component of this problem. Make sure you take advantage of techniques you learned in previous classes. However, the identification of the component problems in a larger problem is probably the most intuitive, and thus individual, aspect of software engineering. That makes it hard to do, and hard to teach, since everyone does it a little bit differently. Clearly you will have to start by learning something about the characteristics of the target domain.

In this case, you should consider plausible use scenarios for post-processing of data streams system performance data. You can improve your understanding of the target doamin by studying the supplied examples, by asking questions, and by simply thinking about the target domain. The target domain is quite simple in its essence. Files of data about the performance of an application or a system is available, so how can the user look for features of interest. A major type of available infromation is the "stream" of events that narrate what is happening in the target system. The user will want to look for the occurence of specific events or sequences of events in the data.

However, even if the target environment remains a bit boring do not lose sight of the realproblem; to gain experience with problem description, solution design, and solution implementation and documentation.

The individual variation in how people do software work is one reason why the composition of a working group is so important, and why assembling the right team is one of the most important responsibilities of supervisors in industry. Ideally a group should represent a range of individual talent wide enough that all of the skills required to solve all aspects of the assigned problem are present. Visionary inspiration and total command of detail are both required.

For this project, GP01, all you have to worry about is identifying the component problems as exemplified by the set of operations required to reach the customer's goals. Look at the problem. Study it from the top, bottom, left, right, and any other odd angles that may occur to you. Try ideas and scenarios out. Clear your mind and see what observations or ideas occur to you as you test a scenario. What does or might make this scenario hard, confusing, annoying, or stupid? How could it be made easier, obvious, pleasant, or educational? At first just write down anything that seems important without worrying about how it might relate to other things. This is the brainstorming phase. This is also, to a significant degree, what we have done a couple of times in class when discussing various possibilities and aspects of the problem.

Then, when you and the other members of your group have collected some individual items, discuss how they might be assembled into related or interacting groups. Iteratively assemble the ideas and assertions in a consistent set addressing all of the the customer's requirements, while also forming a coherent and well designed whole. Remember that at this stage you have to work verbally. Present your line of reasoning for consideration and criticism by the other members of your group. Formulate lists of questions for the customer, and present you line of reasoning for critique.

It may sound easy put this way, but it isn't easy for anybody; ever. It can, however, be tremendously fun and incredibly stimulating after you get used to loosening up and moving to the rhythm established by a group of people bouncing ideas off one another. Be inventive, think wishfully, and try to imagine how you are helping a hypothetical customer interact more effectively with the project's target environment.

Product Feature Set

A document soemthing like a customer might give you is available here. It is important to realize that, in fact, this document actually gives you a lot more information and specific requirements than many customers would provide. This is because I have a lot of software design experience and am trying to be helpful. Even so, there is a lot you have to design and implement for yourselves.

Customer Interview and Questions

The textbook discusses the fact that software engineers must exchange ideas about the problem with each other and with the customer to educate themselves (and the customer!) about a problem. That means you should read this information, think about it, react to it, try the tools and think about them and this some more, and then TALK WITH THE MEMBERS OF YOUR GROUP!

Realize that it is your responsibility, as the software engineer, to make sure you understand what the project requirement, and not mine, as the customer. As a software engineering student you are supposed to be learning how to analyze a problem in this way, and I cannot tell you what questions to ask without doing a hard part of the problem for you and defeating the purpose of the exercise. Bring questions about the target problem to class.

What to Hand In

GP1 will produce a document combining, in the interest of time, the requirements and specifications. While working on this document your group should also be building a rapid prototype (RP) reflecting your ideas. Ideally you would be able to show the RP to the customer and receive feedback which you could take into account by changing your document. Time pressure of the semester format dictates that you will hand in the document and the RP at the same time. In the customer interactions we have, as a class, determined which of the desirable ideas within the target feature areas deserve more careful study and which should be deferred. Then The requirements and specifications document produced by your group will have three sections: overview, data flow diagrams, and a discussion of each of the features, including some idea of which should be pursued and which should be deferred for later development. Your discussion of whcih features to pursue and which to defer should be based on an honest assessment of what you think it will be feasible to design and implement.

There is no minimum or maximum page count, but each report must clearly communicate the relevant information at an appropriate level of detail. In previous semesters this has typically required approximately 15-20 pages, depending on the conciseness of the rhetoric and the size of the diagrams. I have placed some representative example of project notebooks on reserve in the engineering library so you can get a feel for how to approach this, but remember that since your problem is to communicate, you must use your best assets to communicate clearly. Your approach will thus be different from that of others

The overview section should discuss the problem domain, describing the general approach your group plans to take to each problem, and a reference to the data flow diagrams illustrating the approach. This discussion should reflect your comprehension, opinions, and development of the discussion presented here, not a transcription of it!

The data flow diagram section should include a diagram for each major feature at an appropriate level of detail. There is no single standard for how detailed this has to be. Either extreme is bad. Too simple and the diagrams do not say enough. Too complicated and they say too much, so that no one can figure them out.

The third section should discuss which features and operations you plan to implement, which you do not, and why. This should include some initial estimate of how hard each implementation would be an why to support your decisions. This is an initial aspect of the planning you will do in detail in GP #2, since you must make some estimate of how much your group can handle in the time allowed.

The report should be typeset on a word processor. Ideally you should be handing in a Postscript file containing the final text of all your project documentation. However, not every student has access to systems that can do this, or knowledge to make it happen, so: hand drawn diagrams are acceptable, but all diagrams should be neat and easily legible, and since you are likely to want to use the diagrams again, diagrams done using a drawing program or screen shots (try the gnome-panel-screenshot command) are preferable. Realize that data flow diagrams reflecting the actual implementation may be useful as part of the final report. Note that if you take screenshots, there are options to capture a single window shot as well as the whole screen. It is also fairly easy to crope a window image out of a full screenshot with the "gimp" image processing tool.

I would say it is possible to both over and under estimate the difficulty of the assignment. Treat it too casually and you will do a bad job. However, if you dive into details too early you can lose sight of the problem as a whole, and get lost.

Does all this seem under-defined, over-hard, and generally annoying? Well, yes, it is. However, that is the state of this craft, which is one reason I think it is exactly that - a craft. Neither science nor engineering is quite this messy, but this is the way AWE really works. Welcome to Software Engineering!