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.

Impromptu Meeting To Fix Deliverable 3

Today Nelson, Crendall and I attempted to fix at least some of our deliverable 3. The fixes we included were changes to the code and generalizing the test generation, as well as changes to the document. Changes to the document included things such as names, date, context, and filling out in greater detail how our tests work. Test cases requirements were specified further than reference,  and the how-to section was revamped all together to specify how to add and remove tests as opposed to how to run the framework in general.

Some Thoughts on Chapter 22

None of the important easy to see goals nor the problems of managing a software engineering project listed were surprising. We know by now that our projects are intangible, unique, and always changing, and actually doing what we say we will do is important to keeping customers happy. None of the responsibilities of the project manager were particularly surprising either.

That being said, risk management, managing people, and teamwork are all very important to the success of a software project. On some levels I feel like the management of people will lend itself to having certain elements of teamwork. Someone who is good at managing people is going to facilitate communication especially. While most of the important points in teamwork and people management seem obvious, they are obviously important and not always done correctly despite this.

Deliverable 3 Complete

All of our members showed for our last meeting before deliverable 3 was due, which was nice. Together we targeted different parts of the problem, such as the pdf file, oracle, test specification templates, and the script itself.

We encountered some problems getting it to compile correctly at first, at least having it do so automatically. We soon passed that first problem using the java compiler, and ran into other problems actually executing everything. Unfortunately these setbacks with java and the java compiler set us back quite a few hours.

While some of us were tackling that problem we were able to complete the other parts of the project and conceptualize what was needed to be done.

Unfortunately while we've sketched out the rest of the program this one problem proved rather difficult and as of the time of this time of posting is still a roadblock for us.