CSCI 265 (Wessels): Fall 2026 Practice Midterm

 

Question   Mark   Value
1. Short answer
 
  /10
2. Brief discussions
 
  /10
3. SDLCs
 
  /10
4. Modeling requirements
 
  /10
TOTAL
 
  /40

Question 1: Short answer [10]

Provide short (one or two-sentence) answers for each of the following five questions on version control and git.
  1. Briefly explain the concept of a remote in git, and how/why one might use one.
    
    
    
    
    
    
    
  2. Briefly explain circumstances under which one might use a branch in git.
    
    
    
    
    
    
    
  3. Briefly explain what is meant by a merge conflict in git, and the circumstances under which one might arise.
    
    
    
    
    
    
    
  4. Briefly explain how a merge conflict might arise from a pull or push in git, and how it might be resolved.
    
    
    
    
    
    
    
  5. Teams often choose to have a 'git leader' to manage their team repo. Briefly explain the key issues such a role is meant to address.

Question 2: Brief explanations [10]

Provide short single-paragraph answers for each of the following two questions.
  1. Non-functional requirements
    One of the most challenging non-functional requirements to express is that a product must be "easy to learn". Briefly explain why it is difficult to write a 'good' requirement for this, and suggest some suitable wording.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  2. HCI/Accessibility/Internationalization
    One of the common themes in our discussion of these topics was that it is easier to incorporate them if they are built into our design from the beginning. Pick one of the three areas (HCI, accessibility, internationalization) and provide a short example illustrating why it is more challenging to retro-fit a fix.

Question 3: Software development life cycles [10]


Study the system and client description below and recommend a suitable SDLC to complete the final system within 16 months (including providing a clear timeline showing which phases/aspects will be worked on in which months), then provide justification for that choice of SDLC over the other possibilities.

System description: resource utilization modeling tool
A local client wants a custom software product developed over the next 16 months to model the consumption of resources by his crews at sites around various remote Vancouver Island locations. The crews frequently switch between sites, with periodic visits back to their headquarters in Nanaimo.

The client wants the completed tool to be able to report on current storage levels of each resource at each site the crews visit, the rates at which the resources are being consumed, and to forecast when new resources need to be ordered and shipped to ensure the crews do not run out of key resources.

Each crew's resource needs are somewhat different, and resource needs also vary from site to site.

To gather information on the system needs, your team can meet with the leads of each of the different crews during times when they are in Nanaimo, but should also plan on at least one visit to each remote site while there is a crew there.

The client and crew leads are keen on having such a system in place, but they are all very busy and have limited time available to provide you with details about their needs and operations. The client is willing to pay current market rates for you and a team of up to four other people for the 16 months to gather requirements, design, and develop the product. (Any longer term revisions and/or maintenance to be negotiated separately.)

(extra space for question 3 if needed)

Question 4: Modeling requirements [10]

Consider the system described on the last page of the exam (feel free to detach the sheet for easier reference) and pick exactly one of the four modeling techniques below to help clarify the description for potential readers: (If you provide more than one modeling diagram then only the first will be graded.)

On the next page:

(extra space for question 4 if needed)

 

System Description: GameBraker
GameBraker is a software tool focused on the ways games crash and the people who crash them (intentionally or not).

Registered users can add games to the system for tracking, report new crashing techniques for games that are tracked, confirm crashes reported by other users, or confirm that new game patches or versions have fixed crash issues. (Unregistered users can browse the tracked games and crash reports, but cannot add content.)

Users register by selecting a unique username (the system automatically flags attempts to use offensive or already-selected usernames), providing an email address, and following the setup/confirmation steps given in an email the system sends to that address. The user can then complete a profile to include (optional) information about their preferred platforms, games and game styles, age, region, etc.

Users can add new games for tracking by submitted the name of the game and the platform and game version they are using, along with an email address or URL for that game's producers (preferably an email/URL associated with bug reporting for the game). The staff at GameBraker Inc then verify the information provided and have the game added to the system.

After testing or experiencing a game crash (in a tracked game), users either browse existing reports and confirm/deny the crash is still present (deny actually meaning they did not experience a crash with the same circumstances as the other user reported) or they can add a new crash report. Either approach begins by selecting the game, platform, and version in GameBraker's reporting system, then either selecting an existing crash report for that game for confirmation or creating and filling in a crash report. If a new report is being generated then the user is asked to provide detailed information on the form (date/time, detailed descriptions of the steps leading up the crash, nature of the crash, etc).