For those papers used in the course, a brief annotation is provided summarizing the main theme of the reading and my rationale for its use to suit course objectives.
This chapter focuses on the practices associated with Extreme Programming and their interactions with one another. Extreme Programming is arguably the Agile Method that has received the most press in the practitioner literature. I use these chapters because they provide a new and important methodological framing for many of the individual practices that students have employed throughout the term (e.g. simple design, automated unit tests, pair programming)
This article provides a brief overview of using CRC (Class, Responsibility, Collabotor) cards for generating alternative software designs in small development teams. They provide nice illustrative examples, and argue that CRC cards provide a kinetic, low-cost, low-tech means for facilitating class design discussions among developers. Though students to not appear to adopt CRC cards as a technique that they will use throughout their lives, its focus on answering what are the parts, what does each part do, and how do the parts interact is at just the right level of abstraction for doing class design.
This article comes bundled with the Junit download, and provides an incremental use of automated testing using Junit for the development of a simple example program. Although I like the article, students have reported difficulty in generalizing from the discussion in the article to using Junit analogously in their own code.
This article provides a definition of a software lifecycle model, its function in software development, an overview of several models, including code and fix, waterfall, evolutionary, and Boehm's Spiral Model. Boehm himself admits that the Spiral model is not as developed as other models and requires considerable expertise for effective use. Yet his definitions are clearly written and his clear exposition of that there are different models and the distinctions between them make this an excellent introduction to the subject, and provide a basis for my explaining to students why we use the waterfall model in the course. In addition, he has an excellent discussion on risk management in the software development process.
If I were to use a textbook for this course, this is book that I would use. The text is very practice-based as opposed to the comprehensive surveys common in texts such as that of Pressman. My main reason for using this chapter is its clear use of testing terminology (test case, test suite, drivers, stubs, unit testing, regression testing, etc.), and its discussion of different test methods at different places in the software lifecycle. They also focus particularly on unit and integration testing, those aspects of testing that students will most need in carrying out their projects. I also particularly like their explicit reference to testing as an instantiation of Popper's falsification (or refutational) epistemology.
Cockburn provides an overview of the use case, extended examples, a "form" for how use cases are documented, a strategy for how to write use cases - abstract to concrete - reflecting one of the course's recurring themes, and a discussion of how the use case fits within the requirements process. What more could I ask for?
Faulk provides a broad overview of requirements gathering. I do not discuss this article in class, but ask students to read it so as to have some framing knowledge about the requirements process. I think that it is only moderately effective, and students rarely make reference to it in discussions.
This text is my hands-down favorite for UML. It focuses on the essential aspects of UML as a communication medium, leaving aside the more obscure aspects of the notation, or separating them for later chapters. I preferred the 2nd edition, but that is also because I preferred the version of UML that it described. I particularly like the different "perspectives" he provides in the Introduction for how one might use UML, and his chapters on the Class and Sequence diagrams are just enough to be immediately usable by students both for reading and writing.
I use only this partial chapter because it is a particularly compact and lucid description of Mayer's design by contract (i.e. the use of preconditions, postconditions, and class invariants to specify method behavior) and because it uses Java notation and assertions, mirroring my own and students' use. I used to use Mayer's chapter on DBC in his Object Oriented Software Construction, but the discussion was too detailed for the newcomer, and the use of Eiffel notation and semantics was difficult for students to transfer to their own practice.
This chapter provides an overview of the space of review techniques for software artifacts. I like its emphasis on differences in scope, purpose, documentation, leader, and people involved, and its graphical depiction of how it can be used at different places in the waterfall lifecycle model. I do find the article dry and pedantic, (probably because of its lack of specific examples) and make little explicit reference to it in class.
This is probably the most important article that I ask students to read. The article describes principles of object-oriented design encapsulated as a set of simple, pithy design heuristics. I view these principles as a mechanism for critiquing and adjudicating between alternative designs, and as a basis for refactoring. Students refer to these heuristics and use the terminology of this chapter (esp. "God class") throughout the balance of the term without prompting.
Paper prototypes are a simple, low-cost, socially enacted technique for developing graphical user interfaces using simple office supplies, and then subjecting these non-functional interfaces to early usability testing through "play acting" the computer. These chapters focus on specific examples of paper prototypes from actual systems that the author has been involved in developing, and a brief tutorial on how to create the interface. No reading is provided on usability testing, though this is discussed (and performed) in class.
This provides a straightforward account of Sun's java coding standards. I use this to point out the sort of things that coding standards describe and as an explicit guide to the standards that are used in Sun's own code and API's. I require students to use this as a default, arguing that programming is a cultural practice and the necessity of learning the rules of discourse within programming communities.
Provides an overview of pair programming, the different roles, and a rationale for its use. Though I do not require students to use pair programming, many students do so and report it as one of the most important practices that they have adopted.