Course Policies

Course Description

Introduction to the software lifecycle. Methods and tools for the analysis design, and specification of large, complex software systems. Project documentation, organization and control, communication, and time and cost estimates. Prerequisite: CSC345-Data Structures.

Course Objectives

After this course, you will be able to

outline the approaches available to a group desiring to design a large software project,
explain the advantages and disadvantages of each approach in relation to a particular project,
apply a variety of methodologies to programming projects,
explain the role of software quality assurance,
explain the role of Software configuration management, and
develop schedules and resource estimates for a software project.

Expectations

I have good news and bad news with respect to the course material. The good news is that there is nothing particularly difficult or hard to understand about the material we're going to cover.

The bad news is that there is a lot of straight-forward material to read and understand. This means that it is critical that you read the assigned material before coming to class. Our lecture time is spent discussing the material, not being exposed to it for the first time. If you don't read before coming to class, you will not be able to contribute to the class discussion, nor will you be able to learn much from it.

Support Material

I'm pleased to offer a variety of support material for this course. I divided these into the categories you see below.

Required Sources

Brooks, Frederick P.(1982) The Mythical man-month. Addison-Wesley, Reading, MA.
This book is a classic in the field of software engineering. Everyone has read it and talks about it. I've sequenced the essays in the book so that they relate to the topics we're discussing in class.
Pressman, Roger S.(1992) Software engineering: A practitioner's approach. McGraw-Hill, New York.
This book is our primary text. Expensive, but worth it. Besides, we use it for two courses (CSC440 and 441), so you'll end up reading virtually every word.
Course Newsgroup poly.course.csc-440
We use the newsgroup to keep in touch with one another throughout the course. Any questions you have concerning the course in general, what you're supposed to do for any particular assignment, et cetera, should be posted to the newsgroup. If you have personal questions (i.e. "what do you think of my hairstyle? When can I get an appointment to see you?"), then feel free to send me email. If you send a question to me through email, I may ask you to post it on the newsgroup. Don't take that as a rebuke, I simply mean that the question is sufficiently general for many people to be interested in the response.
I encourage you to use the newsgroup to post references to items of interest to software engineers.
Jones, Capers. (1995) What Are Function Points?

Helpful Books

Humphrey, Watts S. (1990) Managing the software process. Addison-Wesley, Reading, MA.
Paulk, Mark C., et al(1993) Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24. URL: http://ricis.cl.uh.edu/CMM/TR24/tr24.html
Paulk, Mark C. et al(1993) Key Practices of the Capability Maturity Model, Version 1.1, CMU/SEI-93-TR-25. URL: http://ricis.cl.uh.edu/CMM/TR25/tr25.html
Software Engineering Institute. URL: http://www.sei.cmu.edu/.

Grading

I will assess your performance based on three components. Table 1 contains the specific point availability for each assignment.

Table 1. Scoring Summary
Component Number Points each Total Points

Journals 3 100 300

Labs 4 100 400

Participation 2 100 200

Total 900

Table 1. Scoring Summary
Component	Number	Points each	Total Points
Journals	3	100	300
Labs	4	100	400
Participation	2	100	200
Total	900

Journals

Before this quarter, I followed the traditional paradigmn of assessing student performance by using examinations. However, during Winter Quarter, 1996, I took a psychology class (PSY330) in which we sat for exams. Although the instructor used what I considered to be "good" exams (clear questions, followed the class discussion and reading, etc.), I felt dissatisfied with the experience. Consider this: when creating an exam, the instructor reviews all of the material to be tested and selects the portions he considers "important." If I happen to learn the answers to the questions he happens to ask, then I am thought to be "smart." If, on the other hand, I learn material that he just didn't happen to ask (but may be equally valid), then I am labelled "stupid," "lazy," or something.

A better way, I think, is for students to keep a journal. This permits each student to show me what they have learned. Additionally, it permits me to chat with each student personally to assess their learning. This permits students to tailor (somewhat) the class according to their individual interests. I've prepared a set of guidelines for the preparation of journals, please review them and refer to them often when writing in your journal.

It is your responsibility to schedule time with me to review your journals three times during the quarter. During this time, I'll read through your writings and ask you questions about them. For example, I may ask you to relate your writings to the topics covered in class or to software engineering. I may ask you to speculate about what the impact of the state of software engineering is everyone had similar thoughts.

Labs

The lab assignments will permit you to apply the concepts discussed in class to a programming situation in greater detail than the examination permits. You will produce most of the documentation required by each phase of the software development process. In addition, you'll have the opportunity to critically evaluate the work of your colleagues.

Participation

Your active participation is critical to the success of the class, in both the lecture and lab portions. In the past, I've tried numerous methods of encouraging and rewarding active participation. This quarter, I've decided to rely on internal motivation to produce discussions in thte lecture period. It works like this: When we get to class, I start asking questions. If no one seems interested in discussing the day's topic, I will assume that everyone has mastered the material and views the prospect of discussing it with boredom. Accordingly, I'll dismiss the class for the day and emphasize that material on the examination. On the other hand, if everyone has prepared for class be reading the material and thinking about it before class, we can have interesting discussions during the lecture period.

During the lab period, I'll grade you by observing your conduct when you are presenting your portions of the project and your conduct during reviews of your colleagues' portions of the project.

Bonuses

To help foster cooperation among the groups and to give you practice in reviewing the work of others, I've devised a bonus mechanism. Each of your lab groups will be paired with another. When it is time for a Formal Technical Review (FTR) of your lab assignments, your sister group will assist you in reviewing your assignment. The review group will get a bonus if the production group earns an A on their assignment. Thus, it is in everyone's best interest to follow the software engineering process closely and produce work of the highest quality.

Assignment Due Dates and Times

I assign only one due date and that is for the Contract Proposal. That assignment is due at the beginning of the class period on the assigned day. You and your lab groups will determine the schedule for the remaining deliverables using the techniques we'll cover in class. When I approve your proposal, the dates you've specified will become the real due dates.

Grade Computation

I will determine your grade by adding the points you earned on various assignments. I'll then divide by the total points possible and use the result as an index into Table 3. Note that this process establishes the minimum grade you may receive; I reserve the right to assess learning in a variety of circumstances and adjust grades accordingly. I will not, however, assign you a letter grade lower than that indicated by the quantitative method set forth above.

Table 3. Letter Grade Lookup Table
Numeric Grade	Letter Grade
90--100	A
80--89	B
70--79	C
60--69	D
0--59	F

Academic Integrity

Dishonesty is inconsistent with academic pursuits and professional work as an engineer. You are responsible for your own work. Examples of academic misconduct include, but is not limited to:

claiming the work of another as your own (plagarism),
taking an examination in which you have an unfair advantage over the other students, whether you created the situation of unfair advantage or not,
failing to report instances of academic misconduct about which you have knowledge,
theft of intellectual property, and
mis-use of computing resources.

Anyone who commits any of these (or related) offenses will receive an F in this course and a referral to the Vice President for Student Affairs for further action.

If you have trouble determining whether your contemplated course of action is ethical, save yourself some trouble and consult the instructor before taking action.