In this lab, you will work in groups of two or three to create various analysis and documents for the Music Scheduling System: a problem statement and glossary, a requirements analysis, a set of web page mock-ups, and an object-oriented domain analysis. You will work on these artifacts in succession, and I will ask you to submits parts of them as you are working through.
While doing this, I am going to insist that you put these documents together in a well-organized manner. This means that the documents will organized in a logical manner within a single working directory. Since it is also important to display your analysis and prototypes to your clients, I will want you to organize these documents as web pages. In order that you do not have to create this from whole cloth, I am making the MCS-Advisor Project Website, which was created by a group from a previous iteration of this course, available as a model.
Additionally, you will learn to use two particular tools that will
make the maintenance of these documents relatively easy; this is
especially useful since you will be working individually within a
group setting. These two tools are CVS (Concurrent Versions System),
and open-source version control system, and make, a GNU utility for
maintaining a group of programs. Although you might wonder why you
would use make when there are no programs yet to maintain, the reason
is that you will even at this stage be able to install the web
documents within your www-docs directory.
Look at MCS-Advisor Project Website and see how they organized their project page to display the documents. Your first task is to create do a Requirements Analysis for the Music Scheduling System; this should consist of a Problem Statement, Glossary, Use-Case Models, and Use-Case Descriptions. The Glossary is not described in our textbook, but is fairly clear: you are explaining the terms being used. The others parts are explained in fairly great length in the textbook; be sure to refer to the textbook when working on this part.
Regarding use-cases: be sure to include both Use-Case Models, which pictorially describe and organize the many use-cases in your system, and Use-Case Descriptions (like on page 134 of the textbook), which elaborate on the individual use cases. Note that the MCS-Advisor group did the use-cases as plain text, which I think was a good choice, since it is easy to do and fine to read. Scenarios are useful in the more complicated use-cases. Also, try to include exceptions, where appropriate.
Now is the time to time to organize your directory and read about and use CVS and perhaps gmake. In particular, read through the CVS page, which is structured as a lab, and set up a repository for your project.
Your next task is to create mock-ups for the web pages for the Music Scheduling System. Fortunately, you have started this in Lab 2. You should again refer to the Music Department Scheduling System site that I put together for you in Lab 2, and consider how you might improve upon the navigation as well as the general look and feel to address the complaints David Fienen had, as well as problems you can uncover.
When you have finished this portion of the lab, you should be able to describe the applications function pretty well to the client. You will probably also uncover some incomplete details in the use case you did. Since we are using an iterative approach to design, be sure to update the use-cases where needed.
After completing task 4, I want you to email me that you have gotten to that point. I will update my copy of your files and see how you have done.