From the CSci 455 course syllabus...
The term project will involve a substantial effort in the specification, design and implementation of a information system using Oracle. The information system will include data entry/enquiry forms, embedded SQL code in C programs, the use of the Oracle report writer, and the use of the Oracle menu-building system.
Group projects are an integral part of several courses in Computer Science. While they have been used upon occasion in nearly every computer science course, they are almost always a part of the following three courses:
And, of course, the new capstone course in the BA/Computer Science degree.
Since software engineering is the discipline of developing large computer systems, a team project is always a part of that course. Group projects have been used very successfully in CSci 255 over the past decade, and have been introduced in CSci 455 beginning with the 1988 - 89 academic year.
Group projects give the students a chance to learn to work on a substantial software development project as a member of a programming team. While this is the norm for software development in industry, it is generally not the way students are taught to work in a University environment, since student work is normally evaluated with the expectation that the student has submitted the result of an individual effort. Group projects also give students the opportunity to work on much larger programs than would otherwise be possible.
In addition to the development of technical skills, group projects also give students the opportunity to further develop skills in oral and written communication. Students are required to write at each stage of the software development process, to report on progress throughout the term, and to make a final formal presentation to the class (and to interested faculty members in addition to the teacher).
Group projects also give students an opportunity to fail. While groups are usually successful, some groups do fail. These failures, when they occur, can sometimes be attributed to over ambitious projects, but can be attributed perhaps more frequently to individuals in the group who do not complete assigned work (thus increasing the load on colleagues), or to individuals who try to take on all the work themselves (and, being therefore greatly over committed, fail spectacularly). While this is never a pleasant experience, we try to build in enough safeguards that such disasters do not cause the failure of the efforts of the rest of the team. When disaster strikes, the original project can generally be restructured to salvage the work that has been done into a more limited project. Of course, this works only if the teacher monitors the progress of a team very closely - which is one reason for requiring progress reports and written documents at significant milestones in the project throughout the term. While we make every effort to avoid these disasters, they can be a very important learning experience for the students involved. Furthermore (and fortunately), failure in a classroom environment has a substantially less long- term career impact on an individual student than a similar failure in industry would have. In any case, although significant difficulties with the term project would probably have an impact on the final grade, difficulties with the final project no not necessarily imply failure in the course.
Written and oral communication are substantial components of the group project. In addition to enforcing standards of good programming style (including internal documentation), students are required to clearly explain how their programs work and how they can be used. These explanations involve both written documents and formal oral presentations, and are directed to both technical and non-technical audiences.
Students planning on entering a career in which they will be called upon to define, design, implement, test, and maintain large computer systems are also encouraged to take the software engineering course, CSci 340.
Last modified: Feb. 15, 1999
(tentative)
The software engineering process is generally very formal. In contrast to the development of a limited-use, short program written by one user, a software engineering project generally involves a number of individuals working over a long period on a product that is expected to be used for a considerable time. Part of the formality of this process is seen in the documents developed as the project progresses. Assessment of documents will include (but is not limited to) the following criteria:
Final copies of documents will be collected into a bound document (for example, flashback binding, available at the print shop) with a printed cover, title page, and table of contents. If you keep the table of contents current for individual documents, you can simply list the documents included and use tabs to identify each document. Listings should be printed on standard size paper and included in the document. "Bundles" of documents can not be accepted for full credit.
The requirements document is the starting point for the software engineering process. It can be thought of as a contract between the potential end-user of the system and the system developer. As such, it should be intelligible to both: the end-user should be satisfied that a system satisfying the conditions set out in the document will meet their needs, and the software developer should be satisfied that the requirements are complete, consistent, and sufficiently detailed that a system can be developed from them.
The following outline presents only a part of what would be a complete requirements document, but it should be sufficient for our purposes.
Please use the following outline for your requirements document for the CSci 455 group project, adding to it as you feel appropriate.
Remember that you do not need to put too much detail in at this point: For example, you might say that you want a data entry screen which permits the operator to add, delete, and modify information about customers, but you do not need to draw a picture of how you want the screen to appear (that will be part of the design process).
The design document for a program consists of an outline for the program. In the case of an information system we need to define a database structure together with the necessary forms, reports, and an occasional program to do something that forms and reports can not do.
In the following, seven issues of design are addressed (two of these may be considered managerial issues, but we will put them in the design document):
In the following, several items are marked (using an asterisk) as sections to be provided in a preliminary design document. The remaining items are to be included in the full design document.
Please use the following outline for your design document for the CSci 255 group project, adding to it as you feel appropriate.
Sections marked with an asterisk (*) are to be included in the preliminary design document.
Although your project may or may not include any programming in C or Pascal, you will probably use PL/SQL, particularly in SQL*Forms. These code segments should be considered modules.
Note that this is not the same as the database data dictionary.
Please note that the content of these documents may change during the development of the project - you are not restricted to decisions you make now. In a more rigorous project, you would need, however, to log any changes you make.
For this document, the outline is very much up to you. Begin with an introduction to the system, a tutorial if possible, followed possibly by a reference section.
You will probably generate more source code than you think that you will for this project. Although you may not have any SQL code embedded in a C program, you will generate PL/SQL code for forms and (possibly) for reports, and this is also the place for descriptions of forms and reports.
An important note: You should have sequential files with test data in them instead of planning on typing in all of your test data via your data entry screens. This is to avoid a substantial amount of work if some part of your system fails in development and your files are lost. In addition, you should have a series of control scripts available for reloading your test data. For our purposes, this, together with a description of the files in your system, will comprise the maintenance document.
Please use the following outline for your maintenance document for the CSci 455 group project, adding to it as you feel appropriate.
This is the most free format of all the documents, and may be only a page or two. Describe in some detail how much of your original project you have implemented. For those areas that were not completely implemented, say why you think they did not get done ("ran out of time" may be a reasonable response), and list the ways in which your project could be extended.
You are asked to keep a journal throughout the project. What I would prefer is a bound or spiral notebook, though a journal kept on a computer and printed out would also be very acceptable. If you keep your journal on individual scraps of paper, make sure that these can be bound together in some fashion in a binder to turn in periodically. What the journal should contain:
Together with a brief narrative of what was accomplished that week.
The group project will account for 20% of your grade. Generally every one in the group will receive the same grade, although adjustments will be made only in exceptional cases. Your project will be evaluated against the following criteria \footnoteThese criteria are adopted from those used in software engineering projects at the University of Wales, Aberystwyth:
Total: 100 points
The following presents a rough idea of the standards against which projects will be evaluated (subject to the constraints given above):
It is expected that, over the long term (several semesters), the majority of projects will be in the 70% - 90% range (C and B), with
as the marking scale for group projects.
Each group in the Spring, 1999 class will be given the same project: The creation of a registration and billing system for a small motel on the Hoh River.
The Hoh River Inn is a small motel with several classes of rooms (with/without fireplace, river view/no river view) with a check-in time of 3:00 PM and a check-out time of noon. It is a popular place, and so rooms are reserved by customers (from whom we need name, address, telephone number, method of payment, etc.). As an additional feature, you might want to assign staff to the desk and to room maintenance.
The user of the system should be able to make and change reservations, calculate and print bills, and get a reservation report for any day.
Please note that this is somewhat open-ended. There are some parameters (number of rooms, for example) that have been left unspecified. Please feel free to make these parameters up.
I would like groups of three people and plan to assign people to groups more or less arbitrarily as follows: