Information and Computer Science 127:
Advanced Project in Software Engineering

Winter Quarter, 2000
Lecture: TTh 2:00 - 3:20
Location: PSCB 120
(Need directions to campus? See the maps directory.
Course code: 36158

Lab Session: MW 3:30 - 4:50
Location: ET202 (not really!)

Instructor | Overview and FAQ | Textbooks | Teams | Assignments | Keeping in Touch | Computing | Academic Dishonesty | Schedule
(Last modified Tuesday, January 4, 2000 14:14)

What's New

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

Course Staff


Overview, Prerequisites, and Frequently Asked Questions

UCI Catalog Description:

Students work in teams to specify, design, construct, test, and document a complete software system in a specialized application domain using application/domain-specific techniques. Each offering's topic is announced the preceding spring.

This course will emphasize techniques and notations essential to creating software systems for which there was not adequate time or opportunity in ICS 125 or 126A. A variety of advanced techniques are discussed, depending on the particular applications targeted.

All students are expected to attend all lecture 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.


ICS 125 or 126A; Mathematics 2A-B-C.

Is the Lab Section required?

Yes! The discussion section is essential: You will need to meet with your teammates REGULARLY. EVERYONE needs to be in attendance at team meetings. The discussion section time period is the guaranteed time period for you team to meet.

What will the projects be?

We'll decide this the first week of classes. Some candidates:

What's the Drop/Add policy?

Same as ICS 125, and for the same reasons: Since ICS 127 has a strong team project orientation, it is essential that the drop/add process be terminated early. Therefore NO drops or adds will be permitted after the end of the SECOND week of class.

Lecture Topics

Topics will depend upon the interests of the students and the projects chosen. The following list is representative of the topics that might be discussed in class.

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. Similarly if most projects will be using some particular kind of infrastructure, such as CORBA or ActiveX, then there will be lectures on that.


None required.

Assignments and Assessment

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.


The project nominally consists of five major assignments. Their relative weighting (as a percentage of your final grade) of each deliverable is indicated in the table below along with the 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 Weight  Description Due Date
Individual Web Page . . 14 January
    Teams Designated
. . 18 January
    Projects Selected/Assigned
. . 20 January
Team Web Page . . 21 January
Prospectus and Plan 
Prospectus  25 January
    Prospectus Reviews
. week 3 25 January
Requirements Specification
Requirements  1 February
    Requirements Reviews
. week 4 1 February
Architecture/Module Specifications 
Architecture/Design  15 February
    Design Reviews
. week 6 15 February
Implementation 29 February
    Code Reviews
. week 8 29 February
Testing/Test Documentation
Integration/Testing 14 March
. week 10 16 March

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.

Deliverable Due Dates

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 instructor or placed in the instructors's mailbox before that time.

Deliverable Reviews

Each deliverable will be reviewed in class. Each team will be given 15-20 minutes to present their project. You will be given guidance in class on how to conduct these presentations.

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

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.

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.

Cover "page".
Every deliverable shall have identifying information giving
Project title
Development phase and deliverable
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
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''.
Every deliverable shall be accompanied by minutes of team meetings held during the associated period of time.
Performance Appraisals.
Every deliverable shall be accompanied by performance appraisals. Performance appraisals shall NOT be maintained as part of the project's web page. A form is available at . A .ps file is also available. I know that form is for ICS 125, but it will work here too.
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, 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

Throughout this course, just as in ICS 125, you will keep 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 instructor. A sheet showing what should be on the log is available at: .

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.

Team Composition, Activities, and Peer Apportionment of Credit

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.

You are strongly advised to consult weekly with the instructor/TA about your progress, problems, questions, etc.

Keeping in Touch

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

Teams and 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. agenda for the meeting
  2. team members present and reason for any member's absence
  3. major design decisions discussed
  4. task assignments made
  5. future meetings scheduled

As noted earlier, teams will use (at least) the discussion sections for team meetings.
Team Designator Home page Customer Contact Office


To facilitate sharing of files among team members, each team will have an account on a Unix (Sun Solaris 2) machine, where the team web site and project documents must be maintained.

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.

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 I CS's Computing Support Policies, including ICS's Ethical Use of Computing Policy, as well as UCI's Computer Use Policy.

Department of Information and Computer Science,
University of California, Irvine CA 92697-3425