Information and Computer Science 125:
Project in Software System Design

Fall Quarter, 2004
Lecture: TTh 2:00 - 3:20
Location: CS 174
Course code: 36340

Discussion Section (REQUIRED): MWF: 4:00 - 4:50
Location: ET 202
Course code: 36341



Instructor | Overview and FAQ | Textbooks | Teams | Assignments | Costs and Benefits | TA | Keeping in Touch | Computing | Disabilities | Academic Dishonesty
(Last modified September 30, 2004 )

What's New

Watch this spot for new information regarding ICS 125. It may link to other web pages or to updates to this page.

Course Staff

Instructor

Teaching Assistants


Overview, Prerequisites, and Frequently Asked Questions

UCI Catalog Description:

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.

Attendance at all lectures is mandatory. 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.

Prerequisites:

ICS 51 with a grade of C or better; ICS 121 and 141; Mathematics 2A-B and 67.

Editorial note: What 2A-B and 67 have to do with this class is beyond me!

Is the Discussion Section required?

Yes! The discussion section is essential for two reasons:

  1. You will need to meet with your teammates REGULARLY. The best correlation with failure that I've seen in this class over the past decade has been teams which were unable or unwilling to establish a regular meeting schedule and to keep to it. In other words, EVERYONE needs to be in attendance at team meetings. The discussion section time period is the guaranteed time period for your team to meet.
  2. Since this is a large class and each team will be making presentations during the quarter, we'll have to use some of the discussion sections for those presentations.

What will the projects be?

Candidate projects can come from many places: in prior years 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 variety of projects for the class. 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. Here are this quarter's opportunities.

How will teams be composed?

Each team will have 4 or 5 people. I will attempt to balance a team's aggregate expertise with the needs of a particular project. I will also attempt to accommodate some personal preferences for teammates. The course survey form, which you will turn in on the first day of class, is a key instrument in assigning the teams. In the end however, I make all the assignments, both of team composition and of project.

What's the Drop/Add policy?

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 FIRSTweek of class.


Lecture Topics

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 may be given on:

Specific choice of lecture topics will depend somewhat on the projects chosen by the teams. If several of the projects, for example, are concerned with Internet applications, then lectures on protocols and Web technologies will be included.

Textbooks

Remember reading The Mythical Man-Month? If you do, you can expect to profit from that experience in this class. If you don't, you need to read it, cover to cover BEFORE the class begins. Don't worry, it is a quick and fun read.. Depending on the projects chosen additional readings from various sources may be required.


Assignments and Assessment

The project is the focus of this course and will be assessed accordingly. It will account for approximately 80% of your grade; this is broken down between deliverables, a team Web page, and presentations. The approximately remaining 20% will be divided among individual course logs, teamwork, individual leadership demonstrated, and the final. These are guidelines intended to help students plan their work in this course. However, the instructor does reserve the
right to make changes in these evaluation criteria.A critcal aspect of success, however, and thus of assessment, is an effectively functioning team. Just because a team's code "works" at the end of the quarter does not mean that they have earned an A. If the team did a poor job on the requirements and design, for instance, their grade would be lower, despite "working" code. Put another way, if your team has to pull an all-nighter to get a working system, in all likelihood you will not receive the grade you want.

Deliverables

The ICS 125 project nominally consists of five major assignments. The relative weighting of each deliverable, intended to provide you with some guidance as to how much effort should be devoted to these tasks, and how much importance I ascribe to them, is indicated in the table below along with the due date, or approximate due date. The on-line versions of the assignments may still be under construction (watch the "what's new" section to see when they are available).
 
 
Deliverable/Schedule Item Weight  Description NOTE: the URLs below are currently to the assignments from PREVIOUS quarters and are hence subject to revision. Due Date (subject to change)
Individual Web Page
. For an example see http://www.ics.uci.edu/~mdiallo/ or Scott Hendrickson October 1st
    Teams Designated
. . September 30th
    Projects Selected/Assigned
. . September 30th (tentative)
Team Web Page
. For an example October 7th
Prospectus and Plan 
10 
Prospectus  October 8th
    Prospectus Reviews
. week 3  
Requirements Specification
15 
Requirements October 19
    Requirements Reviews
. week 4  
Architecture/Module Specifications 
20 
Architecture/Design November 2
    Design Reviews
. Starting on 11/3  
Implementation 
20 
Implementation/1st demonstration November 22
    Code Reviews/Demos
. week 9  
Testing/Test Documentation
15 
Implementation/2nd demonstration/Quality Assurance Report December 2
    Demonstrations
. week 10 + finals week (TBD)  

Variations on this schedule may be made to accommodate the particular needs of a given project or a given team. Also, note that a team's grade for a phase is a function not only of the document/specification developed but also of any associated test plan and any reviews conducted in class, with the instructor, or with the customer.

Have questions about your intellectual property rights (IPR)? Take a look at the UC's view of the subject.

Deliverable Due Dates

Specific due dates/times will be indicated for each assignment. 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 :-)

Deliverable Reviews

Each deliverable will be reviewed, some reviews will be conducted before the whole class.

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 formal, 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).

Document Requirements

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, or alternatively, in a subversion repository (details to be announced).

All deliverable documents, with the exception of performance appraisals as discussed below, 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.

Cover "page".
Every deliverable shall have identifying information giving:
Project title
Development phase and deliverable
Date
Team name/number
Team members
Phase manager
Phase clerical person
Files and locations (href's)

Table of Contents.
Every deliverable shall include a table of contents
Specification.
The system specification (requirements, design, module specs, code) for each deliverable shall correspond in form and content to the outline provided for that phase. Sections that are not necessary for this application shall be marked ``N/A''.
Agendas and Minutes.
Every deliverable shall be accompanied by agendas for and minutes of team meetings held during the associated period of time. In contrast to previous years much more "grade weight" will be assigned to this part of your deliverables. Details on this will be given in class.
Performance Appraisals.
Every deliverable shall be accompanied by performance appraisals. Performance appraisals shall NOT be maintained as part of the project's web page.
Project WebPage.
The project deliverables, except for the performance appraisals, shall be maintained in a project homepage.

``Fixed up'' Deliverables

For all deliverables, except for the last and except for the "Agendas and Minutes" section, 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.

Course Log

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 submit the previous week's log to the TA. A sheet showing what should be on the log is available.

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 submit 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.

Summary of what you turn in, and when:

  1. Weekly, by individual, using a dropbox: course log for preceding week.
  2. Per deliverable, by team, on website: deliverable documents.
  3. Per deliverable, by team, on paper, performance appraisals. Exception: not required for the Prospectus.
  4. End of quarter, by individual, on paper: collection of the course logs for the quarter.
  5. End of quarter, by individual, on paper, "peer apportionment of credit"

Team Composition, Activities, and Peer Apportionment of Credit

The danger most students perceive in working on projects with other students is 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. One thing we'll discuss in the class is how to fix dysfunctional teams. Nonetheless, 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, excluding yourself, 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.

Team Organization

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

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

  1. Date, time began, time ended
  2. agenda for the meeting
  3. team members present and reason for any member's absence
  4. major design decisions discussed
  5. task assignments made (i.e. action items)
  6. open issues
  7. questions to be asked and plan for getting them answered
  8. future meetings scheduled
  9. topics for next meeting.

Cost and Benefits

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.


Keeping in Touch

Check the course syllabus page regularly. Announcements concerning assignments, changes to the lecture schedule, and so on will be made there.

An important note about email:

Because of, at least, spam, I will not respond to email that originates from any other domain than uci.edu. Thus if you send me email you must send it from your UCI account. If you send me email from any other domain, especially AOL, hotmail, or yahoo, it will automatically get routed to my spam folder, where it will be duly ignored.


Teams and Meetings

As noted earlier, teams will use (at least) the discussion sections for team meetings.
ICS 125 FQ 2004 Teams and TA Assignments
Hazel Asuncion Ben Pillet
Working Spheres Creating and Updating Palantir Views
Integration of xlinkit with ArchStudio 3 Robustifying Palantir
unexceptional.net: PHASE II GXL Validator Plug-in
File-sharing - moving towards WYSIWYG (2 teams) Blah Blah Blah (3 teams)
New Computer Based Choral Musical Score Display (2 teams) Java-based Genome Browser (2 teams)
New True 3-D Digital Display System  
   


Computing

To facilitate sharing of files among team members, each team will have an account where the team web site and project documents must be maintained.

The primary computing facilities will be the ICS Labs. Also available is the ICS 125 team project room, CS 193.  The hardware environment and software environment is posted on the lab's web site as well as the lab hours.

Policies governing the use of the ICS 125 lab in CS 193 are available at http://www.ics.uci.edu/~lab/policies/index.html You will also find there a form you can fill out to obtain an access code that will give you admission to the room 24 hours a day. We'll talk about the potential use of this room in class.

Choice of computing platform for implementation will depend on the projects chosen. Where possible and reasonable, Java will be the implementation language used.


Disabilities

Any student who feels he or she may need an accommodation based on the impact of a disability should contact me privately to discuss his or her specific needs. Also contact the Disability Services Center at (949) 824-7494 as soon as possible to better ensure that such accommodations are implementationed in a timely fashion


Policies (Academic Honesty and Computing Use)

Cheating in ICS 125 will be dealt with in accordance with ICS cheating policy, which is in keeping with the UCI academic [dis]honesty policy.  Please familiarize yourself with these documents, as you are held accountable to them.

You are also bound by all policies posted at ICS's Computing Support Policies, including ICS's Ethical Use of Computing Policy, as well as UCI's Computer Use Policy.


Donald Bren School of Information and Computer Sciences,
University of California, Irvine CA 92697-3425