View this PageEdit this PageUploads to this PageHistory of this PageHomeRecent ChangesSearchHelp Guide

Open Issues

  1. HCI: Elective, Required, or Integrated?
  2. Assessing Product versus Process
  3. 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.

  1. Fit into semester curriculum.
  2. Assign Theory/Practice % and knowledge level to core
  3. Faculty qualifications
  4. Assessment
  5. Satisfaction of accredication
  6. Pedagogical issues
  7. Cost of the last 2 years? This includes costs in money, time, and faculty.
  8. Solve management nightmare

    • instructor scheduling
    • student scheduling
    • summers, coops, other exceptions, transfers – flexibility
    • student population: how big should it be?

  9. Projects
  10. Lab requirements
  11. Start up
  12. Marketing

Other Issues

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.

Ivan's opinion:
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)

Pros -
Increase competition among severl teams. This would yield wider interpretation of the product and possibly increase product quality.: 
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.
Better chance of arriving at an overall solid solution since multiple angles/options are reviewed by much more people.: 
Product developement is scrutinized by many instead of a few
Another assessment method - having teams critic and evaluate each other to gain and lose points.: 
Having more than one set of documents on a product will help ease questions/conflicts for later praticcums that use the documents.

Cons -
Resources are splitted among multiple teams doing the same thing.: 
Teams might cheat if the going gets tough (this could happen regardless of approach).