CISC 498 Information Technology Project
School of Computing		2009-2010

CISC 498 Details

CISC 498 represents the capstone course of the Software Design program (SODE), that is, a course that allows you to apply the things you have learned about software design so far and put them into practise by implementing a substantial piece of software. The structure of the course is simple: you form groups of three students, pick a project from a list of suggestions, gather the requirements of the system to be built in interaction with the customer of the project, think about the design, and then implement, test and deploy the system.

Format

There will be no lectures. We will meet about 3 to 4 times each term for presentations and checkpoints. See the schedule below for details.

Groups, Projects, Customers, and Supervisors

Suggestions for projects have come from various members of the Queen's community. This year, we have an extensive list of interesting projects. They are listed on the project page. Detailed information on the projects will come from the customer.

You will work in groups of three. Each group will have its own project.

Each project has a customer, who is usually the person who suggested the project. The customer will be your resource for developing the requirements of the system (i.e., what it is supposed to do). It is your responsibility to get in touch with your customer, schedule meetings, and effectively interact with them over the year. All customers are busy people, so please respect their time by, interacting with them with an appropriate frequency and being prepared for meetings.

Additionally, each project will have a supervisor. Typically, this will be a faculty member in the School of Computing. The supervisor will provide input on the technical realization of the system (i.e., its user interface and how it should be implemented). You can find a supervisor yourself (any School of Computing faculty member is fine), or I can assist you.

CISC 498 will require you to work independently and with relatively little guidance. You will be required to use your own judgement. To facilitate the organization of the course, however, your development should follow the waterfall process. That is, you should perform requirements analysis, design, and implementation in this order and not move to the next phase until the current phase has been completed and the appropriate document summarizing your results has been created. You don't have follow all details of the waterfall process and can modify it as you see fit (e.g., use pair programming, construct prototypes), but you will have to work on requirements, design and implementation in this order and produce documents summarizing each. The structure and contents of these documents will be fairly standard and I have provided templates for each.

Documents should be delivered to your supervisor and the course coordinator by the due date, and to your customer at your next meeting following the due date.

Schedule

The fall term will largely be devoted to requirements analysis and design, while the winter will be devoted to implementation, testing and deployment.

Fall 2009

This term will be devoted primarily to forming groups, picking a project, gathering requirements, creating a design, and thinking about software quality assurance.

• First meeting: Sept 15, 2009. Form teams and review projects.
• Contract and project plan
  • Project plan includes, for instance:
    • description of project
    • description of project schedule including self-defined milestones
    • logistics - group's plan for coordinating own activities (meetings, bulletin board, etc.), plans for meetings with customer
    • meet with your supervisor to obtain feedback on project plan
  • Due: by Sept 29, 2009 (in class)
• Create requirements document. Includes, for instance,
  • problem definition from user's point of view
  • documentation of existing processes
  • identification of required and optional aspects
  • identification of relevant resource limitations
  • specification of non-functional requirements
  • identification of acceptance criteria
  • Due: Oct 13, 2009 (in class)
• Present requirements: Oct 13, 2009 (in class)
• Create external design document. Includes, for instance,
  • description of system from user's point of view
  • user interface design
  • must be backed up by first prototype (e.g., web mockup, storyboard) that has been demonstrated to customer for feedback
  • Due: Nov 10, 2009 (in class)
  • *** NEW *** Revision due Nov 24, 2009 (in class)
• Present external design and demonstrate prototype: Nov 10, 2009 (in class)
  • *** NEW *** Present revised external design: Nov 24, 2009 (in class)
• Create internal design document. Includes, for instance,
  • object models
  • module structure and dependencies
  • architecture
  • data structures and algorithms
  • *** NEW *** Due: Jan 12, 2010 (in class)
• *** NEW *** Present design: Jan. 12, 2010 (in class at first meeting of Winter term )
• Create software quality assurance plan. Includes, for instance,
  • identification of covered software process activities and metrics used
  • description of assurance activities applied
  • description of documents produced
  • *** NEW *** Due: Jan 19, 2010 (hand in to Prof. Cordy or main office)

Winter 2010

This term will be devoted mostly to implementation and deployment of your system.

• Present internal design: Jan 12, 2010 (in class)
  • Internal design document due
• Software quality assurance plan due: Jan 19, 2010 (no class)
• Send brief weekly progress reports to customer, supervisor, course coordinator
  • Send by email each Wednesday, starting Jan 22, 2010
  • List meetings held, progress, milestones met, modifications to schedule or delivery plans
  • Reports not required in weeks where you give presentations in class
• Create deployment plan
  • Detail plans for delivering system to customer, hosting details, hardware and software issues, security plan, plan for acceptance testing
  • *** NEW *** Due: Mar 2, 2010 (in class)
• Present deployment plan and system demo
  • Demonstrate current state of system (should have early version demonstrating much of intended functionality)
  • *** NEW *** Due: Mar 9, 2010 (in class)
• Final presentation and demos: April 6, 2010 (in class)
• Create final project documentation. Includes user manual, installation guide, maintenance suggestions, user manual, known limitations and workarounds, updates (as necessary) to system internal design.
  • Due April 9, 2010
• Deliver system to customer (by end of term)

Documents

For each of the documents to be submitted, I have provided rough templates. I encourage you to add to these templates whatever information you feel is relevant. The references provided below contain some ideas on what kind of information the various documents could contain. Use the templates and additional material as a guideline, but then apply your own best judgment when deciding on the contents, structure, and level of detail of these documents.

Submission

Documents are due on the dates indicated in the schedule. Documents not submitted by the due date will be counted as 0%. Make sure that the group members are indicated clearly on the front. For each document, you should submit one copy to your supervisor and one copy to me.

Presentations

The presentations will, at most, be 30 minutes in length. All members of the group are expected to cover a part of each presentation. All students must be present during all of the presentations.

We will have a tight schedule on presentation days. To avoid wasting time shuffling laptops, please submit your presentation by 5:00 PM on the previous day by email to me (cordy @ cs • queensu • ca). Presentations must be in a standard format suitable for projection from a laptop (e.g., PowerPoint or PDF.)

Attendance

Attendance at class meetings is mandatory. For each hour of class (or part thereof) missed, two marks will be deducted from your final grade.

Marking

To obtain a passing grade, the group must engage in ongoing meetings with its customer, and create and deliver a project solution to their customer based on requirements determined in collaboration with the customer and supervisor. Assuming that these conditions are met, the mark for each student will be obtained from the documents and presentations of the student's group using the following scheme:

What	When	Weight
Contract plus intial project plan	29 Sept 2009	0%
Requirements document	13 Oct 2009 (in class)	10%
Requirements presentation		5%
External design document	10 Nov 2009 (in class)	10%
External design presentation and prototype demo		5%
Internal design document	24 Nov 2009 (in class)	10%
Internal design presentation		5%
Software quality assurance plan	3 Dec 2009	5%
Weekly progress reports (email to coordinator & customer)	By email, each Tuesday starting 22 Jan 2010	5%
Deployment plan document	23 Feb 2010 (in class)	5%
Deployment plan presentation and system demonstration	2 Mar 2010 (in class)	5%
Final project presentation and demonstration	6 Apr 2010 (in class)	5%
Final project documentation	9 Apr 2010	10%
Delivered system	To customer before end of term	20%
Total		100%

The documents and presentations will be evaluated by the supervisor and the course coordinator, with input from the customer. Marking criteria for documents and presentations include correctness, competeness and clarity.

Plagiarism and Dysfunctional Groups

Plagiarism is the act of taking somebody else's work or ideas and presenting them as if they were your own. As in all other courses, plagiarism will be viewed as academic dishonesty and will not be tolerated. Appropriate action will be taken against offending students. Possible actions include partial or total loss of marks for the course the work in question or the entire course, or reporting the case to the Dean who may take further action.

All group members are expected to contribute equally to the project. It is up to the group members to oversee and enforce this requirement. In case of disagreements or conflicts that you cannot resolve yourself, you should contact me. I may then take some action which seems most appropriate to address the problem. Possible actions include changing the marking scheme for a group or individuals, asking a student to carry out additional work, or even expelling a student from the course.

Computing and Software Resources

You can work at home on your own machines or in the CASLab.

There is currently no budget for the purchase of any material or software for CISC 498. Please bear that in mind when planning your project.

For web-based systems, the School of Computing and Queen's ITS can provide test servers and support for migration to production systems.

Course Coordinator

The role of the course coordinator is to

• to organize and oversee a number of meetings and presentations
• assist you in finding a supervisor
• make sure that you have access to the resources you need
• evaluate your work (together with the customers and supervisors)