Student Originated Software 1997-1998 Fall Quarter
		A Software Engineering Course at The Evergreen State College

Student Originated Software Case Study Syllabus Fall Quarter, 1997 Last Revised: October 3, 1997 Description During the first quarter of this three-quarter program student teams will complete a small programming project as a "case study" in software engineering. As in "real-life" the team must produce proper "deliverables" (usually documents) as well as operational software that meets its requirements. The program will be written in SmallTalk. We will cover three main areas in this case study. Deliverables (which take certain forms and can be evaluated according to some criteria) Processes for creating timely high-quality deliverables. (This also includes working in a team etc.) Issues, philosophical questions, etc. Students need to show that they can produce the deliverables (by demonstration, explanation or both), follow the processes (as above) and discuss, assert, defend issues, etc. We will spend class time deriving the (1) rationale; (2) elements (and attributes); (3) format; and (4) quality criteria, for each deliverable. Purpose The purpose of the case study is two-fold. First, students will learn about software engineering through the usual educational route: reading, writing, thinking, listening to lectures, and completing exercises. Second, students will learn by-doing. They will learn techniques for developing software systematically by actually working in a team context developing software. Both of these approaches are intended to help prepare students for the project (which is the primary focus of the entire program) and beyond .. yes, even the "real-world." Plan We will follow a basic pattern throughout the quarter. For each week we will investigate a basic theme. On Monday mornings we will have lectures, discussions, and workshops on aspects of the week's theme. These are not intended to be monologues: students are expected to reflect on the material and participate in discussions. Tuesday afternoon will be more tightly focused on the case study. Students will be presented with material that reflects the current status of the problem that their software will address. On Tuesday afternoons we will discuss and work on the case study. Reading assignments should be read by the following Tuesday. An exercise will be passed out nearly every Tuesday and collected the following Tuesday. All exercises must be typed. The exercises will be returned the following Tuesday after that. Students will keep all exercises in a case study notebook. Due to the incremental nature of the case study and the cumulative and sometimes changing knowledge about the project, these assignments should be updated periodically and added to the notebook. Original and updated assignments alike must be added to the case study notebook. All notebook material must be dated. The entire notebook will be turned in on Thursday, December 4. The Object-Oriented (OO) portion of the class is aimed at improving software skills as well as knowledge of OO techniques, and is critical to the successful completion of the case study. Case Study Deliverables Feasibility Study Software Development Plan Requirements Specification User Interface Design Software Design Testing Plan User's Manual Operational Software Week 1. Systematic Software Development How is software developed? Are some ways better than others? Why? Why do companies prefer a systematic approach over hacking? What's a software "life cycle?" Monday, September 29 Lecture and Discussion: What and Why is Systematic Software Development (AKA Software Engineering)? Tuesday, September 30 Case Study: Introduction to case study, project videotape, and Feasibility Study discussion. Assignment given: Feasibility Assessment exercise Readings assigned: Software Engineering Best Practices, pages 1 - 17 in Wilson; Part I in Koberg and Bagnall, pages 8 - 35. Thursday, October 2 Q & A on Feasibility Study Week 2. Coordinating the Software Project There is a lot more to software development than writing code! This week we will consider the wide range of issues that encompass software development including team issues like cooperation, communication, and coordination; project management issues like roles and responsibilities, scheduling and reporting; organizational issues like communicating within a large institution; and the important role of documents. Monday, October 6 Lecture and Discussion: Coordinating the Software Project Tuesday, October 7 Assignment given: Software Development Plan Assignment collected: Feasibility Study Readings assigned: Teamwork, pages 19 - 26; and Quality, pages 27 - 38 in Wilson Week 3. Requirements Analysis In order to develop a system that everybody likes and wants we have to agree first on what it's supposed to do. During the phase of requirements analysis we need to completely and unambiguously figure that out and record the conclusions in a Requirements Specifications document. Monday, October 13 Lecture and Discussion: Requirements Analysis Tuesday, October 14 Assignment given: Requirements Specifications Assignment collected: Software Development Plan Readings assigned: Week 4. Conceptual Analysis/Design How do we turn our idea of what needs to be done into software that actually accomplishes it? There are several approaches to this problem but all of them involve finding out what type of information people need and how do they and how will they use that information in order to accomplish a task? Monday, October 20. Lecture and Discussion: Conceptual Analysis/Design Tuesday, October 21 Assignment given: Conceptual Analysis/Design Assignment collected: Requirements Specifications Readings assigned: "interface", Jonathan Grudin Week 5. User Interface Design A bad user interface can defeat the best application code. What can we do to recognize and design good user interfaces? Monday, October 27 Lecture and Discussion: What's a User Interface and How do we Build a Good One? Tuesday, October 28 Assignment given: User Interface Design Assignment collected: Conceptual Analysis/Design Readings assigned: Community Participation in Health Informatics in Africa: An Experiment in Tripartite Partnership in Ile-Ife, Nigeria (CPSR: 1996) Week 6. Design: System, Detailed, and Participatory Monday, November 3 Lecture and Discussion: System and Detailed Design Tuesday, November 4 Assignment given: Software Design Assignment collected: User Interface Design Readings assigned: Design Specifications, pages 49 - 57; Design Reviews; 59 - 68 both in Wilson. Thursday, November 6 Lecture: Participatory Design (tentative) Week 7. Implementation This week we discuss the critical -- but not sole -- factor of the software itself. These discussions will revolve around issues associated with implementing; i.e. writing the actual software. Monday, November 10 Lecture and Discussion: Implementation Tuesday, November 11 Assignment given: Assignment collected: Readings assigned: Code Reviews, pages 69 - 98 in Wilson. Week 8. Testing How do we prove to ourselves that the software does what it's supposed to do? By Testing. How can we test software in a way that is cost-effective (doesn't go on forever) but actually finds the problems? Monday, November 17 Lecture and Discussion: Testing Techniques: Black, White, and Shades of Gray Tuesday, November 18 Assignment given: Testing Plan Assignment collected: None Readings assigned: Best Practices for Software Testing, pages 119 - 131 in Wilson. Week 9. Aids to the User: Documentation and On-Line Help Monday, November 24 Lecture and Discussion: Documentation and On-Line Help Tuesday, November 25 Assignment given: User Guide Assignment collected: Testing Plan (keep a copy for system testing!) and the rest of the case study notebook. Readings assigned: Week 10. Software Maintenance Software development does not stop after the program is first released. Often users want new enhancements. Some users have the audacity to suggest that bugs gets fixed (or that defects get removed). Moreover, companies like to keep adding features to their programs so that users will keep buying updates and new releases. This week we will discuss maintaining the software (which includes both enhancement making and bug fixing) after initial release. Monday, December 1 Lecture and Discussion: Software Maintenance: Onerous Chore or Thankless Unpleasant Task? Tuesday, December 2 Assignment collected: Results from Testing phase; User Guide Thursday, December 4 Assignment collected: Mini-demonstrations of operational software and group discussion.