CSC 307 Introduction to Software Engineering Individual Assignments

Each student should create a portfolio at Google Sites that contains all of the items below. The portfolio will be presented to Dr. Janzen and graded in individual interviews during finals week.

Resume

Due: at 2:10pm on Day 1

Write a very brief resume that addresses the following:

1. Name
2. Preferred Role: e.g. team lead, requirements analyst, architect, developer, quality assurance, build/environment/tool master
3. Who I want to work with (one or two individuals in the class that you would like to have on the same team, can be blank)
4. Times I am available to meet outside of class (e.g. MWF 4-6pm, TR 3-5pm, Sat 1-5pm)
5. Technical Strengths (e.g. web, Java, php, database, svn)
6. Organizational Score (i.e. how organzied are you? 1-excellent, 5-awful)

UML Diagrams

Due: 1/25/11

Each student should prepare a UML diagram using some electronic UML tool (e.g. ArgoUML, Violet). Each team should prepare one of each of the following diagrams:

• Class Diagram
• Sequence Diagram
• Statechart Diagram
• Activity Diagram
• Deployment Diagram

Subversion Checkin

Due: 2/10/11

Each student should make numerous svn checkins of their work to their team svn repository. Capture a screen shot that demonstrates one of these checkins using the browse source feature in Trac. Your commit should include a descriptive comment explaining the motivation for and characterization of the change. Post the screen shot on your portfolio.

Unit Tests

Due: 2/15/11

Each student should complete the following:

1. Implement some code (class or method) from your team project that is non-trivial (e.g. not a getter/setter).
2. Write automated unit tests for your code (at least three tests).
3. Post the code and tests on your portfolio.

Metrics

Due: 2/17/11

Each student should post on their portfolio at least three metrics calculated on code from their project that they wrote. At least one metric should be code test coverage. See these instructions on how to get code coverage in GWT.

Software Inspection

Due: 3/1/11

Each student should have one code/unit test artifact reviewed by their teammates. 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: 3/3/11

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!

Coordinate with your own teammates so that no more than two of you tests the same system.

• Irwin
• Creel
• Park
• Belis
• Chan
• Selzer

For each test executed,

• Print and complete an Acceptance Test Form. Or you can complete the form directly in the RTF document.
• Post your completed form on your portfolio.
• Email your test records to the team lead for the team whose system you tested.

Impact Analysis

Due: 3/10/11

Each student should complete the following:

• Suppose you are given the task to modify your system in each of the following ways:
  • Allow instructors to add a logo image that would appear at the top of every step.
  • You just found a really great web-based UML editor that uses HTML 5 canvas and javascript. Allow instructors to be able to add the editor into a lab step.
• 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 two-page limit (one page for each change). 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, ...
• Upload your impact analysis to the Digital Dropbox in Blackboard. Name it IAdjanzen.pdf, but replace djanzen with your calpoly.edu username.

Code

Due: 3/10/11

Each student should upload to the Digital Dropbox in Blackboard the one piece of code from their project that they are most proud of writing. Change the file name to be djanzen.java, but use your calpoly.edu username. In the Blackboard upload comment, clearly state what portion of the code you wrote.

Self/Peer Evaluation

Due: at final exam

Students will complete a self and peer evaluation at the end of the quarter. This does not need to go on the portfolio, but should be completed on the paper provided.