CS2212 -- Introduction to Software Engineering
Group Assignment 3

Due Date: Friday, March 16, 11:59pm
Percentage of total mark: 7%

This is a group assignment.  READ THIS ENTIRE ASSIGNMENT OVER CAREFULLY BEFORE MEETING WITH YOUR GROUP!.

Each group in the class is to hand in one separate assignment. You can delegate the individual parts of the assignment to a subset of the group members, but it is a good idea for all group members to read over the entire completed assignment before one of the members hands it in to webct.

Overview

In this assignment, your group will prepare for coding by thinking about unit testing and taking one last look at the UML Class Diagram. Your project report must be of high quality and typed. The entire assignment, i.e. the report, must be submitted as one pdf file. If you do not have pdf writer software, there is a good free one called CutePDF at: http://www.cutepdf.com. Join the pdf files for the title page, class diagram, sample test cases, test driver and test stub and gantt chart together into one large, neatly organized pdf that the teaching assistant can print off in order to grade your report.

Your hand-in should consist of the following things (see below for more details):

 

1) PDF REPORT DETAILS

a) Revised UML Class Diagram

This section should include a revised and updated version of the UML class diagram submitted for group assignment 2. Your diagram should capture ALL the systems functionality as specified in the requirements specification document. In addition, your diagram should include details such as attribute type, method parameter and return type, as well as identify which attributes and methods are public, private, etc. In order to make it easier for your teaching assistant to evaluate your new UML class diagram, make sure to use a different colour and/or font and/or weight in your diagram to distinguish all the updates you have made to the new class diagram versus the class diagram you submitted for group assignment 2.

 

b) Testing Information

This testing section consists of 2 parts:

PART 1:

In part 1, you should create a test plan consisting of a set of test cases need to completely test the system in response to users performing the following tasks (NOTE, make sure your test plan is clear, easy to read and well organized):

Each of the above tasks will likely require more than one test case in order to adequately test the task. Each test case must have the following layout:

ID: 1
TESTING: Admin User adding a new user, invalid user id
REFERENCES: Requirement 4.c.1.1
TEST CASE:
1. At unix prompt type: java UWOBoggle -admin
2. Select Add user
3. Enter abcde for user id

EXPECTED OUTPUT:
Error --> Message: Invalid user id, user id is too long

ID: 2
TESTING: Admin User adding a new user, invalid user id
REFERENCES: Requirement 4.c.1.1.
TEST CASE:
1. Enter ab for user id
EXPECTED OUTPUT:
Error --> Message: Invalid user id, user id is too short

ID: 2
TESTING: Admin User adding a new user, invalid user id
REFERENCES: Requirement 4.c.1.1.
TEST CASE:
1. Enter Pabc for user id
EXPECTED OUTPUT:
Error --> Message: Invalid user id, user id should start with a U

 Note: if there is a test case that is not possible to test because of the way you designed your GUI, for example: If a name is limited to 20 characters and you have designed your GUI so that they can't enter more than 20 characters, still put that test case in but you can indicate that the GUI will not let this happen.

PART 2:

In a neat, well organized manner (consider a table of contents to help the teaching assistant figure out what is being included in this part), print out the code for one test drivers and one test stubs that your group has written so far for individual classes or subsystems within your project. The driver and stub should be documented so that it is clear why they were being used. (If test cases are "hard-wired" into the driver, documentation can be given via comments in the code, otherwise include a separate test plan documentation for the driver and the stub that indicates what it was testing.)

 

c) Project Plan Documentation

This section should be an update of the project plan in the second report. In particular, your group should provide a list of tasks to be accomplished between milestone 3 and milestone 4 and between milestone 4 and  milestone 5. Indicate all the information for each task that was required in assignment 1. Remember to update the percentage of completion of any previous tasks and any upcoming tasks that you have already started. Make sure your Gantt chart correctly indicates who is/was assigned each task and who actually completed each task so that we know that the work is being fairly distributed.

 

2) THE .JAR FILES

When you view the Project Requirements you will notice that each requirement is numbered. We will have you submit this assignment in an Agile methodology, thus you must complete some (you may choose which ones) of the requirements for this assignment and some more for assignment 3. The following requirements must be completed:

For the rest of the project, you must have now written the code to complete at least 50% of the requirements from the list that are numbered 4.c, 4.d or 4.e

You must name the jar files as follows:

NOTE: For data persistence, you can do one or more of the following:

NOTE: for the .jar files, the t.a. will not test all of your screens so the screens do not have to all be connected yet (i.e. the button to display one screen doesn't have to make the screen display at this point) but the t.a.s must be able to get to/use the screen that will be necessary to test the functional requirements that you have implemented.

NOTE: the t.a. will take a quick peek at your code and make sure that you have included "some" javadoc comments for each method and class.

3) THE GROUP?README.TXT FILE

Your Group?readme.txt file must contain:

Tips

 

Marking

The marks will be tentatively assigned as follows.

 

Submitting the Assignment

 

Peer Evaluation (to be done individually)

Within four days immediately after this assignment's due date, complete the following peer evaluations for each individual (including yourself) in your group. For each peer evaluations that you fail to submit within four days of the due date, you will individually lose 0.5% off of your final course mark (up to a total of 2% for the 4 peer evaluations you must submit).

Click here to submit a peer evaluation  (remember to also evaluate your own performance as well as ALL your other group members)

Note: Peer evaluations can affect the final mark given to an individual so please complete these peer evaluations CONSTRUCTIVELY.