CSci 455 Group Project Spring 2004

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:

• CSci 455: Introduction to Database Management Systems
• CSci 340: Software Engineering
• CSci 460: Senior Project

Since software engineering is the discipline of developing large computer systems, a team project is a natural 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. 18, 2004

Schedule

(tentative)

• Week of 2/9/2004
  • Wednesday: First discussion of group project
  • Friday:  Informal project proposals
• Week of 2/16/04
• Wednesday: Further discussion on the group project
• Week of 2/23/04
  • Wednesday:  Formal Project Proposal
• Week of 3/8/04
  • Requirements Document due (Monday).
• Week of 3/15/04
  • Spring break: no classes
• Week of 3/25/02
  • Monday: Status reports. Status reports are informal reports given at the start of the class session.
• Week of 3/22/04
  • Friday: Preliminary design document due
• Week of 4/12/04
  • Friday: Design Document due
• Week of 4/26/04
  • During the week: Arrange individual sign-of meetings with me. These will take about half an hour each, and you should be ready to demonstrate what works, what does not, and answer questions.
• Week of 5/3/04
  • Formal presentations
• Wednesday, May 5 (last day of class)
  • All documents due 5:00 PM. Documents may either be turned into the departmental secretary or brought to the student picnic (assuming that I'm there).
• Week of 5/13/02 
  • Final Exam Friday, May 14, 8:00 AM

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:

• Accuracy
• Completeness
• Adherence to standards (see below)
• Clarity of expression
• Organization
• Quality of writing, including sentence construction, spelling, etc.

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.

• Table of contents
• Section 0, including
  • Purpose of document
  • Change history (date/change/reason)

Formal Project Proposal

The following is extracted (copied, mostly) from Sommerville, Software Engineering, 6th edition, pages 76 - 77.

• Section 1:  Introduction.  Describe the objectives of the project.
• Section 2:  Organization:  Describe how the team is organized, and what roles individuals play.
• Section 3:  Hardware and software resource requirements.  This should not include anything not currently available on-campus unless you have access to client resources (in which case these resources should be named and your access to them described).
• Section 4:  Work breakdown:  Break down the process into subtasks, assign responsibilities, and set milestones (dates that can be tracked).
• Section 5:  Project schedule.  Consider using the scheduling tools available in VISIO.
• Section 6:  Monitoring and reporting mechanisms.  Include the date for scheduled milestones (requirements document, design documents, etc.) and add any additional milestones or events you have scheduled above.  (sections 5 and 6 may be combined).

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, 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 or organization (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
  • Data to be stored,
  • Operations to be performed on that data, and the
  • User interface
    • Data entry/enquiry screens
    • Reports

  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. This might also be a good place to address security, if that is an issue.

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):

• Database Design
• Data Flow
• Forms Design
• Report Design
• Module Design (where appropriate)
• Team Structure
• Configuration Management

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.

• Section 1: Introduction (*): An overview of the system design in narrative text.
• Section 2: Entity-relationship diagram (*): A detailed Entity-relationship diagram listing
  • Entities
  • Attributes
  • Relations
  • Type of relationship (one-to-many, many-to-many, optional, mandatory, etc.)
  • Relation definitions arising from the E-R diagram.
• Section 3: Bottom-up database design (*): A set of relation definitions arising from an analysis of the forms and reports. While it would ordinarily not be appropriate to include the work involved in developing these relation definitions in a design document, I do want you to include that analysis in this document. Please include all steps. Include an Entity-Relationship diagram resulting from the bottom-up design (new: added 3/22/2001)
• Section 4: Resolution and final relation design(*): In this section, perform an analysis of the conflicts between the bottom-up and top- down design (there should be some), your resolution of these conflicts, and a final database design in the form of
  • A final entity-relationship diagram.
  • CREATE TABLE statements (with definitions of all fields, and justifications for the use of NOT NULL statements).
  • CREATE INDEX statements, with justification for all indexes together with justification for any indexes not placed over primary or foreign keys.
  • Any CREATE VIEW statements.
• Section 5: Data Flow Diagram (*) An abstract data flow diagram that is reasonably complete.
• Section 6: Functional Decomposition (*): In this section, break the system down into functional elements. For example, a customer information system would include functions to add, delete, and modify customer records, validate input, approve charge purchases, accept payments, etc. You may find it easiest to think of this as a way of organizing menus if your project is menu-driven.
• Section 7: Module Definitions (if any): Think of this as a collection of assignment write-ups for programs. For each module described, identify a functional element it belongs to (and how it belongs). The level of module definitions should be driven by the following: would you be happy with an exercise write-up that had this level of detail?

  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.

• Section 8: Module Design (if any):
  • Module Purpose and Description (narrative)
  • Pseudo Code
• Section 9: Data Dictionary: For each field in the database,
  • Name
  • Data type
  • Description
  • Where defined (tables)
    • Specify primary/foreign key
  • Where set (forms/programs)
  • Where used (forms/reports/programs)

  Note that this is not the same as the database data dictionary.

• Section 10: Forms and Report Descriptions (*): Describe the forms and reports to be used in your system.
• Section 11: Test Plan: This section should include a plan for testing the completed system. Tests should be divided (for this document) into two categories:
  • Interface testing
  • System Validation Testing
• Section 12: Configuration Management (*): Since several individuals will be working on parts of the program, say how you plan to make sure that you don't get in each other's way, and how you plan on agreeing to changes in the design or implementation.
• Section 13: Team Structure (*): How is your group organized? How are tasks allocated? Who has been assigned what tasks? In particular, who is responsible for what part of the system? (I will need to use this during grading).

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. Note that you might also have some Java code if you use the Oracle JDBC

Document Outline

• PL/SQL, Java or C language source code (if appropriate) Include a general introduction to the source code, and then present the source code program by program with a brief narrative introduction to each program saying what the program does, where it fits in, and who wrote it. If you do not have any source code in PL/SQL,  Java or C, put a note to that effect in this section.
• Forms description
  • Form description (using the Oracle tools).
  • Picture of a sample form
  • Annotated PL/SQL code segments
• Reports description. Include descriptions (generated by Oracle) of reports, and include enough of a sample report that the reader can see what is going on.

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.

• Section 1: Introduction: Include your group account number and a password to the account and to Oracle. Include a description of any files in the account not described in the following.
• Section 2: Description of tables: List each table by name together with a brief (one sentence) description.
• Section 3: Description of programs: Include a list of any programs, and map these source listings to the module descriptions in the design document.
• Section 4: System installation: List the sequence of steps necessary for building the system. This is best done by giving an \em annotated control script of CREATE TABLE/INDEX/VIEW statements.
• Section 5: Test control scripts: List and describe the control scripts written for loading the data files, the sequential files of test data (with descriptions), and instructions for loading for doing so. This might also be a good place to document backup/recovery control scripts.
• Section 6: Anything else you feel you should add

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:

• A log, kept up at least on a weekly basis, of your work on the project. List your work by categories (design, requirements, writing, meetings), and say (roughly) how much time was spent on each task. I will provide the form for this later this week.
• Your own thoughts about the project. These can be divided up into technical musings (explorations of alternate design options, etc.) to your own reactions to the project (this week things went really well/rotten, etc.)
• Anything else you want to add. I will read your journals, but will not pass them on to anyone else. If there are parts of your journal that you would prefer that I not read, paper-clip the appropriate pages together with a note.
• The only required part of the journal is the record, on a weekly basis, the time you have spent with the project, grouped by
  • meetings
  • reading
  • design
  • implementation
  • testing
  • writing (documents or other)
  • any other task you want to keep track of

  Together with a brief narrative of what was accomplished that week.

• You may want to use the following to record time (or something like this):

Date (wk beginning)	Meetings	Reading	Design	Implement	Test	Write
2/18
2/25
3/4
3/11
3/18
3/25
4/1
4/8
4/15
4/22
4/29
5/6

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 (modified from SWE project assessment, University of Wales/Aberystwyth):

• Technical Achievement: 20 points. How much was achieved given the level of difficulty of the project?
• Quality of product: 20 points. An overall assessment of the project quality (given the constraints).
• Quality of Specification: 20 points This item refers to the quality of the content of the documents. Evaluation of the quality of writing, etc. is addressed in the next item.
• Quality of Documents (including the journal): 20 points
  • Adherence to published standards
  • Quality of writing
  • Quality of explanation
  • Quality of presentation
• Organization and Management: 5 points
• Final Presentation : 15 points The presentation should be formal. Allow 15 minutes for your presentation, with a few minutes to answer questions. The presentation should give listeners an understanding of
  • The goals of the project
  • The design of the project
  • A short example of the use of the project (can not be extensive)
  • A discussion of interesting approaches, problems, etc.

Total: 100 points

The following presents a rough idea of the standards against which projects will be evaluated (subject to the constraints given above):

• Projects meeting minimum standards in a category (Tables reasonably designed and defined, loaded with data, reasonable indexes, programs run with perhaps some errors, some documentation, documentation set complete and readable, etc.): 60% - 80%.
• Well designed and implemented tables, complete, well written and running programs, problems clearly documented, complete and well written documentation adhering to standards: 80% - 90%. Please note that not everything needs to be working to achieve a grade in this range (although that would certainly help, and in general the more elements of your system that work the better are your chances of a good grade)
• Projects earning 90% or more will be those that are (given the projects limited scope) of a professional quality in each of the areas described above.

It is expected that, over the long term (several semesters), the majority of projects will be in the 80% - 95% range (C and B), with

• 90% - A
• 80% - B
• 70% - C
• 60% - D

as the marking scale for group projects.

Projects:

Group Projects Spring 2004

• Group 1
• Team Members:
• Christopher Foulston
• Westley Rowe
• Proprietary Resource for Educational Progress (PREP)
• Group 2
• Team Members
• Amy Bechtel
• Geoffrey Gariando
• Michael Cramer
• Project:  Selling computer parts.
• Group 3
• Team Members:
• Craig Brunner
• David Conger
• Justin Quevedo
• Project:  Digital Music Logging System
• Client:  KUPS
• Group 4
• Team Members: 
• Jason Fieman
• Kristle Pegler
• Patrick Karjala
• Paul Tidmarsh
• Project:  OIS Knowledge Base
• Client:  OIS
• Group 5
• Team Members: 
• Lee Jahncke
• Joel Smith
• Ryan Yamada
• Jason Person
• Project:  Graph Theory Data Base
• Client:  Peter Puget
• Group 6
• Team Members: 
• Steven Klon
• James Lakin
• Ryan Kolp
• Morgan Johnson
• Project:  Book inventory system
• Group 7
• Team members
• Mo Ojala
• Philip Edry
• Project name:  ModTIME

Groups projects Spring 2002:

• Group 1:
  • RMroczek (S02), BKunst (S09), RBancroft (S03), VWong(S08)
  • Mroczek Brothers Auction
• Group 2:
  • JTillett (S04), IWHoyt (S07), TLarkworthy(S25)
  • GIS Application
• Group 3:
  • JMarenkova (S05), RMacDonald (S26)
  • Educational Application (History of the Olympic Games)
• Group 4:
  • RTyler (S10), JJaworski (S11), JGreves (S12)
  • Hotel Reservation System
• Group 5:
  • NWilson (S13), NChang (S14), GZou (S15)
  • Last Stop Internet Solutions Inc.
• Group 6:
  •  BJohnson (S19), MOjala (S18)
  • Wine database
• Group 7:
  • ZCapehart (S16), LHonbo (S20), GHatayama (S21)
  • Used Book Exchange
• Group 8:  
  • JKamrath (S22), DNag (S23), RTruell (S24)
  • Tacoma Youth Symphony Association
• Group 9:  
  •  AColeman (S17)
  • Senior Project Group
• Group 10:
  •  JAbdul (S28)
• Group 11: 
  • KShinohara (S01), GGililland (S27)
  • Bertolino's Cafe

Order of group presentations:

The order of group presentations for Spring 2004 will be:

• Group 4:  OIS Knowledge base
• Group 1:  PREP
• Group 7:  ModTIME
• Group 6:  Book Inventory System
• Group 5:  Graph Theory Data Base
• Group 3:  Digital Music Logging System
• Group 2:  Computer Parts Database

The first four presentations should be scheduled for Monday, the last three for Wednesday to allow time for return of Exam #3 and for a brief word about the final exam.