News

Course news and announcements are at http://uo-cis422-08f.blogspot.com/

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.

The project

We will produce a soundscape map for blind users. That means a map in which sound cues are used in place of visual display. This is part of a series of projects leading ultimately to a platform to support assistive cartography researchers rapidly devise and evaluate new ideas in building maps that are really useful for blind users. (>>more)

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 (until Fall 2007) I used a two-project organization. In the first, 4-week project, both the project and the teams were assigned by me. In the remaining 5 weeks, students completed a project of their own choosing, with teammates of their own choosing. In practice this meant 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 ran 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 year we again have the worst case: The holiday break wipes out the end of week 9, as it did in Fall 2007. So, I will give one project for the full term, with an initial turn-in Tuesday of week 5 (Oct 28) and a final, revised turn in Tuesday or Wednesday of week 9 (Nov 26). 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 old 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.