CS 481 - Team 49 Meeting Minutes Weekly Team Meeting - Concept Proposal Presentation Friday, September 14, 2007 10:30 - 11:30 AM JEB 324 Recorder: Brandon Riggers -------------------------------- Meeting Summary This meeting consisted primarily of our Concept Proposal presentation. Peter was the speaker, and Bill and Bruce (who was with us over the phone), provided questions and input throughout the presentation. Attendees Brandon Riggers, Shruti Upadhyaya, Peter Brown-Hayes, Travis Thoroman, Bill Junk, Bruce Mayes (over the phone) Topics Discussed - Concept Proposal presentation As Peter discussed the points on each of the Powerpoint slides, Bill and Bruce gave their input: Product Highlights - Bruce commented that our product will give a measure of entire turmoil or, given a list of files, measure turmoil on those specific files. Bruce also mentioned that in the end he needs the "entire package" of our product, which includes test cases and documentation. Bill also mentioned that our program should never leave temporary files on the system. Use Cases - Automatic and Full Freeze Automatic: At the beginning of these slides, Bruce brought up the 'Cruise Control' tool, which looks at Subversion and emails a distribution list when an integration is introduced. Therefore, our tool will have to "marry up" with this tool. We can expect it to run inside a script, and we'll need to add a block to the email Cruise Control creates that describes the turmoil introduced. Full Freeze: Bruce will give us a list, and we'll measure turmoil on the files between two "labels" or "tags." These "tags" should be frozen or locked when our tool is running. Architectural Approach - Testing Strategy Bill commented on our introduction of change between 1% and 99% on a file, saying that we should include "no change, to complete change" and suggested that percentages might not be the best way to describe this. Bill also asked if the additions, deletions, and changes are to be distinguished in the turmoil report. Bruce says they are, but we have to keep the scope of the project in mind. Bruce also mentioned that we're testing the diff utility, and we won't always have to test the whole product. Bruce brought up the need to test for correlation with historical data, and Bill agreed, saying this should be a 3rd point on our testing slide. Architectural Model - Bruce mentioned that the 'command line interface' and the 'user scripts' boxes in our model could be the Cruise Control tool. Bruce also asked when we'll see the 'metrics engine' portion. Risk Analysis - Risks Discussion began about choosing the correct path, and the different diff utilities. Bruce's concern (again) is weather svn diff is giving a good enough report for us to determine the adds, deletions, and changes. Bill then began discussing Perl and its various versions. He mentioned that he could be "making a leap that we're going with Perl" as our language, and suggested those who aren't up on Perl, to start writing in it. The discussion of Perl continued into the next slide. Risk Analysis - Solutions Bill continued by saying that we should adapt a type of "internal review process" where those who know Perl better look over those who might not and help out. Bill said it's feasible for us to talk through our code (it should be small enough, for this project), and that this works very good for us all to understand the code - those who wrote it and those presenting it. Bill also addressed our "sickness" bullet on this slide, saying that we should "shift responsibilities around" when we need to. Schedule - Upon a first look at our schedule, Bruce talked about how we needed to make a major design decision soon (by next week). Bill then talked about a software release, saying that we would freeze the code 5-7 days before the release date, and there are a lot of "procedural things" we have to take care of for a release. Bill pointed out that we only have 2 weeks to to get 95% of the code for release 1 done, and brought up the possibility of compromising anything for the release if we need to. Bruce agreed, saying that we need sufficient time to get the tests, code, and documentation together. Bruce also pushed toward making a decision now of using svn diff, asking if we could "afford the luxury of waiting until next week to decide." Bill then suggested we take on "parallel paths" of work, because we don't necessarily need to know which diff utility we're using to make certain design decisions. Some people can focus on the diff investigation, some can focus on design. We should "do the studies" with svn diff, and begin designing/writing. Mapping Requirements - Bill discussed how we can expect to aim for some performance enhancement, particularly between release 2 and the Beta release. Bruce then mentioned that it "wouldn't bother (him) if one of our releases focused on correlation with historical data." The discussion shifted to looking ahead when the presentation was over. Bruce mentioned that it's been abstract to this point, and Bill began talking about our formal documents. He expressed the need to to get started on a functional specification. We can make the presumption that our tool will be invoked via the command line, so we should map out what the command line looks like, including arguments and input. We also need to identify the definition of turmoil, and what we're going to produce. However, we don't have to say HOW anything is going to happen (at this point). There is a format to these specifications (see the CS 480 web page), but generally there are 3 sections: boiler plate, executive summary, details of what the product is going to do. Bruce then expressed the need for a "regressible harness" with our tests, saying that we need to identify where something failed, and Bill included the idea of a test script being run against the change we're made in the code. Before the call with Bruce ended, we agreed on a decision by Friday at the latest. Bruce talked about a small test that has a Perl wrapper, 1 to 2 dozen files, and produces human-readable output, for the purpose of he and us comparing the use of the different diff utilities. (We need to be able to verify that the metrics engine is running the same in both places - for Bruce and for us.) Bill concluded the meeting by mentioning the need for a push during the next 3 weeks. He also brought up using the PRS to record our defects, and that individual code needed to be made available to the rest of the team starting one week from this meeting (next Friday). He also said we needed to have our documents archived somewhere, and that we'll need to get CVS on our team account. Overall, the presentation went well, with Bill telling us he has "confidence that we're on the right track, and that we'll get the first release done."