198:431 Software Engineering
Fall 2006
Prof Barbara G. Ryder
DCS-ALUMS Project
The objective of this project is to design and build a secure system that will enable the department to keep track of students after their graduation from Rutgers with an undergraduate or graduate degree (i.e., as DCS-grads). Access to the system will be web-based, with privacy of the information protected from misuse.
The system will offer different sorts of functionality to different users. For example, for students the system will offer a persistent repository for personal contact information and a means of networking with fellow graduates. Opportunities to visit campus after graduation to talk to students, visit a DCS Open House, give a presentation, all will obtain potential volunteers from the graduate pool maintained by this system. The system will offer networking opportunites through threaded discussion group(s), restricted to usage by graduates.
For example for staff, the system will be used to generate reports corresponding to graduates with certain shared characteristics. The department may want to report all graduates during a particular year who did honors in CS, or list all PhD students in a particular subarea over a 10 year period.
Now let's consider the project from a developer's point of view. Clearly this system will contain private information, so that there is a need for authentication control of users. We intend to be able to query the data using queries that handle state information (as well as stateless ones). For example, a query might have to know whether or not a graduate has already visited campus during the past year, before selecting him or her to receive an invitation. The system will need to notify graduates of events through email. There may be a need not only to introduce new data to the database but also to decide when data is no longer to be kept. Some users may need on-line help in order to use the system, either correctly, or when they make a mistake. A user manpage for the system will help users with the most common tasks. Teams will need to make choices about whether/how to detect and handle problems in usage. Teams should feel free to add other sorts of extended functionality to their projects. We do not expect every team's project to offer the same functionality, but we will define a kernal of functionality that all projects must provide; this will occur in time for the testing of each team's kernal project by one of the other teams.
Given the size and scope of the project, it is important that each team spend time brainstorming about how their project will behave and how it will appear to a user. During the design phase, you need to consider how the framework you devise will support the rest of the project. For example, if you think of features you would like to be able to incorporate, you do not need to implement them right away, but your design should allow the initial project implementation to be extensible to allow such added requirements.
The entire code base will need to be documented well enough by Javadocs so that other team members (and graders) can understand each other's code. For example, each Java method should include a description of its functionality and its parameters. Each class should have a few sentences describing its role.
We will be using the Cereal lab (Hill 252) as a computing resource and/or teams can choose to develop on their own laptops with careful co-ordination using CVS in Eclipse. The cereal labs will be the location of all project demos, whether or not personal laptops are used. We will be providing an initial set of data for testing the projects; teams can add to this dataset as needed.
We will be arranging several specific interview times during the third week of classes for teams to talk to at least 2 prospective users of DCS-ALUMS. These will include faculty and staff members of DCS.
Students in the class should propose teams of 4-5 students by the end of the second week of the semester (Sept 15th) by email to the instructor. It is very desirable that each team include the following: someone who has used the Eclipse environment before to code in Java, someone who has programming SQL queries, and someone who has programmed in the Java Swing library. These goals may not be realizable, but we will try to get a division of expertise among the teams. This does not mean that the SQL expert will necessarily code the database interactions, however.
Work on the project will progress through the semester in phases with FIRM DEADLINES (see below). It is essential that each team have a working project to demo at the end of the course, even if it is a project that implements a reduced set of their original requirements. Members of a team will not pass the course unless they have a project that can be demo-ed at the end of term. (Yes, we are simulating the 'real world').
Each deliverable will involve a written document produced in PDF and we will provide a PDF translator, if needed (see below). Each team member must perform a variety of jobs during the semester; each person will (i) act as writer or editor for a document, (ii) write some of the code, (iii) be responsible for part of the design, and (iv)participate in all demos of the project. The documents will make clear, in writing, who took primary responsibility for each piece of the deliverable for that phase. The specific model of team organization to be used will be chosen by each team (We will talk more about possible team models in class); however, it is essential that all team members contribute to all deliverables in some way and that each one's contribution is acknowledged explicitly. At the end of the term, each team member will have to privately assess (for the teaching staff) the contributions of all the other members of his/her team to the project as well as his own contributions.
Each team will be required to test a stable, partial implementation produced by another team, frozen 10 days before the final demos. This testing will be documented and turned in as part of the final project deliverable. The GUI prototype demos and final project demos will be conducted as a class, so that other teams will observe the project demos of their classmates. Of course, the teaching staff will be the focus audience for these demos, but other teams may be asked to comment as observers.
Advice for dealing with new software tools introduced in lecture or recitation: spend some time learning the tool before trying to apply it to you project. Download the tool yourself, find relevant tutorials through Google and work through them. For the majority of the tools we will recommend, there are many good tutorials on the web that can make you a familiar user with a little time investment.
Note that the due dates are generally on Wednesdays to allow teams to retrieve graded documents on the following Monday (hopefully).
Note, the dates on these milestones are firm, so the obvious question is What if we miss the date? Missing a date means the team will receive a zero for that deliverable of the project. Also, the entire team will have to meet with the instructor to explain what happened and to discuss how to avoid a recurrence.
Another question is "What if our final working prototype does not have the full functionality we outlined in our requirements and design?" This may happen, depending on how ambitious your requirements are. The important thing is that you document in writing what parts of the requirements have been met and which parts have not been met. The final demo will be judged in the context of those requirements you claim to have met; however, your project grade will be influenced by the amount and kinds of functionality your project provides.
This course involves a lot of writing and speaking about your project, in an attempt to simulate the real world, where developers have to have good communication skills. You will not be judged directly on your writing style, however, it is to your advantage to write as clearly and tersely as possible, and we will comment on your style as well as on the content of your documents. It's not about having long documents, it's about having quality documents!
We suggest that each document has 1-2 writers and a different person as editor. The editor ties the entire document together and provides a different perspective from the writers, who often are too close to the document to see its flaws. Make sure that you understand what the document is supposed to contain. Read the project assignments carefully and ask the TA or instructor if there is something you don't understand.
After receiving feedback on a deliverable, the team may decide to change their proposed approach. For example, a part of a high-level design may be re-worked in response to feedback. All project documentation should be kept 'in synch' with the code throughout the semester. This is especially important for comments in the code! The final documentation to be turned in at the end of the semester, will include updated versions of all previous documents, that clearly reflect any changes the team has done to requirements, design, implementation and/or test plan.
We all have our own favorite document preparation system. It is easier for us if you turn in your documents electronically in PDF format. Here is a PDF writer you can use from Windows. Macs automatically convert postscript to PDF by clicking on the file icon. There are UNIX utilities that convert postscript to PDF for Linux users; make sure you include all fonts in the created PDF. In this standardized output format, it should be easier for us to comment directly on your electronic versions.
We will be using the departmental on-line handin program for your deliverables. More details will be given in recitation.
There are 4 points of standardization we are introducing to the term project, each listed below. These were chosen as the best set of platforms for the entire class learning experience in CS431. Scott's recitation notes from 10/16/2006 can serve as a model as to how the inter-tier communication will be handled.
Last updated by Barbara Ryder at 11:52pm, December 5, 2006.