EGAD - Expert Generic Algebra Designers

Individual Program Analysis by Symon Perriman

 

Technical Review

Team Review

Grading
Technical Review

 

Time Review
For the first couple of days of the project I spent very little time on it because I had four consecutive midterms (2/23 - 2/28).  After that point I was basically done with work until spring break so I spent 3 - 5 hours each day, though some days I spent up to 8 hours.  The team began on 2/23 and finished on 3/11, so in total I probably spent 40+ hours on the project.  There were five distinct time-consuming parts to this program: planning/learning, refactoring/debugging, coding/testing/debugging, and documentation, and meetings.  The first part included analyzing the given code and determining how to break it up (refactoring) since we decided to use templates.  The whole group was unfamiliar with templating, so we spent some time learning about this.  I probably spent around 3 hours doing this, less that the rest of the group because this was the initial step that occurred while I was overloaded with midterms.   The second part was refactoring the code to use templates.  Aaron spent a majority of the time on this because he was very insistent on using templating and seemed to understand it the best.  I probably spent around 15-18 hours writing various classes and functions for our updated program.  This section took the most time.  Next was various other coding, testing, and debugging which includes adding arithmetica2 and imagemetica since they basically adapted changes from the newly refactored arithmetica.  I spent a lot of time on this section adapting the code for arithmetica2 and imagemetica - around 10 hours.  The documentation included: the user's manual, the programmer's manual, the doxygen document (although this took no time), and the ReadMe file.  This also probably took around 8 hours as a lot of the required section were repetitive between the two manuals and features for arithmetica, arithmetica2, and imagemetica were similar.  Around 3-4 hours were also spent meeting with group members and the TA.

 
Planning
We decided to refactor the program and use templating.  This decision was made to make the program more extendable and helped when we added arithmetica2 and imagemetica.  It did however take much longer than planned as we had a lot of trouble and errors in our code because of our limited templating knowledge, because of this the program took at least three times longer than expected to finish.  We did however follow the plan and finally got our program to work.  Each team member was used effectively as Aaron worked on the program architecture and programming, and Will and Symon worked on the programming and documentation. 

 
Status
The program accurately reflects our planned design as it uses a base templating structure that easily extended to incorporate arithmetica, arithmetica2, and imagemetica.  The design did not change much as it was realized in code, it was just more complicated than initially expected.  I like that fact that our design made it easy to add the different applications, but found the templating confusing.  I liked how easy the code was to understand when adding the different applications, I found it very expandable.  All of our design worked when we tried to code it (I believe), but we had a lot of trouble refactoring it.  Overall I think it worked out well, eventually.

 
Conclusions
The program works fine, but unfortunately, due to time constraints, not all of the specifications were met, such as some of the functions.  These could likely be done with little trouble since they follow a similar structure as other working parts of the program; it is just a case of punching them out.  Our design turned out to be good, even though it was confusing and time-consuming to create.  We had problems with errors when we initially refactored the program, most of which were due to templating.  These errors took several days to resolve and slowed our progress.  These defects would be reduced in future programs simply because of our new knowledge of templating.  These sections of code required a lot of reworking.

 
Future work
Making the project better:
               Implementing all functions - Due to our time constraints, not all of the functions worked for the applications. 
                          With more time these would be added to improve usability.
     Improving templating documentation - Since the group found this part so challenging, it would be helpful to
                others looking at our code if we explained 'how' each templating part worked in more detail.
               Ability to catch more bugs or erroneous input - Due to our time constraints, we were unable to catch every
                          exception during testing.  This is another item that would be improved with additional time commitment to the program.
 
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 myself, Will Fleming, and Aaron Wise.  The only outside collaboration was with the TAs Ben Pollack and Ben Wolf.  The team worked well together although we found that living on separate campuses an inconvenience when we had to get together.  Since I was the most proficient in C++, Aaron knew basically only Java, and Will was somewhere in between we used this to our advantage when planning roles for each person.  I worked mostly on detailed programming in C++, such as specific functions.  Aaron worked mostly on overall programming architecture because he had a good overall structural vision for the program.  Will worked with both of us on both the overall structure and detailed parts of the code.  We split our time working alone and together since we had both specific parts of the program to work on and larger structural parts that needed to be linked.

 
Planning
The team communicated daily either through meetings, via email, or AIM to keep each other updated on the status of the program.  We met probably four nights a week and worked on the overall structure for a couple of hours, then separated and worked on our specific parts for several more hours.  I managed the project individually by making sure I was up-to-date with each section of code that would be required for the following day and constantly communicating with my group.  We managed the project as a whole by either working on separate files so there was no deadlocking, or if two people were working on the same file, one would email their work to the other to compare/add to their updated file, then that compiled file would be uploaded to Eclipse.

 
Status
Our team worked well together.  There were just some periods of time when only two group members could commit to the project for a couple of days because of either tests, or a sickness, but overall this was not a problem.  Since there were no problems there were no warning signs of trouble or any other issues along those lines.

 
Conclusions
I believe that our good planning and communication gave us a successful project.  By constantly communicating and meeting we knew how we were doing and followed our plan from the beginning.  I think we were each assigned to the right roles based on our C++ abilities.  We didn't necessarily underestimated the size of the project, but underestimated the time it would take by several times as much.  We also didn't think that the refactoring and templating would be as challenging as it was.  Our method of estimating time was flawed since we underestimated the complexity of our changes since they were a new application for all of us.
 
 
Future Work
I learned to not underestimate the time it would take to change the program if a new application (templating) was to be added.  I would also make sure to have more time at the end of the program to test and debug.  Reviewing my previous personal goals I met most of them by working well together and communicating effectively, but we failed to manage our time effectivley because of the major problem we had with our program.
 

Grading

Grade: B +/-

Justification: Our program works even though it is not completely implemented.  Our documentation is very complete and clear for both the user's manual and the programmer's manual.  Our test cases our very complete.  We have a good deign and coding by refactoring and using templates.  Overall the code of our product is good, and the program could easily be made great with just a little more time to achieve complete functionality.

Related Pages:

Project Home

User's Manual

Programmer's Manual

 Doxygen Documentation

Homepages: CPS 108 | Will Fleming | Symon Perriman | Aaron Wise