CSci 340 Group Project

• CSci 255: Introduction to Business Data Processing (less frequently now than in former years)
• CSci 455: Introduction to Database Management Systems
• CSci 360: Software Engineering

And, of course, the new capstone course in many Computer Science contracts.

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

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 as well). All of these documents (with the exception of the project logs and journals) should be considered public documents, and will be shared with your colleagues in the class via a group web page

• Project Proposal
  
  This should 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. This informal proposal should have the agreement of the client (who should be copied on the email), and will (after review) form the basis for the requirements 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) is given here (adapted with slight modification from the generic requirements document given on page 69 ofSommerville)

   

• 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

   

• 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. If the project requires some programming (but is not primarily a programming project), then this would be a good place to place annotated program listings. It would also be a good place to place descriptions of Oracle forms, reports, and menu descriptions. For projects that are primarily programming projects, however, separate documents may be more appropriate for code listings. 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.
  
  Each member of a project group is asked 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.
  
  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 journals, but we will not pass them on to anyone else. If there are parts of your journal that you would prefer that we 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 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.

   

• Group Web Page
  
  This document is no longer required

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

• Overall quality of project: 20 points
  This is an overall qualitative assessment of the quality of the project, given its difficulty. That is, a difficult project that achieves most of its goals might possibly be marked higher than an easy project that achives all of them. In approving projects, of course, I try to make sure that they are of comparable difficulty.
  
• Quality of specification: 15 points
  This is an assessment of the material in the requirements document (as contrasted with the format and writing in the document itself, which is assessed under "quality of documentation"
  
• Quality of design: 15 points
  
• Quality of implementation: 15 points
  This will result from a review of code, database routines, web page sources, etc.
  
• Quality of documentation: 20 points
  This includes:
  • How well organized and how well written the documents are.
  • How well the documents adhere to the published standards
  • How well deadlines were met (this will be given a significant portion of the grade in this area)
  • Completeness.
  The final document submission should be in one or more (fewer is better) BOUND documents (feel free to use the "fastback" binding used for the class notes and available at the printing shop).
  
• Presentation: 15 points

• Admissions Web Page
• Financial Aid Web Page
• Behavior Suite (robotics)
• Basic E-R Tool
• Basic DFD Tool

• Senior Project
• CSci 455 Group Project