CSci 455 Group Project

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 (possibly) the use of the Oracle menu-building system.

Introduction

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 during 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. Last modified: Feb. 8, 1996 \newpage

Schedule

(tentative)

Required Documents

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. Listings should be printed on standard size paper and included in the document. "Bundles" of documents can not be accepted for full credit.

Requirements Document

Basic ideas

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\footnote 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., but it should be sufficient for our purposes.

Document Outline

Please use the following outline for your requirements document for the CSci 455 group project, adding to it as you feel appropriate.
  • Section 1: Introduction: Include a brief description of the company (make this up) and the problem for which the proposed system is intended to be the solution.
  • Section 2: Functional requirements: Describe the functions that the proposed software system is to perform. Include descriptions of the 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).
  • Section 3: Non-functional requirements: For us, this section will be used primarily to describe the sizes of the data set (use realistic sizes - not the (smaller) sizes that you plan on using in testing), number of users (again using realistic sizes), indicate which functions need to be done most easily, and describe the level of ease of use for each function.

    Design Document

    Basic ideas

    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): Furthermore, 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.

    Document Outline

    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. 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.

    User's Document

    Basic ideas

    Document Outline

    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.

    Source Code

    Basic ideas

    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.

    Document Outline

    Maintenance Document

    Basic ideas

    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.

    Document Outline

    Please use the following outline for your maintenance document for the CSci 455 group project, adding to it as you feel appropriate.

    Evaluation Document

    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.

    Journal

    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:

    Evaluation

    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 (These 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.

    Project

    Each group in the Spring, 1996 class will be given the same project: The creation of a portion of a registration system for the Hoh River College to be used by students in registering for courses.

    Description The Hoh River College is a small (about 1,000 student) college hidden along the Hoh river in the Olympic Peninsula. Registration up to this point has taken place using a punched card system, and the College would like to move to a database management system (Oracle). In order to do this, the registration system will need to manage information about There are some complications to the process. Feel free to add others, extracted from a study of the UPS catalog and Spring course schedule, but try to accommodate (as far as possible under the time constraints - some of these are difficult) the following: There are some characteristics that we would like the resulting system to have: We will do only a part of this problem. Our task is to write the part of the system that will display a form for a student and which will allow that student to register for courses. At the most basic, this will be a form-based problem. If possible, I will try and figure out how to use a WWW interface to Oracle (there are several around), which would be much more fun (but which would still incorporate a form).

    Please note that this represents an abstraction of the registration system as it exists. There are a number of complications that are not discussed in the above (look at the catalog for more details. At some point, I hope that we will be able to have a guest lecture by someone in computer services who will be able to describe some of the additional complexities.

    Groups I would like to try something new this term. Since I would like groups of three people, I plan to assign people to groups more or less arbitrarily as follows: Group accounts will be allocated as


    Return to Group Project Home Page