Finchum & Perriman

Kwic Project

Individual Analysis by

Symon Perriman

Technical Review

Team Review

Grading
Technical Review

 

Time Review
I estimated I spent an average 2-3 hours each day, though some days I spent up to 8 hours.  We began on 2/4 and finished on 2/16, so in total I probably spent 25-30 hours on the project.  There were five distinct time-consuming parts to this program: planning/learning, coding/testing, debugging/implementing, documentation, and meeting.  The first part included writing program or function flows and learning how to do new processing that I did not know before, such as different sorting techniques for arrays and an attempt at operator overloading.  I spent most of this time browsing the web for various C++ website with the relevant information.  I probably spent around 8 hours doing this.   The second part was the coding which was probably another 8 hours.  This was just time spent writing code and functions then testing them so that they worked independently and they could not be broken.  The third section was debugging and implementing.  This was basically adding new classes of function that worked independently into the entire program so that they worked within the entire program.  This probably took 2-3 hours.  The final part was the documentation: the user's manual, the programmer's manual, and the ReadMe file.  This also probably took around 8 hours as a lot of the required section were repetitive between the two manuals.  Around 3-4 hours were also spent meeting with group members and the TA.

 
Planning
We began with an initial plan and followed it throughout the project.  We decided to use James' basic framework since he used classes then create three separate parts for the program: input, sorting, and output.  The fourth section of the program was the documentation.  We split up the work so that we each did two section so as to use each person in the team effectively.  I did not expect the project to take this long, especially the documentation.  In the future I would be ready to spend more time on the documentation.

 
Status
The program accurately reflects our planned design as it is basically broken up into three parts: input, sorting, and output.  The only changes is design as it was realized in code is the order of some processes.  We had to use the toUpperCase() function later than we had initially planned so that we could compare words to regular expressions, but for the most part we followed the plan.  Also we ended up using the wordsBeforeAfter() function to append the words to the keyword later than initially intended, but these two items were only minor.  The design and code was understood.  The part of code I disliked was the selection sort I used which requires O(nē), given more time I would have used a merge sort which is O(n*log(n)), however I could not implement this without first converting the array into a linked list, sorting it through a recursive binary tree method, then placing it back into an array.  There were no parts of the design that did not work when I tried coding it except for the afore mentioned merge sort function.

 
Conclusions
The program works exactly as it was specified with all possible exceptions accounted for (I think) and there are no known bugs.  I would like to make the program faster/more efficient by implementing a merge sort instead of the selection sort I used.  The most frequently occurring defects were just array out-of-bounds errors for the various sorting methods.  These took some time to fix and they were fiddley, but they were easily found.  The code that required the most rework was trying to use the same sorting function to sort an int (word.length(), number of occurrences) and a string (word.keyword).  Our original design structure was solid so it did not require much reworking.
 
Future work
Making the project better:
               Sorting: As mentioned before I would like to have a faster and more efficient sorting function of the O(n*log(n)) size such as a merge or
                     heap sort.  This would make sorting large data much quicker.
     In-Program File Input: If the user does not enter a name for file(s) in the command line, the program will prompt the user for an input.
               Separate Properties Executable: The user would be able to use a menu-based options program to change the kwic.properties
                    options so that they did not have to edit directly through the text file.
 
Since the program works the only thing  I believe would help my grade is adding the additional functions and making it faster.
 

Team Review

Description
The team consisted of Symon Perriman and James Finchum.  There was no outside collaberation with the exception of the TA, David Winslow.  The team worked together because we both requested to work with someone who programmed using the same code, C++.  Physically working together was tough since we had very different schedule and lived on different campuses.  We each took on two of the four main parts of the program: input, sorting, output, and documentation.  James worked on the input and output, and I worked on the sorting and documentation.  We worked for the most part very separately on these sections of code and got together when we added the sorting methods to the rest of the code.

 
Planning
The team appeared to be solid in its C++ knowledge which was good.  James was very proficient in using classes as he had an extensive class-based programming course in CPS110.  I did not know much about classes since I rarely worked with them in the past, so this was a good opportunity for me to learn.  We spoke about the project in class every day and had about half-a-dozen other meetings to check how we were doing.  We communicated several times a day by email to make sure we weren't working on each other sections so that we did not overlap code and spoke via instant messenger or phone when necessary.  I had trouble using eclipse to compile for most of the project since I downloaded a bad (?) MinGW package, so I wrote code on a separate compiler and emailed it to James.  I also had trouble resubmitting code that I had written via Ambient.  Since we worked, for the most part, on separate sections we got together when we needed to the manage the project as a whole an integrate it, specifically the input to sort to output sections.  Our system worked fine and there were no conflicts.
Document your initial thoughts about the team, including the initial meeting and plans to keep communication flowing with the team.

 
Status
Our team worked reasonably well together.  I felt by decided to use James' initial framework that would eliminate any problems of "my code is better" machismo.  Since there were no problems there were no warning signs of trouble or any other issues along those lines.

 
Conclusions
I believe that our planning and communication was good and led to a successful project.  We emailed each other several times a day to let each other know how we were doing and followed our plan from the beginning.  I think that either of us could have done any of the four separate section to the code, so it is hard to determine if the 'right people' were assigned to the right role.  I  don't we underestimated the size of the project, but underestimated the time it would take by many hours.  There were many problems with regular expressions that we were not expecting.  Other than that we did not procrastinate, so we finished each deadline before it was due.  I believe that we underestimated the time it would take because of small 'bugs' that we had, for the most part we finished the project in the time we expected.  I also wasted a lot of time trying to change the selection sort into a merge sort and ran out of time in the end and was unable to implement it, so that was frustrating.  I also feel that James, to his credit, spent longer on the program that I did.  He had more free time during the days so he took advantage of it which I appreciated very much.  To try to make up for that I insisted on doing all of the documentation, however I still feel he spend more time overall.

 
Future work
I learned to not underestimate the time it would take to get out the bugs and make the program work 'perfectly.'  It worked very well from early on but the few details took as much time to implement as did the major part of the program.  I would follow a similar plan that we used for the program for future ones because I feel it worked well.  We started work on it early on, so we did not stress out about it as the deadline approached.  We split up the work into specific assignments so that helped us focus on our code without worrying about needing to adapt to the other person's code for a function.  Reviewing my previous personal goals I think I/we met them for this project as we worked well together, communicated effectively, managed our time well, and created a solid, working product at the end.
 

Grading

Grade: A-

Justification: Our program works well and meets all specifications.  There are no know bugs.  Our documentation is very complete and clear for both the user's manual and the programmer's manual.  It could sort faster than it is, but we are not being graded on efficiency, so this should not really matter.  We could have more classes to make the program structure clearer for another user or to make it easier to add additional functions.

Related Pages:

Project Home

Programmer's Manual

Homepages: CPS 108 | James Finchum | Symon Perriman

E-mail: James Finchum | Symon Perriman