CSC 307 Introduction to Software Engineering Individual Assignments

Weekly Timesheets

Due: Every Monday at 2:10pm, Week 10 due 6/6/08 at 2:10pm

Self/Peer Evaluation

Due: 5/9/08 and 6/6/08 at 2:10pm

Students will complete a self and peer evaluation midway through the quarter and again at the end of the quarter.

Reading Quizzes

Due: Unannounced quizzes will be given in class on a regular basis

Short quizzes will be given in class on weekly reading assignments.

UML Diagrams

Due: 4/11/08

Each student should prepare a UML diagram using ArgoUML. The diagram should be exported to an image and added to their team project wiki and sent via email to Dr. Janzen (djanzen@calpoly.edu). Each team should prepare one of each of the following diagrams:

Class Diagram
Sequence Diagram
Statechart Diagram
Activity Diagram
Deployment Diagram

The class diagram should be created collaboratively by the team during lab. Team members should then assign one of each remaining diagram to be completed by individual team members. The diagrams should represent a first attempt at high-level architectural decisions for the course project. For instance, the class diagram could have the classes bracket, match, team, and location. Each class should have at least one attribute and at least one operation. The sequence diagram could show the interaction between the bracket, match, team, and location classes in order to add to the bracket a match/game that will occur at a particular location. The statechart diagram might show the possible states of a bracket (e.g. first-round matches assigned, partially completed, locked, ...). The activity diagram might show the steps involved in an add match method in the bracket class. The deployment diagram might show what components (groups of classes) might be found on the web server and client browser.

Don't worry about getting the elements (classes, states, methods, ...) correct. Focus on learning UML and ArgoUML. Save your files as you will probably revise these models in the near future.

Subversion Checkin

Due: 4/14/08

Each student should complete the following with their team svn repository.

Create a text resume that documents your particular skill areas and software-related experience. Add the resume to your repository and commit the changes.
Modify your resume in some way. Commit the changes.

Each commit should include a descriptive comment explaining the motivation for and characterization of the change.

JUnit

Due: 4/23/08

Each student should complete the following:

Implement a class from your team project class diagram.
Include at least three methods, at least one of which must be more complex than a simple getter/setter.
Write JUnit 4 tests for every method of your class.
Print the source code for both the source and the test classes.
Deliver the printouts (with your names on them) to Dr. Janzen at the beginning of class on 4/23/08

GWT Modification

Due: 4/28/08

Each student should demonstrate their understanding of the Google Web Toolkit and the provided project prototype by modifying the prototype in one of the following ways:

Option 1: Password Checker
- Change the background color scheme of the bracket to green and yellow
- Add a password text box and a "Check Password" button above the "Save Bracket" button
- Add a passwordChecker service that runs on the server and checks to see if the submitted password is in a list of passwords that are stored on the server
- Connect the "Check Password" to the RPC service and respond with either a "Valid Password" or "Invalid Password" message
Option 2: Username Recorder
- Change the background color scheme of the bracket to red and blue
- Add a text box and a "Store Username" button above the "Save Bracket" button
- Add a usernameRecorder service that runs on the server and stores the username in a file on the server
- Connect the "Store Username" to the RPC service and respond with a "Username Stored" message
Option 3: Name Reverser (to be completed by solo programmer in team osos)
- Change the background color scheme of the bracket to orange and blue
- Add a check box with the label "reverse" above the "Save Bracket" button
- Modify the submitBracket service to store the bracket team names in reverse order if the check box is checked

The prototype is available on the course Trac project site. The modification will be demonstrated to Dr. Janzen during lab on 4/30/07. Team members should work in pairs to complete this assignment. Each pair on a team should choose a different option. One person should complete the user interface portion and the other person should complete the server-side portion. The two should collaborate to complete the RPC connection. Pairs may ask questions of other pairs, but should not receive direct assistance or view code of other pairs.

Code/Unit Test/Test Coverage

Due: 5/16/08

Each student should develop code and unit tests for the course project. Students should select one segment of code (probably a class) and the corresponding unit test that they wrote, along with the corresponding test coverage report. The code/test should be reviewed during class by the team. Students should provide a print out of the code, unit test, and test coverage report at the end of class.

Software Inspection

Due: 5/16/08 Artifact to be reviewed should be posted on team wiki

Due: 5/21/08 Report is due to Dr. Janzen at the beginning of class; All artifacts should be posted on your team wiki

Each student should have one code/unit test artifact reviewed during class on the first due date. The review should follow the guidelines of a typical review.

Each student should prepare a report that includes the artifact inspected, names and roles of everyone involved in the inspection process, notes from the inspection, defects found, and changes to the artifact resulting from the inspection.

The report should have the following sections:

Names of Author, Moderator, Recorder, and Inspectors
Date of Inspection
Artifact Inspected (artifact exactly as it was when inspected)
Artifact After Improvements (artifact with all defects corrected and approved suggestions incorporated)
Notes from inspection
List of defects found; for each defect, discuss the root cause of the defect and the correction made
List of suggestions to improve artifact; for each suggestion, discuss whether you agree or disagree with the suggestion and why; discuss any changes made resulting from the discussion

Artifacts should be small enough to be reviewed in about twenty minutes. Software artifacts will typically be a class but may be a single method.

Acceptance Testing

Due: 5/30/08

Each student should execute functional tests on one application produced by another team in this course. Students should complete a minimum of five tests. You may complete as many tests beyond the five each as you think are appropriate. You are not given a set of tests to complete. Once you have become familiar with using the system, devise your own set of tests to execute. Some tests should verify that the system works correctly with proper data. Other tests should verify that the system appropriately rejects/handles incorrect data. Feel free to try things like using different browsers, using different resolutions, using a slow network connection, attempting to breach the system's security, ... Be creative. Be careful, however, not to impact any Cal Poly or other systems or networks, don't break any laws, and don't do anything unethical!

For each test executed,

Print and complete an Acceptance Test Form. Or you can complete the form directly in the Word document.
If a defect is found, check the corresponding defect tracking system to see if the defect has already been reported. If not create a defect ticket.
If something does not work as you think it should, but you are unsure if it is a defect, go ahead and create a defect ticket.

Complete all testing and turn in your printed test forms in class on the due date. Also include a count of how many tests you performed, how many defects you opened, and how many times you crashed the system.

Impact Analysis

Due: 6/2/08

In pairs or solo, complete the following:

Suppose you are given the task to modify your system in each of the following ways:
- Add a team logo for each team on the GUI
- Allow an extra game between two teams who compete to be the 16th seed in one region of the bracket
Document an impact analysis electronically. Use this template as a guide (consider contributing to the Norm Kerth fund). You don't have to do everything in the template, but use it as a guide for your own impact analysis report. The analysis should be as specific as possible within a three-page limit (one page for the logo, two pages for the extra match). For instance, note specific classes that will need to be modified, changes to the requirements and architecture, tests that need to be written and/or changed, ...
Send a copy to Dr. Janzen.