Software Engineering

With appologies to Sun Tzu

The art of software development is of vital importance to every enterprise.
It is a matter of life and death, a road either to success or to ruin.
Hence, it is a subject of inquiry which can, on no account, be neglected.

Course Objectives

Students are assumed to have a good understanding of programming and exploiting the features of programming languages and libraries.
But interesting software is sufficiently subtle and complex that it is not usually possible to sit down, think about it for a few minutes, and start coding.
Building working software requires tools, discipline, and methodology.
This is a course in software development concepts, issues and methodologies, whose goal is to develop:

• your ability to organize and effectively manage large and complex team projects.
• your ability to gather, define, clarify and validate requirements for non-trivial software projects.
• methodologies to approach the creation of good specifications, architecture, designs, and test plans for efficient and robust software.
• your ability to understand, describe, and review complex software systems and development processes.
• an understanding of a range of software development processes and the types of project to which they are best suited.
• your ability to recognize, analyze, discuss, and address the problems that arise in such efforts.

This is a very practical course dealing with real-world problems, the issues that complicate them, and the approaches that have been successfully applied to their solution.

Instructor: Mark Kampe

My background is not academic, but in Operating Systems development. I have spent almost 50 years designing, building, and guiding operating systems, operating systems related projects, and system software development teams. Much of my work has focused on high performance and highly available multi-processor and distributed systems. I teach for fun, and to help develop the next generation of engineers. My goal in this course is to identify the most valuable concepts and techniques, and to make them interesting and clear.

Assumed Student Background

• abiliy to design, write, build, and debug software in multiple languages
• experience with researching, obtaining, and learning to exploit new libraries and software development tools.

Assigned Readings

This is a concept-rich course and there is a great deal of reading (averaging 45-50 pages per lecture). A few days will be shorter than this, and one of them is much longer. Fortunately, I think you will find that most of the material is simple enough to be understood in a single reading.

The primary text for this course is Steve McConnell's Code Complete (2nd edition) This is an excellent book, available in paperback, that you will probably keep for a very long time, and replace when you eventually wear it out.

For more general Software Engineering topics, rather than force you to buy an expensive Software Engineering text (half of which would be uninteresting), I have attempted to assemble a collection of small, publically available articles on selected topics. URLs for all of these articles can be found on the reading and lecture schedule.

Lecture Sessions

Lecture, Reading, Lab, and Exam Schedule

It is not my preference to use the lectures to review topics that are well presented in the reading. I hope to use the lecture time to:
• discuss student questions arising from the reading.
• expand on key results that should be drawn from reading.
• work through and discuss important but non-trivial examples from the reading.
• have group exercises related to these topics.
• discuss perspectives, implications, and applications not covered by the reading.

You can help to enrich the quality of the lecture sessions by:

• using the on-line forum to suggest questions and topics to be discussed during the lecture sessions.
• asking questions during the lecture sessions.

All lecture slides will be available on-line before the start of each lecture. This should simplify your own note-taking and give you a starting point for exam preparation. It will also give you the opportunity to see what topics I am planning to discuss in each lecture. If you find (after reading or a lecture) that there are additional topics you would like to discuss, please post them to the course discussion forum.

Quizzes

Years of experience have consistently taught me that the greatest single predictor of how much a student will get from a lecture is how well they understood the material before the start of the lecture. I have found (and student surveys regularly confirm) that giving daily quizzes on the assigned reading gets students to do the reading before the lecture, and greatly enhances learning. A secondary purpose of the quizzes is to enable me to assess what concepts you are having trouble with, so that I can give them greater emphasis in future lectures.

I attempt to choose quiz questions, based on key concepts, that few people could answer from common sense or general knolwedge, but should not be too difficult to answer the day after a single reading. Each quiz will have four or five questions, typically asking

• the definition of a key term
• distinctions between key terms
• examples of a key concept
• relative efficacy of techniques

Most quiz questions can be answered with a single sentence (or even a few words). Since the quizzes are timed, short answers are pretty clearly the best.

Exams

There are two exams: a mid-term, and a (whole course) final. These are closed book exams. The purpose of these exams is to determine whether or not you understand the key concepts that have been discussed in the preceding lectures and chapters.

A typical exam will be comprised of roughly 10-20 questions. Some may ask for definitions and examples, but most will ask you to describe how or why something works, to contrast related concepts, to explain which principles are applicable, or to predict what would happen in some situation. The vast majority of these questions will pertain to designated key concepts, and in most cases the answers will have been presented in the text, the lectures or both. Most exam questions have brief (2-4 sentence or a simple diagram) answers. Typical types of questions might be:

• simple "do you remember" questions, comparable in nature and difficulty to quiz questions.
• moderate "can you describe/contrast/apply" questions, comparable in nature and difficulty to in-class discussion questions.
• moderate "consider this" questions, asking you to find answers not specifically discussed in class.
• a philosophical extra credit question, related to key concepts, but un-related to any reading or in-class discussion.

Different study techniques are more effective for different people. This is a general suggestion for review, that is meant only to guide your own study efforts:

• Start by reviewing the key learning objectives.
• If there is a concept, issue or technique that you don't think you could talk about for five minutes, go back and review the lecture notes.
• If anything in the lecture notes (including the discussion points) is not completely obvious, go back and review the related reading.

Projects

By the end of this course, the students will have not only studied, but actually performed, all of the major steps of a large software project. It is hoped that these exercises will consolidate the learning of these skills and well-prepare students for larger projects to come. There is, in some sense, only one project for the entire course, but it is broken down into a few distinct phases (involving very different activities):

1. Requirements and Proposal
2. Architecture and Review
3. Planning, Specifications, Design, and Review
4. Implementation and Testing

It is traditional, in Software Engineering courses, to have students build a large project. This is intended to give students the opportunity to apply many of the skills covered in the reading and lectures. And I must concede that building software is the most obvious form for projects in a Software Engineering class to take. But, in looking at what students have actually done in these projects, I have found a few major concerns:

• Students are expected to develop coding and debugging skills in the lower division programming series. The academic material in a Software Engineering course deals with project models, work products, requirements, analysis, design, (representation, characteristics of good designs, processes for evolving them), review, testing, and an introduction to projects, process, and organization.

  In a typical Software Engineering project, students spend (at best) 25% of their time on these activities, and 75% of their time coding and debugging. This is realistic (in that it mirrors real software development) but it doesn't provide much opportunity for the students to apply the taught techniques and develop the associated skills.

• The success of a small software project probably has more to do with the motivation, skill, and experience of the development team than with the methodology they employ. Software Engineering disciplines have evolved to manage the risks and complexities of large projects.

  The typical class project involves a one digit number of staff-months of work: the size of a single task in many large software projects. While these projects are highly educational, and a necessary step in the development of discipline and skills, they seem (to me) too small to demand significant exercise of Software Engineering (as opposed to programming) skills.

• Projects (whether research or commercial) seldom fail because the developers lacked sufficient familiarity with languages or other programming tools. Projects fail because of:
  • poor requirements
  • lack of a concrete plan
  • having a bad plan, and not realizing it
  • failure to recognize and obtain required resources
  • failure to recognize and respond to problems
  • poor time and resource management

  If this course is to make a difference, it must address these problems.

My goal, in defining projects for this course, has been to create a series of projects that will focus primarily on the software engineering skills taught in the course.
• In teams, students will be asked to develop requirements and architecture something larger more complex than can reasonably be built in a one semester course. The advantage of this approach is that they will gain the opportunity to exercise important skills that would be poorly (if at all) exercised by smaller projects.
• Each team will then identify a single component of the proposed project (that is small enough to be reasonably accomplished in a few weeks), develop specifications, a design, and a test plan, and then build and test that component according to those plans.

Another goal of these projects is to develop organizational, planning, time management, and post-mortem review skills. This is accomplished by not breaking the project into small pieces, but rather, requiring the students to do this. The students are not merely responsible for producing the required work products, but for creatining and managing team efforts to produce those work products. The project grades are based, in part, on the quality of the plans, the dilligence that was paid to them, and the insights gained in retrospect. It is further hoped that the post-mortem reviews will help consolidate learning of both process and technical lessons.

These are, large team projects; Large enough to give you the opportunity to encounter a wide range of requirements, archictectural, planning, execution, and group problems ... from which I hope you will learn lessons that will enable you to recognize and evade many tragedies in your future lives.

Thus the assigned projects should be seen, both in terms of the primary technical skills they exercise, and successively more demanding sets of project management responsibilities. I assert that it is these skills (and not additional programming ability) that are the primary focus of this course.

Grading

The greatest portion of the grade is almost evenly divided between exams (your mastery of concepts) and projects (your ability to apply skills and techniques).

Weight	Item
10%	quizzes: daily
20%	exam: midterm
20%	exam: final
12.5%	project: 1. proposal
12.5%	project: 2. architecture
12.5%	project: 3. planning and design
12.5%	project: 4. implementation and testing

While a weight is shown for each project, there will not be a "single grade" for each project. Each of the projects will involve a great many activities and deliverables, each of which will be individually graded (and many of which will each be the subject of an entire lecture).

For each project submission most of the grade will be a group-score (based on the overall quality of the submission). A smaller portion of the grade will be personal, based on and divided (more or less equally) between the share and quality of each person's individual contributions to the overall effort. This weighting is because:

1. in the real world you will be judged, not on the basis of your individual efforts, but on the overall quality of your results.
2. teams are not merely a technique for allowing individuals to do less work. A well functioning team can do work that none of the individuals would have been able to do.
3. work division and cooperation are skills that are taught in this class. I expect to see the results of the applications of those skills.

Letter Grading Scale

• I do not grade on a curve, but a fixed scale. I am not trying to assign students to performance percentiles, but rather to assess their mastery of the course learning objectives.
• I do look carefully at the break points to try to ensure that students who did similar work do not get different grades, but the major break points generally fall within a point or two of 88/78/68/58.
• if I make a mistake in a problem that makes it significantly more difficult than intended, I will adjust the scale to compensate for my mistake

Late and make-up policy

• there are no make-ups for quizzes, but you can take a quiz before it is due.
• each student has 4 slip days that can be used for any project submission due date (before the end of the semester). After those have been used up, a grade is reduced by 10% for each 24 hours late the assignment is.
• if you are unable to make an exam, it may be possible (with prior notice) to arrange to take a (different) make-up exam at some later date.

Grade Adjustments

• I will always correct any (promptly reported) error in score computation or recording. You are encouraged to check the on-line grade book regularly to ensure that all of your assignement grades have been properly recorded.
• I am always willing to explain the correct answers and grading criteria.
• I am always willing to regrade an exam problem if I misunderstood a clearly correct answer ... but this does not extend to
  • reinterpreting vague or poorly written answers
  • giving credit for not having properly or fully understood problem
• I will correct a quiz score if the auto-grader was unable to accept a correct answer.
• I never raise grades in response to excuses or hardship stories.
• I never assign makeup projects. The only opportunity to improve a grade is before the assignment is submitted.

Academic Honesty:

The most valuable thing you will get from this course is a mastery of concepts and techiques that will serve you throughout your career. Your grade in this course gives testimony to that mastery. But those benefits will only accrue, and the grade will only be meaningful if it is honestly earned. Students must follow the Academic Honesty standards of both Harvey Mudd and the Computer Science Department which prohibit cheating, fabrication, multiple submissions, and facilitating academic dishonesty.

Students are encouraged to study together, and to discuss general problem-solving techniques that are useful on assignments; but all exams are to be completed individually without assistance or references; when working on the projects students must not share work with others (outside their team), and must specify the sources for all non-original parts of submitted work.

If you have questions about the policy, please discuss them with me. Be warned that I take Academic Honesty deadly seriously. I use a variety of tools and techniques to detect plagiarism, I report all suspected cases to the Dean's office, and I seek full prosecution of every case I report.

Please, do not test me on this matter.