Discussion Section (REQUIRED): MWF: 12:00 - 12:50
Location: CS 180
Course code: 36168
Specification, design, construction, testing, and documentation of a complete software system using concepts learned in ICS 52, 121, and 141. Special emphasis on the need for and use of teamwork, careful planning, and other techniques for working with large systems.
This course will emphasize techniques and notations essential to creating software systems based on the principles discussed in ICS 121: well-understood requirements, usability and user interface design, architectural design and module specification, well-planned testing, effective oral and written communication of concepts, proper programming style, group coordination, product documentation and software process.
All students are expected to attend all lecture and discussion sections. In general, there will not be much lecturing in the class. Instead, class time will be highly interactive, and all students are expected to participate. About half of the time will be spent performing reviews of the artifacts developed. These reviews will take up all lecture and discussion periods the week following the due date for each deliverable.
Yes! The discussion section is essential for two reasons:
Candidate projects can come from many places: in AY 98-99 some ICS 125 teams worked on projects that sponsoring local companies suggested. Other teams worked on projects related to on-going research programs in the ICS department. Other projects may come from the students.
Choice of projects is related to many goals.
One key goal is to pick a project of appropriate size. It must be big enough to challenge a team of four students, but not so big as to commandeer everyone's life! As a result we will spend some time at the beginning of the fall attempting to size various projects. These planning estimates will be revisited as the course progresses.
Another goal is to select a different project for each team. Since each team will be making regular project presentations to the rest of the class, diversity of projects will enable students to learn from experiences across a range of project topics.
Still another goal is to work on something fun and interesting! I've had students working on flight simulators, generating HTML pages, linking MPEG movie frames via hypertext to other artifacts, and building graphical program editors. There are many opportunities....
Since ICS 125 has a strong team project orientation, it is essential that the drop/add process be terminated early. Therefore NO drops or adds of ICS 125 will be permitted after the end of the SECOND week of class.
ICS 125 is on a tight time schedule, thus there is not much time for review. You are expected to recall the material covered in ICS 121 and the other prerequisite courses. Short supplementary lectures are anticipated on:
Regardless of the project chosen, all students will be required to read The Mythical Man-Month. Depending on the projects chosen additional readings from various sources may be required.
Note that this book has a lot of white space and blank pages, so it really will not take you long to read these chapters.
All are available from amazon.com.
The project is the focus of this course and will be assessed accordingly. It will account for 80% of your grade; this is broken down between deliverables, a team Web page, and presentations. The remaining 20% will be divided among individual course logs, teamwork, individual leadership demonstrated, and the final.
| Deliverable | Weight | Description | Due Date |
| Individual Web Page | . | . | 04 October |
|
. | . | 05 October |
|
. | . | 07 October |
| Team Web Page | . | . | 11 October |
| Prospectus and Plan |
|
Prospectus | 15 October |
|
. | week 4 | 18-22 October |
| Requirements Specification |
|
Requirements | 22 October |
|
. | week 5 | 25-29 October |
| Architecture/Module Specifications |
|
Architecture/Design | 05 November |
|
. | week 7 | 8-12 November |
| Implementation |
|
Implementation | 19 November |
|
. | week 9 | 22-24 November |
| Testing/Test Documentation |
|
Integration/Testing | 03 December |
|
. | week 10 | 29 November - 03 December |
The deliverables are weighted according to the relative amount of time and effort we expect you will spend on each (and not necessarily on their importance with respect to software development). Variations to this may be made to accommodate the particular needs of a given project or a given team. Also, note that the grade for a deliverable will consist not only of the document/specification, developed during that phase but also the test plan developed along side it as well as the review conducted in class the following week.
Deliverables are due at 12:50 PM on the date indicated in the table above. NO LATE ASSIGNMENTS WILL BE ACCEPTED. This applies to your final system and all intermediate projects. Since you are working in this class as part of team, it is the team's responsibility to ensure that assignments are turned in on time. Normal excuses for late assignments, such as illness, do not apply in a team setting (unless of course everyone on the team is ill :-)
Unless directed otherwise, deliverables must be turned in directly to the TA or placed in the TA's mailbox before that time.
Your customer should be invited to your team's Prospectus and Requirements review as well as your demonstration (and, possibly even your design and code reviews depending on the nature of your customer). The review is your team's chance to inform as well as obtain feedback and ideas from all relevant parties; your document will be reviewed at this time by course staff and clients as well as the rest of the class. This review is a formality, however, and each team should have presented and negotiated both relevant documents to the customer prior to the review (if you haven't, it may be unpleasantly obvious by the interactions at this time).
All the documents associated with the above listed phases are integral parts of systematic software development. Their continued, up-to-date existence is necessary for successful system development. Do not delete documents after they have been turned in. They must reside permanently on your team's website.
All deliverable documents must be prepared on-line and be available as part of your project home page either as either HTML or .pdf files. NO MS Word files. In general, the following should be observed.
For all deliverables, except for the last, you will also have the opportunity to ``fix it'' based on its evaluation. You may hand in an improved version of a deliverable one week after that deliverable has been graded and receive up to 50% of the points deducted on the initial version. The purpose of this exercise is for you to both learn how to use the techniques and so that you do not implement something from a bad design or specification. You should keep the same responsibilities for the improvement phase but assign new responsibilities for the next phase.
During your career you will need to keep track of how you spend your time either for you employer or to improve your own productivity. Throughout this course, you will practice doing this by keeping a course log recording the time you spend on all activities related to this course. At the beginning of each week you must email the previous week's log to the TA. A sheet showing what should be on the log is available at: http://www.ics.uci.edu/~taylor/ics125_fq99/logform.html .
Keep a copy of your logs: you will need them at the end of the quarter for the final review.
Each entry records the date and amount of time spent, type of entry, and text describing the entry. An entry is one of three types:
Most entries will be of the first type, but occasionally you should reflect and think about what is going on. The time entry applies for descriptions of activities and records the amount of time spent in hours, to the nearest quarter hour.
You will be marked down only for failing to email logs each week, giving too little detail, or failing to keep track of time spent.
You are especially encouraged to keep track of the kinds of errors you make and the amount of time they consume. The purpose of recording these errors is so that you develop a better understanding of the kinds of mistakes you typically make. With that understanding you can improve your performance in the future, by paying extra attention to those areas in which you've had problems in the past.
As discussed in class, teams will be assigned on as fair a basis as possible for the project. The danger most students perceive in working on projects with other students is in being saddled with (what they think is) a "non-producer". This is particularly true when you don't get to choose all your teammates (the situation here). Many factors dictate the use of a multi-person project for this course. You will not, after all, be able to choose your workmates in the future. Therefore, to alleviate your concerns and to grade you appropriately, at the end of the term project you will be asked to divide 100 points among the members of your project team, corresponding to how you believe they contributed to the project as a whole (or on a phase-by-phase basis if you wish). In addition, each team member will be appraised for each phase. This ``peer apportionment of credit'' will be used to help determine appropriate individual grades for the project component.
There are several obvious dangers to group work that can be circumvented. Ensure that there is adequate coordination among the team members. Know each other's login names for electronic mail. Know each other's phone numbers. Meet at least twice per week (outside of class lecture) at the same, pre-determined time each week (so as to avoid confusion). The Discussion Section is designed to guarantee that such meetings are possible for everyone. You are strongly urged to use that time slot.
Have a contingency plan for submitting a document on time even if the responsible manager becomes unavailable.
You are strongly advised to consult weekly with the instructor/TA about your progress, problems, questions, etc.
Meetings are an important part of a team project. A successful meeting requires that the meeting have a definite purpose and associated agenda (these are the responsibility of the phase manager) and that all decisions be recorded in minutes (the responsibility of the phase clerical person).
The purpose of minutes is to record decisions made and to be available for updating any team member who misses a meeting. Each deliverable must be accompanied by agendas and minutes for the team meetings held during the associated period of time. I.e., keep the agenda, and the minutes, on-line as part of your project web page. The minutes should outline
This course will demand a lot, but I think that you may well find this to be the most rewarding courses that you will take in your undergraduate career. ICS Alumni have said repeatedly that ICS 125 was the most important class that they took at UCI. The techniques presented in class actually work and will help you in future software development.
At the end of the class I encourge you to make copies of your project website/notebook for each team member. Take them with you when you go to a job interview. Students from past ICS 125 classes have frequently said that it was their project notebook that clinched a job for them. Some interviewers have commented that the quality of the process followed by the ICS 125 teams and the quality of the product exceeds those of the production engineers in their companies.
As noted earlier, teams will use (at least) the discussion sections for team meetings.
Team Designator| Home page | Customer Contact | Office | |
| Compaq | Team Compaq | Roger Olds | CS Trailer Room 1 |
| Posties-1 | Posties-1 | Joe Feise | CS Trailer Room 2 |
| Posties-2 | DAV Posties | Joe Feise | CS Trailer Room 2 |
| PSYO-1 | Wild, Wild Web | Dick Taylor and Tamara Wolfe and Chris Russell | CS Trailer Room 3 |
| PSYO-2 | One In a Million Industries | Dick Taylor and Tamara Wolfe and Chris Russell | CS Trailer Room 3 |
| PSYO-3 | Team Mugen | Dick Taylor and Tamara Wolfe and Chris Russell | CS Trailer Room 5 |
| IMPP-1 | The Zot Project | Rohit Khare | CS Trailer Room 8 |
| IMPP-2 | HKPlayers | Rohit Khare | CS Trailer Room 8 |
| Workflow-1 | Reservation Pro | Peter Kammer | CS Trailer Room 9 |
| Workflow-2 | Workflo2 | Peter Kammer | CS Trailer Room 9 |
The primary computing facilities will be the ICS Labs, which provide Sun Solaris and Windows/NT machines. The hardware environment and software environment is posted on the lab's web site as well as the lab hours and availability for Fall 1999.
The system specification for each deliverable may be done on Suns, Macintoshes, PCs, or any other available platform. Choice of computing platform for implementation will depend on the projects chosen. Where possible and reasonable, Java will be the implementation language used. (Scads of Java information is available on-line, including a tutorial, reference material and many, many packages, such as those available from Gamelan.)
Choice of computing platforms will depend on the projects chosen. Where possible and reasonable Java will be the implementation language used.
You are also bound by all policies posted at I CS's Computing Support Policies, including ICS's Ethical Use of Computing Policy, as well as UCI's Computer Use Policy.