CSCI 6838 Capstone Projects
Fall 2008
Course Syllabus, Policies and Guidelines

by K. Yue

1. General Information

Instructor

Dr. Kwok-Bun Yue, Professor of Computer Science, Chair, Division of Computing and Mathematics
Delta 163, 281-283-3864, yue@uhcl.edu; URL: http://dcm.uhcl.edu/yue/
Office hour: R 3:30-6:00, walk-in, or by appointment

Course Description

Student teams will be assigned a research or commercial project which requires integrating knowledge and standard procedures in the discipline. A written technical paper and a presentation will be required.

Course Objectives

• Students gain practical experience in the discipline by working on realistic projects.
• Students gain experience to work in a team environment.
• Students gain experience in writing technical papers and making technical presentations.

Learning Outcomes

Specifically, after taking the courses, the following learning outcomes are expected to be able to:

1. Work on real-world computer and information systems projects.
2. Analyze real-world problems to devise requirement specifications.
3. Construct effective software solutions for real-world problems.
4. Work professionally with team members, customers, mentors and supervisors.
5. Manage and participate in software projects.
6. Present technical presentations effectively.
7. Write technical reports effectively.

Prerequisites

24 hours completed in the graduate degree programs of CS or CIS and approval by the division chair.

Course Format

For each week, every team is expected to:

• meet by itself once.
• meet with the mentor and/or instructor once.
• write minutes for meetings.

Grading

Grading will be based on the quality of deliverables and presentations, as well as the instructor's observation on student performance during technical meetings and demonstrations. The instructor will also seek feedback from the external mentors.

Other Useful Information

• UHCL emergency hotline (to check weather related closing, for example): 281-283-2221.

2. Course Policies

The following policies and guidelines will be used for grading projects. Students are responsible to ensure that their projects are following the guidelines.

• Policies and procedures: including general course expectation, procedures, grading policies, etc.
• Guidelines for maintaining an active project Web page: the minimal contents of the Web page.
• Guidelines for oral presentation: slide contents, slide preparation and presentation.
• Guidelines for database design and documentation.
• Guidelines for writing the technical report: contents and layout.

Other policies and hints:

• No incomplete grade or administrative withdrawal under nearly all situations.
• Penalty on cheating will be extremely severe. Standard academic honesty procedure will be strictly followed. Use your best judgment. If you are not sure about certain activities, consult the instructor.
• Students should not miss any meetings or presentations. They should participate actively and be punctual. In verified emergency situation when one cannot attend a meeting, notify other participants as soon as possible.
• Course participation is of utmost importance.
• Check the course Web page regularly.
• If you need help in debugging, you may come to my office with the most recent listing of your program, output and error messages, and a disk containing your program so I can run it. However, unlike other courses, the team is expected to solve technical problems itself.
• If you have problems with your accounts, you may want to contact my research assistants directly by sending them an email and copying it to me. It is very important to secure working development and deployment platforms as soon as possible.
• Software development is time consuming. Start early and plan well ahead.
• If you expect any potential problems, consult me as soon as possible so I may help you.
• Procrastination usually results in poor grades.
  

3. Tentative Course Schedule

The schedule is subjected to changes. Teams are expected to meet with the mentor and instructor regularly during the semester. No class was cancelled due to hurricane Ike. Lost time will be made up by increasing team activities and meetings with the mentor and instructor.

Week #1 (8/26: section 1 or 8/28: section 2)

This is the most important class. Missing the class may result in a failing grade.

Class activity: Introduction to the course; policies and guidelines; descriptions of available projects; assignments of projects; project management.

Tasks expected to be completed in the first week.

• Each team member should send an email to the instructor to provide the following information: name, email address, team number, phone, cell phone, major and student id.
• Each team should send an email to the instructor identifying the team members and their email addresses and student id.
• Each team should also send a MS Word document to both the instructor and the mentor. The MS document should contain the team number, the team title, team URL, and information of each team member. The name, email address, phone number, major, role and a recent clear photo of each member should be included. Try to fit everything into one page for easy printing. Compress the photos before sending the document.
• Each team should meet by itself at least once. Important tasks of the first meeting include role assignments, initial understanding of the requirement specifications, determination of development platforms, setting up project Website, preparation of the first meeting with the mentor, scheduling, initial identification of critical tasks, task assignment, etc.
• Each team should conduct the first mentor meeting. The first meeting usually focus on understanding the project requirements and establishing logistical arrangement.

The instructor will attend the first two mentor meetings.

Week #2 (9/2 or 9/4)

Class activity: Further discussion of course policies and procedures; discussion on mentor meetings; other issues, etc.

Minimal tasks expected to be completed this week:

• Each team should conduct the second mentor meeting.
• Initial project Website should be up and running.
• A smooth process for scheduling meetings should be setup.
• Team roles should be properly assigned.
• Critical tasks should be identified and assigned.
• The team should acquire a good understanding of the project scope.

Week #5 (9/23 or 9/25)

A brief abstract of the project should be sent to the instructor through email in MS Word 2003 format. The abstract should be less than 250 words and should use double spacing. This allows the instructor to comprehend the quality of technical writing of the team and provide feedback, which will be sent through email.

Week #7 (10/7 or 10/9)

Class activity: Mid semester presentations. Each team will present for a total of 25 minutes, including the question and answer session. Each member should present for approximately the same duration of time. Every student is expected to attend all presentations of the same section and ask at least a question during the class. Feedback from the instructor will be dispensed immediately after the presentation.

The instructor will also discuss any issues the class has raised to ensure that any remaining problems are properly addressed. The class may be longer than the normal class time.

Week #11 (11/4 or 11/6)

First prototype demonstration: each team should schedule a meeting with the instructor to demonstrate its project prototype. Mentors may be invited when desirable. Feedback from the instructor to improve the prototype will be dispensed immediately.

Week #14 (11/25 or 11/27)

November 26th to 29th: Thanksgiving.

November 25h: First version of the technical report is due at 10:00pm. It should be sent through email in MS Words 2003 format.

Week #15 (12/2 or 12/4)

Class activity: final presentations. Each team will present for a total of 35 minutes, including the question and answer session. Each member should present for approximately the same duration of time. Every student is expected to attend all presentations and ask at least a question during the class. No feedback will be provided. Final presentations are used for grading. It will be open to the public and may not be scheduled in the capstone project laboratory.

Each team should schedule to demonstrate the final prototype to the instructor this week. The team should encourage the mentor to participate in the demonstration.

Week #16 (12/9)

December 8th (Monday) 1:00pm

• Final version of the technical report due.
• All other deliverables due. They should be well documented and accessible through the project Website, a CD or both.

4. EMail Communications

Email communications have become both more critical and tricky. Several considerations:

• Much critical communications are now done through email.
• The number of emails received everyday can be very large.
• EMail now serves as a central repository of important information. Email should be written and stored in a way for effective searching.
• EMail has become less reliable for various reasons, including being filtered by spam filter servers.

The capstone team is responsible for successful communications of the project. Thus, each team should derive a reliable system for effectively using email for communications with the instructor and the mentor, and among team members. Some hints follow.

Subject heading should be meaningful. The recipient should be able to grasp the main purpose of the email and search for it effectively. For example: the following sequence of subject headings has increasing usefulness. Comments are written inside the parenthesis.

Subject: (no heading: difficult to handle.)
Subject: Meeting tomorrow (ambiguous; not good for searching)
Subject: Meeting 9/1/2007 (better; but what kind of meeting...)
Subject: Mentor meeting 9/1/2007 2:30pm-5:00pm (better; but place...)
Subject: Mentor meeting 9/1/2007 2:30pm-5:00pm UHCL Capstone lab
Subject: Team #4 Mentor meeting 9/1/2007 2:30pm-5:00pm UHCL Capstone lab (better: the recipient almost does not need to read the email body. This is especially helpful to the instructor, who must deal with many teams.)
Subject: Agenda of Team #4 Mentor meeting 9/1/2007 2:30pm-5:00pm UHCL Capstone lab (now the recipient expects the agenda in the email body. Very searchable too.)

Some other examples:

Subject: Team #5: Questions on project Website requirements
Subject: Team #6: Request of meeting with the instructor during 9/2/2007 to 9/4/2007
Subject: Team #2: Encountered project account permission problems
Subject: Team #1: Reminder of project demonstration: 9/22/07 3:00 Capstone lab <eom>

Email delivery is no longer reliable. You cannot assume that the recipients always successfully receive your email. Communications can break down. To combat this problem, you should form a habit to acknowledge email, sometimes simply by replying with a "thank you" or "got it" note. There is a balance of limiting the proliferation of emails and acknowledgement.

If you have sent an email and receive no reply within a reasonable amount of time, send a follow-up email to remind the recipient tactfully. If you still do not receive any response, use other means, such as phone, instant messaging, physical visits, etc.

There should be a central point of contact with the mentor and instructor. The person may be the team leader. Having too many team members communicating with the mentor (customer) can be confusing, unprofessional and sometimes contradictory. When the team member communicates with the mentor and instructor, it is a good idea to copy to other team members. This will keep everyone informed and involved with the project.

Do not send email to the instructor and mentor on internal project communications among team members.

5. Meetings

Effective meetings are keys to successful projects. It is the responsibility of the team to schedule and conduct meetings effectively.

Scheduling meetings are difficult and need some planning. When the team leader schedules a meeting, it is not a good idea to send out email to everyone with no scheduling time slots, for example:

Subject: meeting
Body:

Hi everyone, what is a good time for the first mentor meeting?

This is unprofessional and difficult for the recipients to respond. Instead, the team should have met and agreed to a set of time slots for the mentor and the instructor to choose from, for example,

Subject: Team #4: Scheduling the first mentor meeting
Body:

Dear Mentor X and Instructor Y,

Our team would like to meet with you as soon as possible for our first mentor meeting. The following time slots are good for all of our team members:

8/23/07 (Thursday): 10:00am-11:30am; 4:00-5:30pm; 7:00-10:00pm
8/24/07 (Friday): 9:00am-6:00pm
8/27/06 (Monday): 11:30am-2:30pm; 6:00-10:00pm

Please let us know which time slots are acceptable to you at your early convenience.

Thanks.

Joe Smith
Team Leader, Capstone team #4
281-111-1111

You may copy this email to your team members. Again, if your team does not receive a response within a reasonable amount of time, send a follow up email and/or call.

Meticulous planning is essential for the success of a meeting. Do your homework! For examples, before the first mentor meetings, your team should ask for as much document as possible beforehand. Since one of the topic agenda items is likely the initial understanding of the project requirements and scope, the team should study these documents and compose a list of key questions. These questions can be sent as part of the agenda.

It is a good idea to send meeting agenda one or two days before the meeting so the participants can prepare accordingly. The agenda should clearly list the issues to be discussed, together with supporting materials, such as the list of initial questions on requirements in the first mentor meeting.

The team leader is usually in charge of conducting the meeting. It is important to ensure that every team member participates actively. Planning would help. For example, the list of questions can be divided up among the team members. Team members should continue to ask questions until everyone understands. Write down notes throughout the meeting.

Before the end of the meeting, the team leader should briefly summarize the meeting and list all action items with the responsible party.

After the mentor meeting or the instructor meeting, the team should get together and compare note. This is to ensure that every team member has the same understanding.

Minutes should be written as soon as possible, recording the result of the meetings: information items, decisions, rationale behind the decisions, action items, etc. The minutes should be sent to the mentor and instructor as soon as possible. Ask them to comment on the minutes. This is to ensure that the team, the mentor and the instructor have the same understanding. Minutes should be posted in the project's Website as soon as possible.

Dr. Kwok-Bun Yue
Professor, Computer Science and Computer Information Systems
Chair, Division of Computing and Mathematics
University of Houston-Clear Lake
2700 Bay Area Boulevard
Houston, TX 77058
  Yue's home page      yue@uhcl.edu       281-283-3864