Instructor: David Yang (Science South 433, dyang@csuhayward.edu)
Time: Tuesdays, Thursdays 4:00-5:50 PM
Location: Science South 105 

Blackboard -- notes, submitting work and grades: Lecture notes will be posted on Blackboard after each class. You will be submitting your work on Blackboard and will be able to check your grades there. If you have never used Blackboard before, note that you are automatically given an account. To get started, go to the Support Page . You should find the Getting Started page for Students especially helpful. Note that I do sometimes send information to your email address listed on Blackboard. If you should change email addresses, please update it on Blackboard (the FAQ tells you how).

Text:
Various web pages and web sites. The most important of these are as follows:

• Allen Holub's combined article series about a use case-based approach to developing software
• ObjectMentor.com a site with good introductions to UML

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)

• to develop an understanding of the concepts and techniques of software engineering
• to gain an understanding of the process and management of a substantial software product
• to learn to work in a team 
• to practice software development principles
• to learn how to effectively present your ideas, in an oral and written context
• to develop habits and methods appropriate to the discipline and to scholarly inquiry in general
• to learn how to evaluate the work of others

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 helpful hints about working on it. IMPORTANT NOTE OF WARNING: Not all members of a team will necessarily earn the same grade on a deliverable. Do not allow your teammates to do your work for you. There are presently scheduled to be 5 graded deliverables. Here is the breakdown:

Segment Percentage
Initial project proposal 0% (but must be approved)
Software Requirements 25%
Tutorial/test plan 25%
Software Design 25%
Implementation 10%
Group Presentation 15%

Individual logs: A former colleague, Stephen Cooper, includes a nice explanation of why you should keep a log and what it should look like. I've modified it slightly and put it here. I will require a log for the first 4 deliverables. 5% of the grade for each will be based on your log. In particular, you will receive no credit for any deliverable for which you do not turn in a log.

Document evaluation
Another important component of the project is your evaluation of the work of others. This part of the work is to be done individually. 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: 
The project will count for 50%.
The midterm will count for 25%.
The comprehensive final exam will count for 25%.

[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:
Remember that standard policy dictates that students who do not attend can be removed in favor of students on the waiting list who do show up.

IMPORTANT: attendance is mandatory for the project meeting days. The penalties are as follows:

• -5% for the first meeting missed (modifies your grade for the next deliverable)
• -15% for the next deliverable
• Zero for the project if you miss more than 2 inclass meeting periods.

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: My office is in room 433 of the North Science Building. My tentative schedule for office hours is: 

• Tuesday, Thursday 1:30 PM - 3:30 PM 

I will also be available at other times by appointment. 

Tentative Schedule All days in red are mandatory. Days in green are holidays

Reading:
The Software Engineering Institute at Carnegie-Mellon Univ. Read this intro
Summary of the Capability Maturity Model for software
Standish Group's top 6 reasons for software project failure

Project: form and organize teams of 3-4 by Thursday, pick a team leader and choose a topic (due next Thursday) 
Turn in your "type" via Blackboard -- take a brief Briggs-Meyers test and share it with your teammates

Readings:
13 arguments against user requirements analysis and responses
Alan Holub's simple case study (Read up to "Submit a mockup to a real user")

Project
1. Suggestions regarding topics
2. Grading guidelines
3. Randy Pausch's advice on teamwork in a class
4. Software Requirements Specification assignment (due July 10, 4pm, via digital drop box)
Note that individual logs will be due at the same time

Reading: Definition Principles

Reading:
Deborah Mayhew on usability
Alternate article on usability (Mayhew article has become unreachable)

End of Add/Drop period

Reading:
SEI article on test plans
Adapted version of IEEE Standard 829 (Applied Computer Technology) (IEEE standards homepage requires subscription)
Eric Raymond's "The Cathedral and the Bazaar" The whole article is enjoyable and informative, but at least read the first 5 sections, then "Necessary Preconditions", "Management and the Maginot Line", and the Epilog

Last day to withdraw without approval is Monday, Aug. 11