Second Progress Report Home | Contact Us

Home
Up
General Information
Syllabus
Lectures
Teams
F.A.Q.
Testing
Controversies
Digital Library Access

COMS W4156 Advanced Software Engineering

Summer 2009: Prof. Gail Kaiser

Second Iteration Progress Report
Due Tuesday 4 August by 10:00am

Submission Instructions

This assignment counts towards 10% of your final grade (5% for this document and 5% for the actual code inspection meeting).

Back to Top

The purpose of this assignment is to document the results of your unit testing and code inspection, as defined for the Second Iteration Plan.

As part of your plan, you should have already selected for testing one non-trivial "unit" of your code for each pair in your team (that is, two units for a team with two pairs, and one unit for a team with only one pair/trio).  If there were any deviations from the units originally chosen, state so and explain.  In your unit testing report, describe the set of black box equivalence classes and corresponding boundary values, where applicable, actually tested. Elaborate how you ensured that your test suite covered the unit's statements, and how you tracked the coverage (e.g., did you use some coverage tracking utility?). Indicate any statements that were not actually exercised, and explain the problem. (You do not need to cover all paths, but should still try to cover most branches; it is ok to omit testing of any hard-to-reach exception handling statements, but you still need to explain why they were hard to reach.) You do not need to include any bugs found as part of this section, that is for the defect log below.  Submit in additional files the actual code for the unit(s) tested as well as the complete set of corresponding unit tests, including any sample data, scripts, stubs, drivers, etc., along with detailed instructions on how to set up the environment and run each test case. Annotate the test cases and additional materials with labels referring back to relevant portions of this section or the defect report.

Additionally as part of your plan, you should have already selected for code inspection a different "unit" of your code for each pair in your team (if it had to be the same unit, explain why). Again, if there were any deviations from the units originally chosen, state so and explain.  You should have held a code inspection meeting together either with your TA or in class, with all team members present. Describe the actual conduct of the meeting.  When and where was it held? Who was the "reader" for each unit? How long did the meeting actually last?  Did you finish getting through the unit(s) within the time allotted? Which other materials, if any, were used during the meeting (e.g., looking up other parts of the code)? Were there any "problems" related to the conduct of the meeting? You should have already defined a checklist for your code inspection meeting as part of your Second Iteration Plan.  Discuss how the checklist was used in practice.  Did it help you find flaws?  Which ones? (This part should be cross-referenced to the defect report.) Submit in additional files the actual code for the unit(s) inspected, annotated with labels referring back to relevant portions of this section or the defect report.

Provide a complete defect report (or log), listing all the defects found, whether during unit testing,  code inspection, or otherwise.  Distinguish between logic errors (bugs) and non-logic coding problems (e.g., lack of adherence to coding conventions, lack of adequate comments, general unreadability). Each defect should be associated with an action item, usually either to fix the defect (if obvious how to do so) or investigate further (e.g., develop new test cases, careful debugging). Indicate which action items have already been completed and which are still "to do".   

Back to Top

Deliverables:

Submit an archive file, whose main document should contain the following sections in the specified order.  Missing sections, sections out of order, or difficulty in finding a section will result in a failing grade.  Maximum section lengths are requirements, not just suggestions.  By N pages, we mean N pages when printed, which is not necessarily the same thing as screenfuls. Graders will not read beyond the specified maximum pages (except for illustrations).   Illustrations do not count towards the page limit, that is, there is no a priori limit on the number of pages of figures, mockup screen shots, etc., but please be reasonable!

Note that maximums lengths are indeed intended as maximums, not "suggested" lengths; shorter is almost always better than longer, provided all the requested information is included.

1. Cover page (1 page): Indicate the name of your team and list all team members with their full names and email addresses. Indicate that this document presents your Second Iteration  Progress Report.

2. Unit Testing Report (maximum 3 pages, do not include code here here unless necessary to demonstrate some point).

3. Code Inspection Meeting (maximum 3 pages, do not include code here unless necessary to demonstrate some point).

4. Defect Log (no maximum length).

5. Controversies (1 page): If everyone in your team agrees 100% with your proposed system as elaborated thus far, state so (in which case that would be all you'd need to write in this section).  Otherwise, briefly explain any disagreements, ongoing arguments, or other controversies.  It is not necessary to indicate which team members hold which positions. Note controversies might include the fact or impression that some team member is not contributing his/her fair share to the project.

Additional files in the archive should include:

6. Code of tested unit, Code of inspected unit, Unit Test harnesses, sample data, etc.  Everything should be annotated in such a way that it is easy to cross-reference with your main document. 

Your main document must be formatted in MS Word, Adobe PDF or plain text (with any separate diagram files easily viewable on any conventional platform, e.g., using a Web browser).  No other formats will be read or graded.  It is your responsibility to ensure that your files are virus-free prior to posting. 

Back to Top

Submission Instructions

  1. Make sure the archive file name clearly indicates your team's name and the name of the assignment, e.g., FourMusketeers-secondprogress.tar.gz
  2. One member of your team should email the file to swapneel at cs dot columbia dot edu
  3. All done!

Back to Top

 

 

Home | Up | Pair Formation | IDA #1 | IDA #2 | Project Concept | IDA #3 | Revised Concept | First Plan | First Progress Report | First Final Report | MIA | Second Plan | Second Progress Report | Second Report | FIA

Copyright © 2007 Trustees of Columbia University in the City of New York.  All rights reserved.

Report broken links or other problems with this website to the instructor.