CS 4310 Spring 2009 Home Page | |||
CS 4310 Spring 2009 -
Software Engineering - 4 Credits
Instructor: David Yang (Science South 450, david.yang@csueastbay.edu)
Text: Goals: (Much of the material from here until Calculating your grade is taken from the syllabus developed by Prof. Stephen Cooper of St. Joseph's University)
Project: During the beginning of the second week of class, you will be assigned to a small team with whom you will work on a project over the semester. There will be much further discussion about the deliverables for this project, as well as suggestions about working on it. Not all members of a team will necessarily earn the same grade on a deliverable. The project site will document who did what. There are presently scheduled to be 5 graded deliverables. Here is the breakdown: Segment Percentage
Another important component of the project is your evaluation of the work of others. Each member of your group will be assigned to review a different group, if possible. You are to critically, (but politely) evaluate the work of one other group. You should not spend much time evaluating spelling and grammar -- the content is the focus of our concern. They will get to see your evaluation. It is important that you point out both what you feel the other group has done well and what it has done not-so-well, and why. The evaluation will be required for every deliverable besides the implementation. 10% of your grade for each of these deliverables will come from your evaluation. And just as you should write politely, you should learn to accept criticism politely. Calculation of your grade: [grading note: Your exams must average (using the relative weights above) out to a C- or better in order to get at least a C- in the course.] Final grades will be given according to the following scale: 93-100 A, 90-92 A-, 87-89 B+, 83-86 B, 80-82 B-, 77-79 C+, 73-76 C, 70-72 C-,67-69 D+, 60-66 D, 0-59 F Attendance: IMPORTANT: attendance is mandatory for the project meeting days. I understand that it is difficult to regularly meet outside of class. Thanks to a suggestion from previous students in the Fall of 2002, I will be setting aside 4 class periods for group meetings. If you have a really good excuse for these dates (all marked in red in the schedule below), bring proper documentation (ex: signed doctor's note) the next day. Also, note that you still really need to set up meetings outside of class to work properly as a group. Academic Honesty: This course will follow the University's standard policy on academic dishonesty. In particular, note that regardless of whether you copy work from another student or allow another student to copy your work on an exam, you are both equally guilty and equally penalized. Copying text/files off the internet without properly giving credit is also cheating. Any cheating on an exam results in an F for the course. Cheating twice also results in an automatic F. All instances of cheating will be reported to the Dean's office. Remember that the University may inflict further penalties than listed here under the provisions of the published Academic Dishonesty Policy. Office Hours: Go here to view my office hours Click here for the class schedule | |||
This webpage's layout is originally from Bill Parkinson, who used to teach in the evening program at St. Joseph's University. Much of the content is lifted from Steve Cooper's version of this course -- in particular, the project documents were designed by him, though parts are adapted from elsewhere. |
This is a fairly standard text, covers the material quite thoroughly, and has pointers to a lot of web-based resources. The main project example is a household security control center. This is a useful problem in that there are hardware and external considerations (the system is intended to be connected to a phone system that can automatically dialup the police, for example), but the application may seem a bit remote for students who are trying to get the hang of problems that only deal with software.
This book does not provide as thorough a coverage as Pressman (ex: nothing on risk analysis), but it has the advantage that it is written for students taking a course. It has a lot of good project-related advice, though the advice is only useful when applied, of course. The text also takes the approach that just as software process phases (see the 1st lecture :)) usually need to be repeated, the topics should be discussed again after all topics are covered once. The main project example is a small dungeon game, which is probably closer to what you might be working on in this course and CS 4311 and maybe CS 4320.