CS 453 (WI) Software Engineering Workshop II, Spring 2007

Instructor: Dr. Werner Krandick Administrator: Haritha Haridas

Please, contact Haritha whenever your project information on Teams and Projects needs to be updated. Haritha also schedules the final project presentation and demo, and she administers the WebCT pages of the course. Please, contact Haritha also in case you do not receive another team's document that you need to review.
 Class Times: T 6:00 pm - 8:30 pm
Classroom:  Matheson Hall 308


Final Project Presentation and Demo:

Tuesday, May 29, 2007, Hill Conference Room, 240 LeBow Building
Wednesday, May 30, 2007, Hill Conference Room, 240 LeBow Building
Here is a detailed schedule.


Teams and Projects

Introduction

The Software Engineering Workshop I,II (CS 452-453) serves the purpose of a capstone experience for students in their senior year. The workshop provides students with the opportunity to prepare for careers as professional software developers by working in teams on a significant software development project.

Teams will also have the opportunity to use the software project as a basis for a business idea and present this idea in a business plan competition organized by the Baiadacenter for Entrepreneurship in Technology, Drexel University. More information can be obtained at http://www.baiadacenter.drexel.edu/. 

Course Objectives (CS 452-3)

1) To work efficiently in a team of peers.
2) To give software specifications that are clear, detailed, complete, consistent, usable, and modifiable.
3) To design software according to specifications.
4) To implement a design of significant complexity.
5) To review software projects of other teams.
6) To develop documentation, writing and oral presentation skills.

For students: Schedule, due dates, submission instructions, and grading scheme

For every due date, the due time is 11:59 pm.

Apr  10: Requirements document and acceptance test plan available on project web-site for peer review. The team administrator announces the URL on the discussion board of WebCT.

Apr  17: Review of requirements document and acceptance test plan. The team administrator submits the review in PDF format via WebCT (7.5%). The team administrator sends a copy to the administrator of the reviewed team.

Apr  17: Design document and integration test plan available on project web-site for peer review.

Apr  24: Requirements document (PDF and HTML) and acceptance test plan (PDF). The team administrator submits the final version of the documents via WebCT (10%).

Apr  24: Review of design document and integration test plan. The team administrator submits the review in PDF format via WebCT (7.5%). The team administrator sends a copy to the administrator of the reviewed team.

May   1: Beta-version available on project web-site for peer testing.

May   1: Design document (PDF and HTML) and integration test plan (PDF). The team administrator submits the final version of the documents via WebCT (10%).

May   8: Beta-test report. The team administrator submits the test report in PDF format via WebCT (7.5%). The team administrator sends a copy to the administrator of the reviewed team.

May  15: Project web-site (final version) (5%).

May  22: Project code (final version) (20%). The team administrator submits the beta-version via WebCT.

May 29, 30: Final project presentation and demo (32.5%). The team administrator submits the presentation slides via WebCT. The presentations will be given in Hill Conference Room, 240 LeBow. Here is a detailed schedule.

May 31: Final Four Competition: Outstanding Computer Science Senior Project. The competition will be held in Disque 103 from 6 pm to 9 pm; a light dinner will be served from 5 pm to 6 pm.

Jun 5: College of Engineering Senior Design Competition. The competition will be held in the Bossone auditorium from 9:00 am to 3:30 am. Evaluation form (PDF).

For advisors: Grading schedule

Advisors should grade each deliverable within one week after it was submitted. Here is a list of the submission dates.

Apr 17: Review of requirements document and acceptance test plan (7.5%)
Apr 24: Requirements document and acceptance test plan - final version (10%)
Apr 24: Review of design document and integration test plan (7.5%)
May  1: Design document and integration test plan - final version (10%)
May  8: Test report on beta-version (7.5%)
May 15: Web-site - final version (5%)
May 22: Project code - final version (20%)
May 29, 30: Final project presentation and demo (32.5%)
Peer reviews

Team 1 will review the work of Team 18.
Team 2 will review the work of Team 1.
Team 3 will review the work of Team 2.
Team 4 will review the work of Team 3.
Team 5 will review the work of Team 4.
Team 6 will review the work of Team 5.
Team 7 will review the work of Team 6.
Team 8 will review the work of Team 10.
Team 9 will review the work of Team 11.
Team 10 will review the work of Team 9.
Team 11 will review the work of Team 8.
Team 12 will review the work of Team 7.
Team 13 will review the work of Team 12.
Team 14 will review the work of Team 13.
Team 15 will review the work of Team 14.
Team 16 will review the work of Team 15.
Team 17 will review the work of Team 16.
Team 18 will review the work of Team 17.

Deliverables

1. Reviews

Each review should be about 3 pages in length. This holds for the review of the requirements document and acceptance test plan, and for the review of the design document and integration test plan. The reviews should address the contents of those documents, not style or organization. The test report on the beta-version should also be about 3 pages long. Try to structure your comments in a useful way - for example by the level of seriousness or by the parts of the project that the comment refers to.

2. Requirements Document

The requirements document is the official statement of what is required of the developers. As far as possible, it should focus on what the system should do rather than how it should do it. The requirements document should specify the main components and behavior of the computer system and its operating environment. It should also characterize its responses to unexpected events, and impose any constraints on the implementation. The document should be easy to change because it most likely will require modification in later phases such as software maintenance. The audience for a requirements document is usually non-technical, so keep this in mind when writing it.

The requirements document will have roughly the following structure:

A requirements document typically contains structured text. It is highly recommended to take advantage of the HTML hyper-link capabilities in order to implement requirements traceability.

When you submit your document for grading the document must include a paragraph that summarizes the changes that were made as a result of the consultations with the writing tutor in Winter Quarter.

Requirements document guidelines.

Example documents.


3. Acceptance Test Plan

The acceptance test plan describes the tests that will be executed when you have delivered the finished product. If your product passes this test it will be considered a sucess, otherwise a failure.

The team administrator submits the acceptance test plan in PDF format via WebCT.


4. Design Document

The design document must be written in HTML and should consist of one or more diagrams that explain the overall structure of the software system implementation. This is a technical document. Design diagrams describe concepts such as: inheritance trees, include file dependencies, class and module interfaces, protocols of interaction between objects, runtime libraries, etc. Make sure that the diagrammatic notations you use to articulate your design are explained in the document. For example, what do edges and nodes mean? Are all nodes and edges labeled?

When you submit your document for grading the document must include a paragraph that summarizes the changes that were made as a result of the consultations with the writing tutor in Winter Quarter.

The administrative team leader of each team submits the design document in both, html and PDF format via WebCT.

Design document guidelines.

Example documents.


5. Integration Test Plan

The integration test plan describes the tests that will be used to verify that the software components were properly assembled.

The team administrator submits the integration test plan in PDF format via WebCT.


6. Project Website

The website should contain a logo, the project title, your names, your project description, the requirements document, the acceptance test plan, the design document, the integration test plan, and - once it is available - the final version of your code.


7. Project code (beta-version and final version)

The entire source code and pertinent data, complete with installation instructions, build system, and test harness. If specialized hardware is used, that hardware is also made available.

8. Final Project Presentation and Demo

Each team will make a presentation describing their project and demonstrating the software they developed. The presentations are expected to be of high quality (i.e., well structured, using a data projector, etc.) and to involve all team members. The faculty advisor and a number of other CS faculty members will be among the audience. The total time dedicated to each team will not exceed 30 minutes.

Final project presentation and demo guidelines.

Evaluation form.

Resources

Reference:

Roger S. Pressman, Software Engineering: A Practitioner's Approach, Sixth Edition, McGraw-Hill, 2005.

Academic Honesty

The university's Academic Honesty Policy is in effect for this course.