View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

The REAL A-Team Case Page

We are THE ONE AND ONLY A-TEAM...any others are IMITATORS (go here for an example)

The A-Team Soldiers:

-Kevin Gorham (GUI Specialist)
-James Lee (UML Specialist)
-Ryan LeRoy (Back-end Specialist)
-Omari Worthy (Design Specialist)

Project Overview

You can find a overview of the project that we had during the Spring 2003 semester here. But basically, our project was to create a small investment portfolio manager. The purpose of the application was to manage for a given individual user a set of portfolios containing different types of accounts. The full application was web-enabled and was a complete financial management simulation.

Forming/Working With an "A" Team

START LOOKING EARLY - Take our advice and begin looking for potential team members as soon as possible. Because a good month or more goes by before you have to form a group, try to meet different individuals and find out how they are doing in the first milestones. Try to get a feel for their work ethic, attitude (towards the course and you), and what grade they are willing to get out of the class (notice we did not say the grade that they want, because everyone wants an 'A', but not everyone is willing to put forth the effort). If you are taking 2335 concurrently with this class or have already taken 2335, learn from its lessons and apply its tips concerning what to look for in group members.
FIND OUT WHAT EVERYBODY DOES/LIKES BEST - Once you have your team together, go around and find out what each member likes to do best (testing code, back-end, GUI's, etc) and what their coding strengths are. This is a must, because assigning just ONE member a task that they are not good at or thoroughly hate can result in a whole milestone going down the drain (maybe even the whole project). Also, once the group has an idea of what each member prefers to do and has the ability to do, then with each milestone, it is easier to delegate tasks.
MEET AT LEAST TWICE A WEEK - Even though you will probably have 2 weeks to complete each milestone, meeting only once a week, while convenient, will surely result in team members losing focus of the main objective for the particular milestone. Also, even if the first meeting of the week serves as just an "overview/set-up" meeting where general concepts and general timeframes are discussed, this will be a big help and prevent the "Oops! I forgot I was supposed to...." from being said by any of your group members.
AGREE WITH A SINGLE WAY TO MANAGE GROUP FILES AND STICK TO IT - This is so important because there is nothing more time consuming than code integration. However, this process can be made even longer when you have to rewrite portions of code because something was overwritten or code was written based off of old versions of methods/classes, or it can be longer simply because you are having problems sending/receiving new portions of code. We discuss down further how our group dealt with managing files and the problems your team would want to avoid.
FACTOR IN SPRING BREAK!!! - We can't stress this enough because spring break messed us big time. We thought that if we coded non-stop in the second week of the milestone that we could make up lost time, but that was far from the case. We are not suggesting what method would be best in handling the break and your assignment, but we are simply saying PLAN SOMETHING. If you don not, we can assure you that the week following spring break will be the longest of your life, and to top it off, you probably will still not finish. Dont say that you were not warned!!!

How to Create an "A" Design

Designing is the most difficult, yet most integral part of the entire project. Make sure that you listen to the warnings about "hacking" code and ignoring design because code only counts for 50% of everything that is turned in. Also, it will make the coding ALOT easier if you do the design first and use it as a blueprint. What may seem a waste of time initially, will prove to be the biggest time-saver in the world! It is best to start with CRC cards, just as the book suggests. Doing so will give you a good start as to what classes are needed for the system, what each classes responsibilities will be, and what other classes they will interact with. Then, use your CRC cards as basis for the UML. However, DO NOT be bound to your CRC cards when it is obvious that a change is needed that will have to be reflected back in the CRC cards. It is almost guarenteed that your team will overlook some interaction or responsibilities initially, so simply incorporate this into the UML and then go back and add it to the CRC cards. Just try not to make a habit of this process. And finally, one of the most confusing parts of the design process is dealing with the aggregation of the UML. Although it would still be good to read about the different types of aggregation and perhaps talk to a T.A. for further understanding, here 3 rules of thumb:

Some "A" Tips to Prevent Problems

Use change sets to manage files - Change sets are the way that we chose to manage files and we believe it is the best route to go. But before you can use change sets, you must know what they are, how to file them out, and how to browse through the methods in them in order to take the ones that you want and not have any of your code overwritten. For starters, check out pages 122-125 in the Squeak book. Then, simply try the steps out for yourself and get familiar with the process. The thing to remember is to fileOut a new change set each time and to fileIN your change sets into new images. This way, each change set will only have the most recent changes since the last time and none of the old code will get overwritten when filed in.

Code Reuse/Tools - The ability to have code and special tools available and to be able to use them is one of the biggest advantages of this course, and it would be dumb to not use this to the fullest. However, when talking to some other groups about certain aspects of the project, it seems that they became so infatuated with reusing code or using Squeak tools that they oftentimes overlooked the simpler way of creation of their own. For example, many people used T-Gen and other special tools to parse a website to get info that was needed for stocks. While this worked, it not only took time to learn about the tools conceptually and how to implement them, but also the code itself was not always short. But our group simply grabbed the html text from the site as a string and parsed it with the built-in Squeak String (Collection) methods. This was very easy since there were key tags to distingquish the information that we needed on the page. All total, the code was 6 lines long. This proves that sometimes you can outsmart yourself with reusing code or special tools, instead of other good programming techniques (using relative methods that do everything for you).

Testing - Testing is nothing to be taken for granted. Because it is not part of the "system" and is oftentimes the least amount of credit, testing is put off until the end. Our group had to learn it the hard way the first couple of weeks that you cannot wait until after all the code is done to begin on testing your code. If you test your code while you are coding, not only will it help to make sure that individual portions of the milestone work before integration, but you will also find yourself with that credit at the end. If you wait, many times you will not receive credit because the code is too out of hand to test it adequately, and you probably rather code up until the last minute then work on "simple" tests. We never did get the testing thing down, but that is why we are encouraging you to not make our mistake.

Links to Grade "A" Milestones

A-Team's Milestone4
A-Team's Milestone7

Links to this Page