Informatics 117: Project in Software System Design

Winter Quarter 2013

Course Code 37080

(Discussion: 37081)

Last update: February 28, 2013



Richard N. Taylor


(taylor [at] ics [dot] uci [dot] edu)
To ensure a response to your email, please include "Informatics 117" in the subject line and send your email from a UCI account.

Office hours:

After class, or by email appointment


Tuesday and Thursday 12:30-1:50 p.m., DBH 1200

Discussion: Monday and Wednesday: 4:00-5:20 p.m. MSTB 122 Discussion website
TA: Chris Adriano. adrianoc [at] ics [and you know the rest]
Web site:

What's New?

Description - Textbook and Readings - Schedule - Grading - Policies


2012-13 Catalogue description:

Specification, design, construction, testing, and documentation of a complete software system. Special emphasis on the need for and use of teamwork, careful planning, and other techniques for working with large systems. Prerequisites: Informatics 43 or ICS 52 with a grade of a C or better; ICS 33/CSE43 or ICS 22/CSE22 or Informatics 42 with a grade of C or better, and upper-division standing.


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

Lecture Topics

Informatics 117 is on a tight time schedule, thus there is not much time for review. You are expected to recall the material covered in the prerequisite courses. Short supplementary lectures may be given on:

Specific choice of lecture topics will depend somewhat on the projects.


The schedule is subject to change

Week Date Topic Project Items








8 Tu

Introduction & Project briefs (2)

10 Th Project briefs (5) Course survey form/project bids DUE
2 15 Tu Team and project assignments made. Initial discussion of teamwork Teams formed; projects assigned. Prospectus assigned
75 Th Getting Organized; Managing Time; Giving Briefs; Teamwork/Project management
3 22 Tu Prospectus Presentations Requirements assigned
24 Th  
4 29 Tu Requirements Reviews Design assignment available
31 Th  









5 Tu Architecture/design  
7 Th Working in teams (no formal class)  
6 12 Tu Design reviews  
14 Th

Design due (15th)

Implementation assigned

Part 1 and Part 2
7 19 Tu

Working in teams (no formal class)

21 Th Giving demonstrations and discussion of implementation issues  
8 26 Tu Boothmanship  
28  Th Progress review & informal presentations  






5 Tu Working in teams (no formal class)  
7 Th Implementation due: Part 1 (8th)
10 12 Tu Implementation reviews (as described in "Part 1")  
14 Th Implementation due: Part 2 (15th)
Exam Week  Demonstrations scheduled on an individual team basis  

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 reserves 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 much 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 -- even if the system "works.".


The 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). Variations on this schedule and on the assignments themselves 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, with the TA, or with the customer.
Deliverable/Schedule Item Weight (% of final grade) Description Due Date (subject to change)
Team Web Page
.   January 18th
Prospectus and Plan 
Prospectus  January 25th
    Prospectus Reviews
. week 3  
Requirements Specification
Requirements February 1st
    Requirements Reviews
. week 4  
Architecture/Module Specifications 
Architecture/Design February 15th
    Design Reviews
. Week 6  
Implementation, Part 1 March 8th
    Code Reviews/Demos
. week 9  
Testing/Test Documentation
Implementation, Part 2 March 15th
. week 10 + finals week (TBD)  

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

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.

Normally 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).  Depending on the customer's availability, however, this requirement may be waived. 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 become unpleasantly obvious).

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, 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
Team name/number
Team members
Phase manager
Files and locations (href's)

Table of Contents.
Every deliverable shall include a table of contents
The system specification (requirements, architecture, 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 project 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.
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 Website.
The project deliverables, except for the performance appraisals, shall be maintained in a project website.

``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 submit 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. The first log you submit will cover Week Three; it will be submitted at the beginning of Week Four.

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, all performance appraisals. Exception: not required for the Prospectus.
  4. End of quarter, by individual, on paper, "peer apportionment of credit"

Team Composition, Activities, and Peer Apportionment of Credit

How will teams be composed?

Each team will have 3 to 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 and for the particular project assigned. The course survey form, which you will turn in on Thursday of the first week 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. (Hardcopies of the survey will be distributed in class.)

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. Use email. Use Skype, Use IM. You choose the technology; the goal is adequate coordination. 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 guarantees that such meetings are possible for everyone.

Have a contingency plan for submitting a document on time even if the responsible manager becomes unavailable.


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


What's the Drop/Add policy? Since Informatics 117 has a strong team project orientation, it is essential that the drop/add process be terminated early. Therefore NO drops or adds after the end of the second week of class.

Course Evalutions. The online evaluation window for winter quarter will run from TBA through TBA.

Academic Honesty. The UCI academic honesty policy applies. Consequences of cheating in this class: a letter in your UCI file, and the course grade is lowered, most likely to F. Material that is copied from books or Web pages needs to be quoted and the source must be given. If you plagarize, you run the severe risk of failing the class, in a most disgraceful manner.

Disabilities. Any student who feels he or she may need an accommodation based on the impact of a disability, religious observance (or anything else) should contact me privately to discuss his or her specific needs. If appropriate, contact the Disability Services Center as soon as possible.

Use of Social Media during Class Sessions. Sadly, many students have adopted the practice of using instant messaging, Facebook, or other social media technologies inside the classroom. This is, at a minimum, disruptive to other students. The practice is therefore prohibited in 117. I reserve the right to totally forbid use of the Internet and cellular communications —even the use of any laptop— in class if it turns out that students violate the prohibition. "Let's not go there."

(C) University of California, 2013.