Comments on the Winter 2002/2003 CSC408S Mid Term Test

Answers that regurgitated the textbook or the lecture slides
in general did less well than answers that demonstrated the
ability to think about the issues in the questions.

A good answer had to answer all of the parts of the question.
A lot people didn't answer the question that was asked,
but some mutated version of the question.

1.  Measure cohesion or coupling.

  Either choice was OK *if* it came with a good discussion
  of how cohesion/coupling affects the quality of a 
  software system, and how the tool would help improve
  quality.

  Personally, I'd probably pick the coupling tool and
  argue that high global coupling is really bad for the
  quality of the software and that the tool would help
  me reduce coupling.

2. Dealing with a project that's behind schedule.

  A complete answer had to explain each of the actions:
  1) renegotiate
    Changes the definition of finish to allow the
    project to complete by the redefined end time.
  2) add people
    This would help only if the people were fully
    trained and ready to start working immediately
    Otherwise it will probably make the project later
    (ref Brooks)
  3) renegotiate software quality
    Reduces the amount of testing required and/or
    the time taken to do SQA at the end of the project.
    (a lot of people misread this for reducing software
     functionality)

  Most people preferred renegotiation, although the other
  choices were OK if they came with a good argument.
  It was hard to make a good argument for 2).

  Other ways:
  - renegotiate system functionality, defer some features
    to a future release.
  - defer documentation until after delivery

3. How to be Portability Czar

  A lot of poor answers just gave a list of portability
  issues from the lecture slides.  Some answers didn't
  realize that portability only applied to *new* software.

  The question was about how to introduce portability
  into an existing software development organization.

  What to do as Portability Czar
  - negotiate yourself a large raise and an office
    fit for a Czar.  [you'll be more creditably
    if you appear to be a powerful person in the company]
  - get management to provide some staff to help you.
  - convince management to make "achieves portability"
    a part of every developers and managers performance 
    evaluation.  [something that affects their paycheck 
    will get their attention]
  - work with a small committee of senior developers
    to develop a set of company standards and practices
    for creating portable software.
    [helps get the developers committed to portability]
  - distribute these standards to all developers and
    have management announce that they are mandatory
    for new software.
  - hold seminars for developers to teach them about
    writing portable software.  Hire a small number
    of portable software specialists to act as consultants
    to the developers.
  - get the SQA group to include portability as one of
    the quality criteria that they test in every new
    software product.
  - have your staff work with the SQA group to monitor
    progress toward portability and intervene if necessary
    with developers that aren't writing portable software.

4. Traceability

   A lot of answers didn't give a very good definition.
   A lot of poor answers just regurgitated the lecture
   slide on traceability.  Very few answers said much 
   about how to deal with traceability as the software
   evolves.

   Traceability is the chain of documentation links that
   tie different incarnations of a software system together.
   Forward traceability goes from Requirements to Product.
   Backward traceability goes from Product to Requirements.

   At all steps of the development, a part of the required
   documentation should be the forward and backward 
   links that establish traceability.

   One aspect of every change to a software system should
   be the maintenance of the affected traceability links
   - does the change invalidate any existing links?
     if so, they should be fixed.
   - what new links are required because of the change?
   
5. Personnel Related Project Risks

  A lot of poor answers didn't focus on personnel related
  risks.  Very few answers completely discussed
  identification, prioritization and reduction.
  
  1) Drop the course
     Identification
     - at team formation try to assess how committed each
       team member is to the course.  Look at past history
       of dropping courses.
     - use frequent communication to check that everyone
       is still working
     Priority  - high 
     Reduction - shift load among team members to try
         and encourage everyone to stay
     Contingency - other team members prepared to step
         in and do the persons work
  2)Not do the work
    Identification
    - frequent contact to assess progress
    - set internal deadlines for delivery of each
      members work.  Require use of CVS
    Priority - medium
    Reduction - find out why person isn't doing the work
      Perhaps shift them to something they'd rather do.
      Set internal deadline to finish before the due
        date. Check that system is complete.
    Contingency - other team members prepared to step
      in and do the persons work.  Perhaps report 
      team member to the Prof.
  3) Poor Quality Work
    Identification
     - Do frequent builds of the system
     - have more than one person responsible for each class
     - read each others code.
    Priority - medium
    Reduction
     - help weak programmers with advice
     - try to assign weak programmers to less demanding tasks
    Contingency - other team members prepared to step
      in and do the persons work.