COMS W4156 Advanced Software Engineering
Summer 2009: Prof. Gail Kaiser
Second Iteration Progress Report
Due Tuesday 4 August by 10:00am
This assignment counts towards 10% of your
final grade (5% for this document and 5% for the actual code inspection
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
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
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
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
- Make sure the archive file name clearly indicates your team's
name and the name of the assignment, e.g.,
- One member of your team should email the file to swapneel at cs dot columbia dot edu
- All done!
Back to Top