Since your final project is likely to be large, and there is a 10MB limit on our dropbox, you might consider burning a CD and slipping it under my door.

As the title says, the final will be in 1D11 and 1D15 at 9am on Monday. Please be there on time. It is a computer test and is timed to last 2 hours. Here is a sample test.

Your final writeup will consist of (I would prefer if you could write your documents in HTML) :

1. Your well-commented code.
2. A user's manual detailing, to a novice, how to install and use your program.
3. A technical document:
   1. with an explaination of the overall design of your program, including UML diagrams, protocol definitions, deployment diagrams, etc.
   2. the design decisions and tradeoff you had to make and why you made them,
   3. a list of all the bugs in your program,
   4. a list of all the features that you would implement if you had the time
   5. list of things you would have done differently,
   6. a list of what work was done by each member of the team, assign to each member a percentage from the total.

These are due on May 9 at noon. Please .zip everything into one file and either email it to me or (preferably) use the department's dropbox. Note that itt is hard to email large files.

The testsing assignments are as follows:

This group will test the program of	this group
Alpha	Beta
Beta	Delta
Delta	Gamma
Gamma	Epsilon
Epsilon	Kappa
Kappa	Zeta
Zeta	Alpha

Your test results will be handed in with your final project writeup. Remember, noon today in 1D15!

Looking for a job? Check out our new CSE Careers website. I am still working out the kinks so let me know what you think is wrong with it. I have started to post all the job wanted ads that people send my way.

In order to give you a little bit of extra time as you death march towards demo day, I am making our meetings next week optional. If you are not going to drop by I would appreciate an email telling me so. Work hard!

The final project presentations/demos are scheduled for Tuesday May 1 from noon to whenever we are done in 1D15. Each group gets 30 minutes so with 6 groups it should be about 3 hours. Everyone should attend. The presentation should consist of a demo as well as some slides that cover

1. Technologies used.
2. Overall system architecture.
3. Features of program which might not clear from demo, for example, network connectivity.
4. Comments on what worked, what didn't, and what you would do different next time.

If you are thinking of graduate school, go visit our office of fellowships to learn how to apply to various fellowships. There are plenty and they offer real money. The NSF fellowship, for example, will pay all of your tuition at any school you want and give you a salary of $25K/year, just for going to school. Every year several of our students get these, as well as other fellowships. This is your year.

Yes, there is a final! You will remember that 10% of your grade comes from the final which is a Major Field Test in Computer Science from the folks at ETS, the same people who brought you the SAT and GRE. The test will be during finals' week, Monday 7 May at 9am until noon in Labs 1D11 and 1D15. If you want to prepare a bit here is a sample test.

The following video is a presentation of the gapminder program, not available online. It is a great example of how a relatively simple program can change our perception of the world, and thus change the world itself. Plus, cool graphics. Watch it!

If you haven't already, that is. The next big deliverable will be a demo and code review on the week of April 2. Do not wait until the week before and expect to get it all done in one week! We will continue our weekly meetings. Each meeting from now on will consist of a progress report. Please bring printouts of new code you wrote that week.

AJ Alon just sent me the following link to a bunch of sample design documents for game. Those of you implementing games know that we have talked about how games require a different approach to their design. These sample documents should give you an idea of how others are doing it.

For next week you will turn in at least 20 tests. These should be of the form: Do these series of steps and then you should see this. Of course, 20 tests will not provide comprehensive coverage of your application but you should choose them to be representative of the various features of your program. These tests will be used by the group testing your program.

The time has come to put to use all the knowledge you have acquired about UML, object-oriented design, and plain old programming. For the week of Feb. 19 each group needs to submit a detailed design document. That is, all the classes you will be using, major methods these will implement, database table schemas (if you are using a database), and a deep understanding of how all of these are to fit together. Also, include a division of labor: who will implement what.

You need to carefully think about how your program will handle each use case. Run the program in your head, write down the major methods you will need to invoke.

In the week of February 12 each group will submit their formal specifications document. The textbook does not have a good example of a specifications document but you can find one here (Scroll down to get to the PDF file. You can ignore the coding conventions section).

Assume that the program will be implemented by someone else by following the specification document you will write. Thus you must be precise about what you want. You should use your use-case stories as a foundation for this document and your mockups should be incorporated into the document.

If you don't like to keep checking this website for news and refuse to use an RSS aggregator there is still a way that you can easily stay informed. You can use that great 20th century technology known as email. Just go to www.rssfwd.com and type in http://jmvidal.cse.sc.edu/csce492/news.rss and then give them your email address. They will forward you any new news posted here. Also, remember that your cellphone almost certainly has an email-to-text gateway, so you can use your cellphone's email to get notified whenever there is a new posting and thereby never escape the fun that is 492.

For next week (Feb. 5) each team will bring mockups of their user interface. These can be hand-drawn and informal. The goal is to get a clearer picture of what the user will see and thus determine exacactly what functionality you will need to implement. Play close attentation to that buttons, menu items, text boxes, etc. the user sees on each screen and what function these will perform.

For next week's meeting (our first) each team will need to bring their set of use case stories for their project. Section 3.10.3 defines a use case and later sections give specific examples. The goal of these use cases is to think in terms of the user: what will the user see? what does the user want to do? how does your program fulfill those wishes? You need at least 10, but 20 would be better, use cases. Each should appear on a separate sheet of paper and follow the formatting used in Deliverable 3.3 (page 90).

The Science, Engineering, and Technology career fair will be held Thursday February 15, 2007 at 11am-3pm in the Columbia Convention Center. Here is a list of companies that will be there and the degrees they will be looking for. You can also log in to the USC Careerlink to get a complete list of all posted job openings (including companies that will not be at SET.

This is your chance to impress them with your ambitious 492 project plans! Also, when you do get an offer(s), please let me know. The department is trying to keep better track of where our students are going.

I have just finished reading Dreaming in Code by Scott Rosenberg. It tells the story of the ongoing development of Chandler an "Outlook-killer" being developed by Mitch Kapor (Lotus 123) and a band of very experienced programmers. It is interesting to see how a project with no money problems (Kapor pays for everything), not much deadline pressure (being open source, they don't expect to make much money), and a slew of very talented programmers still has significant problems. The book tries to explain why software is hard to make, even under the best conditions.

The author also intersperses the book with a history of the various software engineering methodologies that have been proposed over the years, from the waterfall model to agile methods, scrum, extreme programming, CMM, PSP, etc. He explains how these have all failed to meet their promise. Still, different people have different opinions on which is the right methodology and he gives everyone a chance to voice their views. In the end, however, he seems to conclude, as many of us have, that there is no magic bullet to software development. That is, software development will never be like, say, civil engineering because most of the bridges we build are identical to ones we have built before while in the software world there is very little incentive to write software that has already been written. In a free market, the only software really worth writing is the one that does something that has not been done before, or does it better, or cheaper. Thus, we are always pushing the boundaries of what is possible and exploring an unknown territory.

There are some parts you might find boring, as when he explains the difference between an interpreted and a compiled program or when he tries to explain object-oriented programming to a lay audience. Still, the book provides an entertaining history of software engineering which will at least acquaint you with all the acronyms, biases, and discussions that are familiar to more experienced programmers. It is a fun read which could serve as a jumping-off point to more serious textbooks. I also note that Joel is excited about it.

Here is Joel's book review.

The book The Five Dysfunctions of a Team is a recommended reading for this course. The book is a fictional story of a dysfunctional executive team and how a new CEO comes in and makes everyone realize their own personal dysfunctions. It is not as Dr. Philish as I just made it sound. Chances are that right now you will think is is all touchy-feely useless stuff but that by the end of the semester you will be able to identify with some of the scenarios. It will still be touchy-feely stuff, but you will realize that your inability to resolve those touchy-feely issues led you to a lower quality final project.

If you prefer watching TV, check out this video of a talk by Bill Lattin, ex VP of Intel in which he rehashes the book using anecdotes from his own career.

Jennifer Guild, a software engineer working at SPAWAR, and her team have sent us the following suggestions for 492 project that they are interesting in seeing.

1. Design (with emphasis on security) and code an audit log analysis and reduction tool. The tool should be able to search on a specific date, user, event/action, or computer ID.
2. Design a software application that controls multiple communication devices (transceivers, switches, and routers). Control includes configuration as well as SNMP puts and gets.
3. Design and code an application which parses RS-232, RS-422, RS-530, and SNMP v1.0 data into a single object.

If you are interested I can provide you with help and further details in any of these, as well as put you in contact with Guild.

I think we are up an running for the semester. Notice that I am using google calendar for our class meetings and individual group meetings. That is, individual group meetings with me (typically, weekly) will appear on the calendar once we set them up.