CS100: Software Construction

Professor: Dr. Teodor C. Przymusinski, (951) 787-5015
Lecture: Monday, Wednesday, Friday 1:10-2:00 PM
Office hours: Monday, Wednesday, Friday 4:00-5:00 PM SURGE 335 or by appointment.

TA: Vladimir Vacic
Discussion: Wednesday 6:10-9:00 PM, SURGE 171
Consultations: Wednesday 3:10-6:00 PM, SURGE 282 or by appointment.

Catalog Description

Development and construction of software products. Topics include design, coding layout, and style; implementation strategies; quality attributes; prototyping, reuse, and components; debugging, testing, and performance; integration and maintenance; documentation; standards, analysis, and selection of tools and environment; and personal software processes.


CS 141: Intermediate Data Structures and Algorithms


Andrew Hunt, David Thomas: The Pragmatic Programmer. Addison-Wesley, 1999. You can download additional material for this book here. An errata is available.

Martin Fowler: UML Distilled. Addison-Wesley, 3rd edition, 2003.

Expected coverage

The Pragmatic Programmer will be covered in full either in class or in the lab or through self-reading.

The following chapters from UML Distilled will be covered:

Selected topics from remaining chapters as time permits.

Important Note: Students are required to read the sections pertaining to the material covered in the class and familiarize themselves with the relevant exercises. Students are also required to attend both the lectures and the lab sections.

Grading Policy

Grading will be based on team projects and several pop-up quizzes and homework assignments. Class participation will be also considered. Approximate weights assigned to them will be as follows:

All programming must be done in C++.

Letter Grades: Letter grades are ***roughly*** assigned according to the usual 90/80/70/60 rule: 90% and above correspond to an A, 80% and above to a B, 70% and above to a C, 60% and above to a D, and less than 60% to an F. +/- grades will be given where appropriate. The exact cutoff scores will not be posted.

Academic honesty

Programming projects must represent your original work and must be developed completely independently by each one of the students. Copying from any sources (web, other books, past or current students, etc.) is strictly prohibited. No cooperation, discussion, sharing, exchange or consultation between the students themselves is allowed. This, of course, does not apply to any discussions taking place during the lectures under the supervision of the instructor.

You can report cheating anonymously at: https://www.cs.ucr.edu/cheating/.

Students violating this policy will be given a failing grade for the course and their case will be referred to the office of Vice-Chancellor for Student Affairs. On the other hand, students are strongly encouraged to cooperate and consult each other in preparation for the exams.

Mailing List

A class mailing list: cs100@lists.cs.ucr.edu will be established to disseminate information pertaining to this class. Make sure to sign-up for the mailing list in order to receive prompt information about class assignments, additional resources and other pertinent matters.

You can sign up for it at: https://www.cs.ucr.edu/mailman/listinfo/cs100

IMPORTANT: only UCR e-mail addresses will be allowed on the list!

Lab 1

Topics: Reading:

Lab 2

Topics: Reading: Homework:

Lab 3

Topics: Reading:

Lab 4

Topics: Reading:

Project Phase 1

There are several things that need to be accomplished, some more some less immediatly connected to the project. I need you to:

What I am expecting to get out of this section of the project:

Lab 5

Topics: Reading:

Lab 6

Topics: Reading:

Project Phase 2

Keep on working on your project according to the specs you got in class today. You should update the documentation and your code according to the latest batch of requirements. Clearly a lot of things will be new. Clearly a lot of things will be what you had before, if maybe slightly modified. Some things might get refactored. Make sure all of them work together. Make sure your documentation is consistent.

The nature of this project is cumulative. So should be your submissions. At any point when you are turning something in, you will have to turn in everything you worked on until that point. This does make your life easier in some sense because a lot of things will be done when you start coding, but you have to perform some integration testing, and if you are modifying your code from before, regression testing.

Deliverables for the second phase of the project include everything from before for the first part of the project, everything from before for the second part of the project, *plus* some methodology and discussion of testing mechanisms you employed. Include test samples, code that tests your code, etc. One of the goals of this phase of the project is to make you view testing as a necessary part of the development process.

Lab 7


Lab 8


Project Phase 3

As said before, this project is cumulative. For Phase 3, you need to add details presented in class on Friday, May 20. Essentially, after completing Phase 3, you should have a working application *AND* complete documentation of the process that made the application.

As far as documentation goes, there is only one new area in addition to what you had in Phase 2, and it will be graded lightly. What you had before clearly needs to be extended with Phase 3 data (use cases, CSV file descriptions, sequence diagrams, Doxygen documentation for new modules, and so on). Once again, these are the specific sections I would like to see in the write-up:

For next Wednesday (May 25), prepare a draft for Phase 3. We will follow the usual schedule: group Eelko at 5:00PM, Discovery at 5:30PM, T.P.O at 6:00PM and Red at 6:30PM.

Phase 3 is due on Wednesday of last week of classes (June 1), in the lab, same as before, printout + demo + files uploaded into turn-in.

Lab 9


Lab 10


Project Phase 4

Phase 3 finishes your application. Phase 4 deals with making interfaces to what you have built before -- GUI to enter data, etc. Details will be covered in class on Wednesday, June 1.

On Tuesday, June 7, you will demo the whole application, GUI included. You do not have to turn in the code for Phase 4. You do not have to make any additions to the documentation as far as Phase 4 goes. I will be available the whole day (more or less), so please pick half an hour which does not conflict with your teammates' finals, and let me know via e-mail, so I can pen down your time slot.