Project Description for CS 3302, Section B - Introduction to Software Engineering

General Project Description

CS 3302B, Introduction to Software Engineering, Fall 1998


Table of Contents

Introduction

The purpose of the project is to walk you through the major phases of a software engineering task and to familarize you with the some of the more common methods, technologies, and tools used in software engineering. This page describes the project's general procedures; see the informal requirements description for the system to be implemented.

The project is structured as the course is: it will go on throughout the term and is broken up into five sections representing the five major phases of a software engineering task. Each section requires a deliverable, which will be graded; the grade for the project is made up of the average of the grades for the five deliverables.

Groups

The class will be broken up into groups of five, with the possible exception of one group that will have less than five members. Group members do not get to choose their group; they will be assigned groups by the instructor. Transfers among groups can only be done by the instructor, which he generally will not permit. However, a group with no programmers or with more than one graduating senior should talk to the instructor about fixing the situation.

Each person in the group will take one of five roles for the length of the project. The five roles are: requirements analyst, system designer, system implementor, quality assurance, and project manager; note these roles correspond to the five major phases of the software engineering task. Initially, roles are assigned to group members arbitrarily by the instructor, but these may be changed by the common consent of the group members involved. There is one restriction, however, in assigning roles: graduating seniors cannot be managers.

During each project phase the group member with the corresponding role becomes the group leader. The group leader is the point of contact between the group and the client (a.k.a. the instructor) and is responsible for getting the report in on time.

Reports

Each two week phase ends with a report:
PhaseReportDue Date
RequirementsRequirements Specification (template)9 October
DesignSystem Design Document (template)23 October
ProductionRevised SDD and code6 November
ValidationSystem Test Document (template)20 November
ManagementSoftware Project Plan (template)4 December

Reports can be handed in on paper or submitted via e-mail; reports submitted by e-mail should be either ASCII text or PostScript. If you submit PostScript, make sure it can be printed on a minimally capable PostScript printer (Microsoft products are particularly bad at generating portable PostScript). Reports should contain around four pages of text and must not contain more than five pages of text; delete figures, tables, and other non-text material when determining the page count.

Reports should be submitted 7:00 p.m. on the day they're due; reports submitted after 7:00 p.m. Friday are late and automatically get docked 10 (of 100) points off. You can submit paper copies to either me or Jerome, but e-mail submissions should go only to me. I leave campus for GCATT after class, so if you're going to give me a paper copy, make sure I've got it before class ends; if you put it in my CCB mailbox after class I won't get it until the following Monday, and I'll consider it late (I don't have a GCATT mailbox).

Templates will be available for each report, but you may use any you choose, as long as it contains all the necessary information, as defined by the templates and the textbook.

Grading

The three factors that make up the report grade, and their approximate weights, are
Information60%
Consistency30%
Presentation10%
Information refers not only to the information in the report, but also in the way it's presented. Consistency refers to the report-to-report connectedness; that is, the software you implement should look like the system you designed should be related to the requirements you specified. Presentation refers to the generic issues, such as spelling and grammar, formatting, and page count.

I'll accept draft reports on the Friday before they're due and provide a critique of how the report looks. It is not manditory that you submit a draft for critiquing or that you do anything in response to the critique. Whether or not you submit a draft will not affect your grade; that is, if you submit a draft and ignore the critique, you'll get the same grade you would have gotten if you didn't submit the draft.

A Reminder

The point of this project is to practice software engineering on a project, not to produce any particular piece of software. Make sure your group doesn't stray from practicing software engineering to bashing out code for a program.


This page last modified on 23 November 1998.