University of Toronto, Department of Computer Science

CSC444 Software Engineering I   Fall 2002

 

alliances, plagiarism and collusion

last updated: Sept 9, 2002

 

Alliances

 

At some point during the course, some teams will inevitably think about forming alliances with other teams to help ensure that their module can be integrated properly in the next phase of the course. Thinking ahead to the integration phase is a good thing, and we don't want to discourage discussions about clearer interfaces between modules. However, some specific guidelines are needed:

 

If the alliances are formed purely to clarify the interface specifications between the modules so that you can be reasonably sure the modules will work together, that's fine. You can even use this as a marketing ploy ("buy our module and we guarantee it will work with Team X's module"), although you should be aware that this is a risk - no matter how good a job you do on the interfaces, there may still be some integration issues, and your customers might demand their money back!

 

The following are NOT allowed:

á       Forming an alliance so that your teams can work to develop the phase 1 modules together. This is collusion, and will be dealt with according to the University guidelines for collusion between individuals.

á       Forming an alliance to shut other teams out of trading. For example, if you only sell to members of the alliance and refuse to sell to others (or if you place restrictions in the contract that have the same effect), then we will invoke the shut-out clause in the trading rules and force you to sell your module at prices that you might not like.

 

 

Plagiarism and collusion

 

Some of you have asked questions about what is allowable in terms of collaboration between teams. To help you understand what is okay and what is not okay, you should understand how the university regulations on plagiarism and collusion apply to team projects. Here is a quote from the relevant section of the calendar:

 

"It shall be an offence for a student knowingly ... to represent as one's own any idea or expression of an idea or work of another in any academic examination or term test or in connection with any other form of academic work, i.e. to commit plagiarism;"

 

For team projects, with team assignments, plagiarism shall be interpreted as any situation in which one team knowingly submits work that was carried out by another team, without explicitly declaring that this is the case. This will include collusion, i.e. any situation in which two or more teams work together to complete an assignment such that it is not possible to determine what each team did separately. Hence, if you use ideas, or work of others as part of completing your assignments, you should be very careful to distinguish the work of your team from the work of others. This applies particularly to any interface standards you might have received from others, and to any software and documentation you have purchased from others. It must be possible to distinguish the work that your team did from the work of other teams.

 

This rule has several consequences:

 

  1. If you buy from other teams everything (or almost everything) that you need to complete an assignment, you will need to indicate on the assignment what was bought and what is your own. If there is nothing on the assignment that is your own, your team will receive a very low grade (you cannot get credit for other teams' work). However, you can get credit for wise purchasing decisions (i.e. credit for being able to recognize good quality software - but only if you add enough commentary to indicate that you know why what you bought is good quality). If you fail to declare what was bought from other teams, you will be penalized for plagiarism.
  2. If you buy or receive work from others that your team subsequently modifies, integrates, or enhances, the modification, integration or enhancement *can* be regarded as your team's work. However, to get credit you should clearly indicate what it was you received from others, and what modifications, integrations or enhancements your team has made.
  3. If you form a partnership with other teams, such that several teams work together to develop the same design for phase 1, or the same integrated system for phase 2, the chances are you will end up submitting the same work for assessment. This will be treated as collusion. You need to make sure that your team develops its own software, and that the software is distinguishable from that produced by other teams.
  4. For phase 2, some of your integrated systems will look similar, because you used the same set of modules as another team. However, integration is not likely to be trivial, and the way in which you solve integration problems will make your product different from those of other teams. It is up to you to indicate on your assignments what it is that your team actually did, to avoid any suspicion of collusion with other teams. An alternative strategy is to ensure that you buy a different combination of modules than any other team (there are 3*3*3*3=81 different combinations!). If you do end up with the same combination of modules as another team, you should not share any ideas about integration with them, otherwise it will be treated as collusion.

 

If you have formed, or are thinking of forming a partnership with another team, you should read the points above very carefully indeed. Plagiarism and collusion will be dealt with very severely.