Since we are keeping the same groups as in project 3, you can keep using the same repository.
In this last phase, I am going to make few new hard requirements. I am more concerned about your product having a professional, finished look and feel. I'm grouping the specification under "new features," "design goals," "clarifications," and "advice."
Auto update. Your program should automatically update (when the program starts and whenever the user indicates), fetching information about price, splits, buy-outs, spin-offs, P/E ratios, and dividend distributions. The easiest way to get this information is by "screen-scraping" from webpages. This article can get you started on how this can be done (thanks to Chet for bringing it to my attention). If the network connection is unavailable, your program needs to have stored the information from last time it updated, and it should display an appropriate message to the user.
Capital gain. Capital gain information is necessary for taxes, and specifically one needs to know capital gain for each year. Therefore, at the beginning of each year, the capital gains should reset, and capital gains for previous years should be recorded and retrievable. Furthermore, capital gains (again, for tax purposes) are subdivided into short-term (held for less than one year) and long-term (held for longer than one year). Keep in mind that if one sells stocks from more than one lot, it is possible to have some short-term gain and some long-term gain. When the user creates a new portfolio, he or she should be allowed to enter the capitals gains so far for the current year.
Dividends. Your program should keep track of and display how much income is generated by the portfolio through dividends. This also should reset at the beginning of the year (and keep record of previous years) and allow the entering of dividend income for this year so far when a portfolio is created.
Reports/research. At the user's request, the program should generate a report containing the following information: what percentage of the portfolio (by value) each company makes up; what percentage of the portfolio (by value) is in each sector (you'll have to search online for the sector of each stock); the best and worst performer in terms of profit or loss; the stocks with the highest and lowest price/earnings ratio. A pie chart would be great for the percentage parts, but is not a hard requirement. Also, it is up to you whether or not all these things should be contained in a single report, or whether the user could ask for this information separately.
User interface. The user interface should be scaled back now that we are getting information automatically. The interface should allow users to indicate a purchase, indicate a sale, request a report, view history, or correct an earlier input. You may assume the user uses the program at least once a year and enters any sale or purchase before the end of the year (but not necessarily on the day of).
Store as little information as possible. Don't store what can be computed or looked up online. However, you do need to store enough information from the previous run of the program so that it will still work if no network connection is available.
Have a professional, finished, and polished feel. Your program should look and behave, well, like a finished product. It should be user-friendly, have testing code removed, etc.
Be robust. Your program shouldn't crash or have unexpected behavior, even if the network is down, the file system unavailable, or the user stupid.
I will add clarifications as things come up, and as I grade your phase 2s.
Initial conditions. This is what seems reasonable to me to require your programs to do when a user creates a new portfolio:
You are free to implement more than this, if you can think of a functionality that would be desired and reasonable.
More on user interface.
Here's an sample of what I'm looking for in an UI. You don't need to replicate this exactly, but this should give you some guidance. The main application window would look like
The "Edit" menu would allow the user to change the password, make corrections, and switch between showing lots together or separately. The "Tools" menu would have options for viewing the history or make a report, each of which would appear in a separate window. A history window might look something like
I would recommend that the first thing your group do is have a meeting for planning and reorganization. By now you should have a good feeling for each other's work habits, skills, strengths, and weaknesses. You should try to improve your group's dynamics before setting back to work. Pick an official team leader-- probably someone who has already shown himself to be a leader. Make a schedule and assign tasks. I recommend moving away from programming individually at midnight to doing pair-programming at pre-determined times. Coach anyone who's not pulling his fair share.
For testing purposes, you'll want somehow to simulate time-- pretend that the user is using the program at some earlier date, and then let time jump ahead to see how it deals with changing years, etc.
DUE:Monday, Dec 10.