General Project Description

CS 325, Software Engineering Concepts, Spring 2000


Table of Contents

Introduction

The purpose of the project is to walk you through the major phases of a software engineering task and to familiarize 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 semester 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.

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.

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. Roles are assigned to group members arbitrarily by the instructor, but these may be changed by the common consent of the group members involved.

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 phase ends with a report:
PhaseReportDate Due
RequirementsRequirements Specification (template)7February
DesignSystem Design Document (template)23February
ProductionRevised SDD and code 20March
ValidationSystem Test Document (template)5April
ManagementSoftware Project Plan (template)24April

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. 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 by the end of class on the day they're due; reports submitted after the end of class on the day they're due are late and will loose five points for each day they're late. I use a 24-hour clock starting at midnight to count the days, so if you submit a report the day after it's due, the report's two days late and will loose 10 points.

Templates will be available for each report, but you may use any report format you like, 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 to the report's contents, and its relevance to the phase related to the report. 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 a week before they're due and provide a critique of the draft. It is not mandatory 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 10 April 2000.