- HCI: Elective, Required, or Integrated?
- Assessing Product versus Process
- Overall Program Resources Required
Issues scheduled for Discussion
We made a list on 9/30 of the issues we'd like to discuss this quarter. This list is roughly in an order so that items which have prerequisite decisions are listed nearer to the end.
- Fit into semester curriculum.
- Assign Theory/Practice % and knowledge level to core
- Faculty qualifications
- Satisfaction of accredication
- Pedagogical issues
- Cost of the last 2 years? This includes costs in money, time, and faculty.
- Solve management nightmare
- instructor scheduling
- student scheduling
- summers, coops, other exceptions, transfers – flexibility
- student population: how big should it be?
- Lab requirements
- Start up
Faculty/TAs/Students - How many
HCI: is it an elective?
Ought HCI be "required" or "elective" as a part of the SE curriculum?
Should it be integrated (sprinkled throughout) or its own course?
It was pointed out in class that much of the work in HCI is very similar to the requirements gathering done by Software Engineers; the two groups currently have different ways to name things, and have some different techniques, but much of it is the same.
I believe that the program we are trying to create a extremely unique.
If we are going to be the ground-breaking explorers in educating SE, I say we go all out and have HCI as a requirement. In recent years, the importance of HCI has grown. Institutes such as ours (GVU) and others have become major academia research centers. Even Berkeley has created its own center last year. We must be the innovators and say: "HCI is a requirement". Once again, it is only my opinion
Pros and Cons of having multiple teams on the same task
Assessments and schedules would be affected by our decision on whether one or more teams would work on a particular task. (please add your comments)
Better feedback to the instructors as to the pace/progress of product development if their observation is made on several teams instead of just one.
Product developement is scrutinized by many instead of a few
Having more than one set of documents on a product will help ease questions/conflicts for later praticcums that use the documents.
Teams might cheat if the going gets tough (this could happen regardless of approach).