Skip to main content.

News

Old news has its own page.

Finals week

The scheduled final exam is 8am on Friday.

If you prefer, you can take the final exam Monday, 3:30-5:30pm. Meet at my office in Deschutes hall, and we will find a room suitable for the number of people who show up. (I count on you to be honest and not share the final exam questions with those who take the exam on Friday.)

My exams are always open book, open notes. You may write your answers legibly on paper, or you may type them (plain text only) on your own laptop computer. You may bring any materials you want in hard copy or soft copy, but you may not make use of the network during the exam (in fairness to those who do not bring computers).

Slides

Some of these are versions from earlier terms, but I think the differences are pretty minor.

Our discussion of software testing was done without slides, but you can find slides from my book as well as a couple sample chapters at the book web site. A lot of the questions I used to drive the discussion are from Chapter 1, although I rephrased them a bit.

CIS 422/522 Introduction

This is a project-oriented course on software engineering. You will work as teams to construct software systems, including not only programs but also end-user documentation, maintenance guides, etc. You will also be expected to think about principles and issues in software engineering, to read and respond to papers, and to participate in class discussions.

No university course can substitute for years of real-world experience, and that is not the objective of this course. Rather, the objective is to prepare you to learn from that experience. Thus our focus is first on broad principles and issues that pervade software engineering. Because these principles and issues are fundamental, they appear again and again even as popular methods and tools shift. Yesterday we had structured development, today we have object-oriented development, tomorrow we can expect something else ... but the fundamental challenges of teamwork, complexity, change and variation have been with us from the beginning and will be with us for the forseeable future.

Overall Project Organization

We use the first 9 weeks of the term for design and construction of projects. Week 10 is reserved for final presentations.

For several years I have been using a two-project organization. In the first, 4-week project, both the project and the teams are assigned by me. In the remaining 5 weeks, students complete a project of their own choosing, with teammates of their own choosing. In practice this means 3.5 weeks for the first project and 4 weeks for the second, assuming you spend about a week organizing a team and project for the second half.

Each time I run the course this way, at least a few students say they would have preferred a single project for the whole term, because the time available for two projects is just too short. Fall term can be particularly hard in this regard, with the Thanksgiving holiday wiping out half a week near the end of the term. In the worst case, Thanksgiving wipes out the second half of week 9, meaning the project could be due either Tuesday of that week or, if I'm really heartless, Wednesday evening. (Making it due the following week would be even worse, since you'd be forced to choose whether or how much to work over the holiday weekend. I'm mean, but I'm not that heartless.)

This week we have the worst case: The holiday break wipes out the end of week 9. If there is ever a time to try a one-project schedule, this seems to be it. I will give one project for the full term, with an initial turn-in Tuesday of week 5 (Oct 23) and a final, revised turn in Tuesday of week 9 (Nov 19). I will also make team assignments for that project. You will have the option of switching projects after the first turn-in, but I encourage you to refine and extend the first project instead.

I know that some students come to 422/522 with a project and/or teammates in mind. I will modify my usual team assignment policy and ask you to indicate your preferences, if any, in the first questionnaire. I don't promise to give you the teammates you asked for, because I have to find a reasonable team for every student in the class, but I will take your requests into consideration. I will also give you a chance to make trades on Thursday of week 1. A trade requires the consent of both teams and the members changing teams.

You will have the option of switching to another project of your own choosing (with my approval) in week 5, although I do not recommend it. I will ask you to indicate in week 1 whether you intend to take advantage of that option, so that I can form teams that are as stable as possible. This means that I will try to form teams in which either everyone or no one is continuing to the end of the term. Failing that, I will try to at least spread people who will be changing teams evenly, so that one team does not suffer excessive turnover. I will also allow a second round of trades in week 5.

So how does this really differ from the usual two-project schedule if I'm still requiring a turn-in in week 5? Basically I will scale back the requirements for the first turn-in. I will still require working code, user documentation, and developer documentation (including design documents that you should be producing as part of your design deliberations). However, I will treat it as a prototype delivery in which it is ok to have some holes in both functionality and documentation. The first turn-in is still an important deadline and milestone, but the change should be enough to ratchet back the pressure somewhat. Also, if you choose to continue the project, you have a huge head start on the final turn-in.