The goal of this course is to provide students with an industrial-like experience in software development. Students will undergo the vicissitudes of developing a large-scale software system from the point of view of all involved personnel - customer, developer, and manager. This course is a two-quarter project course in which the students specify, design, construct, test, document, and evolve a complete software system using concepts learned in ICS 52, 121, and 141. Special emphasis is placed on the need for and use of teamwork, management, planning, and other tools for developing and maintaining large-scale software systems. Using techniques for formal specification and analysis at multiple levels of abstraction are also emphasized, as well as those for usability evaluation and evolution.
A central focus of this course is the application of the software engineering concepts studied in ICS 121 in a significantly sized software development project worked on in teams. This course will will emphasize well-understood requirements, logical object-oriented design, effective oral and written communication of concepts, and group cooperation.
ICS 125 attempts to address all the issues associated with team-based software development in a ten week period. As a result the class is very intense and very rushed during the last several weeks. Depending on the project chosen there is little time for thoughful analysis of requirements, examination of architectural alternatives, or rigorous testing. And certainly there is no time to "do another lap", evolving the application to meet revised needs or to address shortcomings.
ICS 126 will be similar to ICS 125 in that a project will be developed by teams of students, but there will be opportunity to spend more time on requirements, design, and analysis. Moreover there will be time to go around the track again. This second lap is a critical learning experience: developers will confront the consequences of decisions they made during initial design and implementation.
A grade of IP ("in progress") will be assigned at the end of ICS 126A. Final grades will be assigned only upon completion of ICS 126A-B. Naturally, though, intermediate marks will be assigned so that students will know how they are doing as the class progresses.
Students entering the program in the Fall of 1997 have a three-project course requirement, at least two of which must be in different ICS "areas". Students entering the program before FQ97 have a two-project course requirement; a close reading of upper division requirement "C" in the 1996-97 catalog will reveal that these two project classes must be in different areas.
So, what does this mean for 126A & B?
If you have entered before FQ97 then you cannot use 126A and 126B to satisfy the entire project class requirement. You will still need to take one other project class from outside the software area.
Candidate projects can come from many places: in AY 97-98 some ICS 126 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 126 has a strong team project orientation, it is essential that the drop/add process be terminated early. Therefore NO drops or adds of ICS 126A will be permitted after the end of the second week of class, unless there are truly extenuating circumstances.
Composition of the teams will be re-examined at the beginning of ICS 126B. Similar to 126A, drops from 126B will not be permitted after the end of the second week of Winter Quarter.
Since 126 will not be on the tight time schedule that 125 is there will be time for lectures on material supplementary to that in 121 and the other prerequisite courses. 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.
Each team will have their own office in the ICS trailers in which to conduct meetings and (at their option) do their work.
Team Designator| Meeting Room | Home page | Customer Contact | |
| A ("Argo/C2") | CS Trailer Room 6 | TeamName? | Peyman Oreizy |
| B "Cargo Router" | CS Trailer Room 7 | TeamName? | Kari Nies |
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, team process descriptions and updates, a team Web page, and presentations. The remaining 20% will be divided among individual course logs, teamwork, individual leadership, and the final (if any).
Their relative weighting (as a percentage of your final grade) of each part of the project is as follows for ICS 126A (in the case where there is only a single implementation phase --- if there are two then these will have to be adjusted):
Assignment | Weight | On-line versions
| Prospectus and Plan | 15 | Prospectus
| Requirements | 15 | Requirements
| Architecture/Module Specifications | 25 | Architecture/Design
| Implementation | 25 | Implementation
| |
Deliverables, and weighting for grading purposes, for ICS 126B will be determined later.
The final examination may consist of a maintenance activity in which a minor change will be made to your team project or a small essay.
Deliverables are due at 2:00 PM on the date indicated in the team's plan. 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 :-)
The ICS 126A part of the project nominally consists of four major assignments. They are equally weighted. Variations to this may be made to accommodate the particular needs of a given project.
For all deliverables, except for the last in ICS 126B 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. As discussed above, you should keep the same responsibilities for the improvement phase but assign new responsibilities for the next phase.
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.
All deliverable documents must be prepared on-line and be available as part of your project home page.. In general, the following should be observed.
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 hand in a copy of your log. These logs are confidential and should be handed in independent of your team's deliverable. A log sheet is available at: http://www.ics.uci.edu/~taylor/ics126/logform.html . Keep your log as part of your individual home page, but password protect it.
OPTION:
A better way than to submit the course logs (than each week in class)
is be to have the form online in each of your home pages. Create a new one
each week, and password protect the web pages in the following
way:
--save the forms in a separate directory in your public_html directory
-- You place a file called .htaccess in the directory you want to protect.
It has the following sequence of commands in it:
AuthUserFile
AuthName ByPassword
AuthType Basic
<Limit GET>
require user ics126
</Limit>
This means the user has to log in as ics126 and give the correct password (which you will set) to be able to access the course log form. You set the password in the .htpasswd file, be careful not to store the .htpasswd file in your public_html directory.
To create the .htpasswd file:
run the program htpasswd, to create it say,
htpasswd -c ~your_name/.htpasswd username
and to add a password it is
htpasswd ~your_name/.htpasswd anotherusername
assuming of course that the file you pointed to from .htaccess was
~your_name/.htpasswd
Remember to have both .htpasswd and .htaccess as world readable. This should do the trick, and you will be able to restrict access to your course log file. send in to taylor@ics and jaya@ics the password to give access to your course log form. Keep the user name as "ics126". If you have any problems with this, send mail to jaya@ics.uci.edu
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 column applies for descriptions of activities and record the amount of time spent in hours, to the quarter hour.
Keep a copy of your log. You will be marked down only for failing to hand in logs with each phase, handing in illegible logs, 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 once per week (outside of class lecture) and preferably 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. Have an agenda for each meeting, which is determined by the manager.
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, like ICS 125, 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. Since 126 "does 125" with a "double helping" it should be even more popular.
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. Since ICS 126 should be even more realistic and in-depth than 125 I suspect employers will be even more impressed!
Choice of computing platforms will depend on the projects chosen. Where possible and reasonable Java will be the implementation language used. At a minimum, to facilitate sharing of files among team members, each team will have an account on Octavian, a Unix (Solaris 2 on a Sun) machine.
Scads of Java information is available on-line, including a tutorial, reference material and many, many packages, such as those available from Gamelan.