Deliverable 5 - Part 1

We met today at our normal time to finish our project. We had code changes, a presentation, a poster, and various other things to be done. This enabled us to have a nice division of labor for completing things simultaneously. I personally tried to work mostly on the final document that was to be handed in.

We got everyone started on their part of the final project. Most of the presentation was planned, the document was mostly done and outlined, and the poster progressed greatly. We plan to meet again on Tuesday to finish up everything and do our practice presentation runs.

Final Meeting on Deliverable 4

This meeting we are finishing Deliverable 4 and the patches to deliverable 3 required. We tackled the problem with ordering of file names easily, as we did with getting the html output file to open automatically. All of our tests were already created, so that was done. Our output still isn't that pretty, but it's readable. We're gearing towards deliverable 5 already by planning everything out.

Meeting on Deliverable 4

We met again on Sunday in order to do the bulk of our work on Deliverable 4. Deliverable 4 was simple in principle - fix the problems with the third deliverable, and add another 15 test cases in order to obtain 25.

We started to develop a majority of the code changes to deliverable 3 that we had previously sketched out. We fixed our documentation for deliverable 3 and finished most of the documentation for deliverable 4. If the code we plan to implement doesn't work properly we'll have to go back and fix these changes, but at the moment it is theoretically sound. Coming up with the extra 15 test cases wasn't difficult at all - we incorporated another method that compared strings (by checking if the second string was an exact component at the beginning at the first one). We went back and added two test cases to our previous method as well. We'll meet again before our deliverable is due to solidify any code changes that haven't been finished by then and rework any documentation that needs to be gone over again.

Chapter 24 Thoughts - Quality Management

Having a good structure for a quality assurance plan seems important to the process. Without documentation it's harder to keep the same level of quality assurance constant - it is unlikely the entire quality assurance team is going to have the equivalent of a modifiable document memorized.

Having clear requirement is obviously important to the quality management process. Without requirements there isn't a measuring stick for quality assurance processes and standards to measure up against. Speaking of standards, software standards should be met whenever they apply to the situation.

Inspections and reviews was an interesting section to go over. It's more than just normal testing and seeing if the project works within specifications - it's about potential problems and measuring quantitative relationships and statistical information on the code itself.