Please report broken links and other problems to Michal YoungLecture slides will be posted here week-by-week, in PDF (Adobe Acrobat) format. I'll try to post them before I actually give the lecture, but I may fall behind.
[Course Overview] [Group Dynamics]
[Project 1 Overview] (this is a handout in html, not slides)
[Software Development Processes] (I will use only a subset of these and try to cover it in one lecture.)
Reading: Chapter 1 (Introduction) in Sommerville, especially sections 1.2 through 1.4. Chapter 3, sections 3.2 and 3.3 are also useful; section 3.4 will be more useful to you in project 2.
Reading: Sommerville Chapters 12 and 13.
[Basic Project Hygiene] This is a hodge-podge lecture that combines some notes on revision control, some on documentation and coding, some on testing, and other stuff that I think might be useful. Each of the topics deserves a more in-depth and systematic consideration, but I throw together these little scraps of information here as a kind of "survival guide." In addition to the usual PDF version, here's an [HTML version].
Reading: Sommerville Chapters 19 (Programming for Reliabilty) and 33 (Configuration Management).
I think 19.1.1 is superficial to the point of being silly. The general idea of avoiding error-prone code is good, but it should be applied at the level of design approaches and not just programming language constructs. You can skip 19.2 on fault tolerance unless it interests you. When you read 19.4 on fault recovery, think about the fault recovery in your project --- if the power goes out in the middle of running your program, or if your program has a bug that makes a hash of his or her html files, what is the recovery procedure?
Chapter 33 is more detailed than you really need for project 1, and a lot more detailed than my lecture, but it's not too long so you might as well read the whole thing now.
[Human Factors and User Interface Design]
Required reading: Sommerville Chapter 17 (User Interface Design).
Recommended readings:
The Design of Everyday Things. Donald A. Norman. Doubleday 1990. (Previously published in 1988 as The Psychology of Everyday Things.)
Programming as if People Mattered: Friendly Programs, Software Engineering, and other Noble Delusions. Nathaniel S. Borenstein. Princeton University Press, 1991.
[More on Design] An exercise that was in my earlier architectural design slides, that we didn't get to in class, plus some thoughts and heuristics about how the creative, technical problem-solving part of design is related to the discipline of architectural design.
[Requirements Elicitation] as distinguished from requirements specification. I covered only a few of these slides. I'll cover more later, but I don't intend to spend much more time on organizational context. (Sommerville touches on that subject.)
Reading: Sommerville chapters 4,5,7. Chapter 6 is optional for now, but I may require it later.
On Wednesday I intend to return (again) to architectural design, to try to make the idea of [information hiding] clearer. This lecture has more diagrams; hopefully they will help.
[Project documents], particularly internal documents (requirements, design, etc.) as distinguished from documents produced for the end user.
Reading: Sommerville chapter 6,14, as well as some of the previously assigned chapters: 4,5,7,12,13.
Monday: [Concurrency Control]. This is a topic I don't normally cover in CIS 422, but it seems appropriate this term because several teams will be writing multi-threaded applications of some kind. As with some other topics, concurrent programming and concurrency control could easily be a full class or a two-term sequence by itself. To try to do something useful in a single lecture, I'm focusing on one approach to dealing with concurrency --- using locking protocols (particularly 2-phase locking) together with resource ordering to maintain global consistency and avoid circular waits (deadlock). Models of concurrency (Petri nets, process algebra) which might be useful for designing the details of process interactions are mentioned only in passing, and alternative concurrency control techniques are likewise only mentioned. This choice of focus reflects my opinion about the best way to design a concurrent application: As much as possible, we design the concurrency such that we can ignore it and design as if there were only one thread of control. The choice also reflects the tools you have available: Lock-oriented concurrency control is what Java supports best, and it's a reasonable fit with Unix processes (twisted a little to use remote procedures sometimes as monitors).
There are a few extra slides at the end of the lecture giving a very brief introduction to alternative concurrency control approaches; these are likely to be useless by themselves but might help you decide that you want to read more about a particular topic such as priority ceiling protocols or time-stamp concurrency control.
Wednesday: The schedule says I should talk about maintenance and evolution this week and testing next week, but I think I'll reverse it because testing is going to (or at least should) have an impact on your design and schedule soon.
Friday we will have design presentations and discussions again --- which means I'll be asking for volunteers on Monday and, if necessary, making assignments.
Not yet
Not yet
No lectures this week - project presentations instead.
No lectures this week - final examinations instead.
*PDF (portable document format) version 2, which requires Acrobat Reader or Acrobat Exchange version 3. The Reader is available for several platforms (Solaris Sparc and x86, Linux, Mac OS, Windows 3.1, 95 and NT, HPUX, etc.) free from Adobe, http://www.adobe.com. See also [troubleshooting notes].
Last update: 14 April 1998
Please report broken links and other problems to Michal Young