CSci 340 Group Project


The group project in CSci 340 will account for nearly a third (30%) of your grade for the course. It will involve the specification, design, and implementation of a small project. 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 425: Networking
  • CSci 460: Senior Project


Since software engineering is the discipline of developing large computer systems, a team project is always a part of this course. 

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, where 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 overly 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 sufficient safeguards that such disasters do not cause the failure of the efforts of the rest of the team (and your teacher should be promptly informed if this starts to happen). 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.

One of the primary differences between group projects such as the one in this course and programming exercises in other classes is that the process of software engineering is a formal process involving not only the delivery of a final product but also the timely delivery of a variety of documents and a formal final presentation. Although the precise form and number of the documents to be produced vary from project to project (depending on the type of project and the software development model used), there are several documents that are required for all projects (please note that these are adapted from current requirements for the senior project). All of these documents (with the exception of the project logs and journals) should be considered public documents.

All documents will begin with a standard set of sections, as follows:

  • Document Title
  • Authors (group member names and email addresses)
  • Purpose of the document
  • Change history
  • Table of contents
  • Introduction

 

  • Informal Project Proposal: This should first be in the form of an email to me giving me the names of the team members, the project that is proposed to be done, and the name of the client (if any). This informal proposal will be reviewed by me, and will then be followed by a more formal written proposal (see below) which should also have the agreement of the client, and which will form the basis for the requirements document. This informal proposal does not need the standard set of sections described above.

    All documents (except for the first informal proposal) must be printed (using a word processor) and submitted on paper. Email submissions can not be accepted (except again for the first, informal proposal).  All documents (beginning with the formal project proposal below) must be included in the final submission.

  • The Formal Project Proposal is the first formal document due for the group project.  The project proposal describes the project to be undertaken, how the group is to be organized, how the work will be divided up, the resources that will be used, the risks involved,   For the outline for the document, please follow the one given in section 5.2.1, pages 97-98, of our textbook.  Please notice that part of section 7 (Monitoring and reporting mechanisms) will be constrained by what follows in this document.

  • Requirements Document: The requirements document is a statement of a problem and a description of what is needed to solve the problem. The outline to be used for the requirements document (incorporating the functional specifications) will be given here (adapted with slight modification from the generic requirements document given on page 139 of Sommerville)

  • Design Document : Group projects will vary greatly in the tools they use to solve the problem before them. Some projects will require significant amounts of programming, some will include the design and implementation of a database, and others will build a system from other tools. Since this document will differ from group to group depending on the problem, the approach, and the tools used, the form of this document will be set primarily by the group. Some general guidelines for the design document can be found here

  • Implementation Document: This is the place to place annotated program listings, if your project has them. It is also the place to place descriptions of Oracle forms, reports, PL/SQL or VB code, and menu descriptions. This can be the place to put important things that don't fit anywhere else.

  • User's Document: It is expected that a group project produce a system which will be used by your client. The user's document should explain clearly to a non-technical user what the system can do and how to do it.

  • Maintenance and Installation Document: It is expected that over the useful life of the product it will be necessary to make changes to it. It may also be necessary from time to time to rebuild it. This document should describe all of the parts of the system, how they fit together, and how the system can be reconstructed from its parts.

  • Meeting Logs and Journals: Each meeting of the project group should be minuted (who was there, what issues were raised, what decisions were made). The minutes should be formal, and should be collected in one document.  I may ask to see the minutes from time to time.

    Each member of a project group is expected to keep a journal throughout the project either as a spiral notebook or a document on a computer. It should contain a weekly time sheet of your time spent on the project. List your work by categories (design, requirements, writing, meetings), and say (roughly) how much time was spent on each task.  Again, I may ask to see these time logs (which are individual logs, not group logs) from time to time.

    In addition, your journal could contain 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.)

    The journal may contain anything else you want to add. Your instructor may read your journal. If there are parts of your journal that you would prefer that your instructor not read, paper-clip the appropriate pages together with a note.

  • Client sign-off This should be a brief, one-page document signed by your client saying that the project was completed satisfactorily. There should be an opportunity for the client to note things that need more work, and things the client would like to see added (this may form the basis for another group's project).

  • Project evaluation This section should be your group's evaluation of the project. You should describe candidly what worked, what did not, how problems you encountered were or could be corrected, and how your project could be extended. It is important that this section be both thorough and comprehensive.

Outlines for these required documents will be made available as we need them.

You should decide on some form of configuration control for the documents produced by your team. Each document should include a revision history indicating the changes made to the document and the reasons for them. When configuration control begins depends on the document. For the proposal and requirements documents, configuration control begins when the client has approved the initial document, and any changes should be made with the client's approval. With the remaining documents, configuration control should begin when the document goes into use (as, for example, the design document).

Finally, please note that your project may contain something that does not fit into the above. You should be careful to make sure that it is included, as evaluation of group documents depends only on the material provided, the presentation, and an optional sign-off meeting. As an extreme example, if your project includes code of some sort (C++, Java, PL/SQL, VB, etc.) and that code is not included, you may receive fewer marks for your project than you would have received were it included. Please be sure that your project documents give a complete picture of your project.


Some previous Projects

A list of some previous projects can be found Here.



Schedule

The schedule will be incorporated into the Lecture Schedule


Evaluation Criteria

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)

Quality of product: 45 points.

Your readers will make an overall assessment of the quality of your project including how much was achieved given the level of difficulty of the project, the quality of the program, and the quality of the user interface. For a group project, this will include an assessment on how well you were able to work together,  how well tasks were allocated and problems resolved and how professional you were as a group. 

Quality of Specification and Documentation: 45 points

Your readers will make an assessment of the quality of the documentation and of the code produced. This evaluation will include:

  • Adherence to published standards
  • Adherence to usual standards for program code
  • Clarity of expression in code and in written documentation
  • Quality of writing
  • Quality of explanation
  • Quality of presentation

A significant penalty will be assessed for late or incomplete documentation.

Final Presentation : 10 points

The presentation should be formal and professional. Allow 10 - 15  minutes (the length will depend on the number of groups, and you will know more precisely well in advance) for your presentation, with some time 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.

If the presentation is done using power point slides, a copy of the slides (in handout form) should be provided at the time of the presentation.  Printed copies of other transparencies, diagrams, etc. used in the talk should also be provided.

Total: 100 points


Some Resources

Here are some resources which may help, including details of document requirements in other courses.

Fall 2004 Groups

  • Group 1
    • Pete Cameron
    • David Conger
    • Will Schindler
    • Project:  On-air Radio Broadcast Client
  • Group 2
    • Rachel Flodin
    • Anthony Hodson
    • Frank Prince
    • Project: Web Registration System
  • Group 3
    • Wes Kretzschmar
    • Andrew Miles
    • Matt Murray
    • Project: ResNet Student Employee Gateway
  • Group 4
    • Ben Johnson
    • Kelly Brunson
    • Matt Johnson
    • Sam Pierce
    • Project:  Calendar-based Scheduling System

Presentation Order:

  1. Group 4 (Calendar-based Scheduling System)
  2. Group 1 (On-air Broadcast Client)
  3. Group 3 (ResNet Student Employee Gateway)
  4. Group 2 (Web Registration System)


Return to the course home page