Comments on  CSC408F Endterm Test		Fall 2001/2002

In general answers that regurgitated the lecture notes received
lower marks than answers that actually applied the material in the
course to the problem raised in the question.
Vague and generic answers received lower marks than answers that
addressed the specific issues raised in the question.

1a) Either a yes or no answer was acceptable if it was accompanied 
    be a reasonable cost/benefit argument.
    Most students said yes, and I'd tend to agree with them.
 b) Typical components included  sort module, string handling 
    module, data input module.  A few well thought out components
    was enough for good marks.
    
2)  A good answer would include discussion of
    - distributed vs. centralized control
    - mechanism for keeping versions up to date in all locations
    - how to keep software configuration consistent across all
      sites.  How to do change control.
    Most solutions either went for a centralized version control
    archive in Toronto (entirely feasible using CVS) or systematic
    updating of local archives.
    
3)  The important point is that the question is about *process*
    issues.  A lot of answers went off track by not recognizing this 
    point.  
    
    It would be good to look at the tools used in the design, 
    implementation and testing steps.  How well are these tools
    integrated together? Are there any problems using these tools?
    Are the developers being systematic about design, development
    and testing or are they working on an ad hoc basis?
    
    Good modularity, good documentation and traceability are
    three things that can be used to improve the maintainability
    of the system.

4)  The first step is to try and understand the exact cause of the
    problem.  Is the subsystem badly implemented or are the testing
    procedures faulty or inefficient?
         
    There were two kinds of answers to this question, either could
    get good marks if a strong argument was made.
    
    1) tell the truth and do the right thing no matter how much it hurts.
       - reallocate people to spend more effort on the troublesome subsystem
       - tell the client that the software may be delayed and that it's
         really in the clients best interest to wait for correct, stable
	 software.
       - tell manager that there may be a delay in delivery, justify it
         by pointing out that it costs less to fix the problem now
	 rather than later.  Also say that no one wins by giving the
	 client bad software.
    2) the shifty approach
       - reallocate more people to work on the problem
       - don't tell the client about the problem, if the reallocation
         works, you may still deliver on time.
       - don't tell your manager about the problem. Hope the problem 
         will go away before the delivery deadline.
	
       IF the problem can be solved through reallocation before the 
       deadline, this strategy could be a win.
       - client doesn't get stressed by problems that later vanish
       - your manager doesn't realize how close to disaster you came.
       - you look like a hero for delivering successfully.

    Some answers lost marks by not answering the last part of the question.
    There were basically two kinds of answers
    1) dust off your resume and plan to move on.
    2) go to your managers boss and tell her/him about this situation
       and the probability that the software won't be ready on time.
       (this could later require answer 1) as well).
       
5) The answers to this question were specific to this years project
   and the experience of each team.  Any good discussion of risks
   encountered and dealt with was enough for good marks.