Date: Wed, 08 Jan 1997 21:51:41 GMT Server: NCSA/1.4.2 Content-type: text/html CSE 403 General Info

CSE 403: Software Engineering - General Info

David Notkin, Winter 1995

  • Where & When
  • 323 Sieg, MWF 10:30--11:20
  • Instructor
  • David Notkin
  • 414 Sieg Hall
  • 685-3798
  • notkin@cs.washington.edu
  • Teaching Assistant
  • Kingsum Chow
  • kingsum@cs.washington.edu
  • Office Hours
  • Check the online schedule for definitive information about office hours for the instructor and the TA.
  • Required Work
  • Participation in designing, building, and presenting a team project.
  • A midterm examination.
  • A final examination.
  • Readings
  • Brooks,The Mythical Man-Month [MMM].
  • Ghezzi, Jazayeri, and Mandrioli [GJM], Fundamentals of Software Engineering. (You may use other similar books: see Notkin for details.)
  • There's also a lot in this and other handouts; I expect you to read them carefully.
  • Exams
  • The examinations are tentatively scheduled to be given on Monday February 6 (in class) and at the regularly scheduled final (Monday March 13, 9:30-10:20AM). The midterm examination will cover material up to and including design. The second examination will be comprehensive.
  • Grading
  • Your contribution to the project will account for about 75% of your total grade. The midterm will account for about 10% of your grade, and the final will account for another 15%. Intangibles, such as class participation, may affect your grade as well. Your project grade will be based on the quality of your work, not just on your effort. You, not the project, will be graded; individuals in a group generally receive different grades.
  • Final evaluation of the group projects is done by (1) a demonstration of the project, (2) a group discussion of the project and the process of building it, and (3) separate discussions with each individual group member. This is a time-consuming process that will take place on Tuesday March 14 and Wednesday March 15. Plan accordingly.
  • Lectures
  • Most of the lectures will cover topics such as the software lifecycle, characteristics of large systems, software specification, software design techniques, development tools, testing, verification, and validation, maintenance, etc. As much as possible, lectures will be coordinated with associated stages of the project. There may be two or three invited lecturers, giving their impression of software engineering, and of the problems with software engineering, at various companies.
  • The following chart shows the tentative schedule for lectures, exams, etc. It is subject to frequent change.
    
    	Week	Monday		Wednesday	Friday
    	1/2 	No class	Overview	Overview/Lifecycle
    	1/9	Lifecycle	Requirements	Requirements
    	1/16 	No class	Design		Design
    	1/23    Design		Design		Design
    	1/30	Testing		Testing		Testing
    	2/6	Midterm		Formal Methods	Formal Methods
    	2/13	Inspections	Environments	Environments
    	2/20	No class	Safety		Reliability
    	2/27	Architecture	Process		Metrics
    	3/6	TBA		TBA		TBA
    
  • Sections
  • Sections will be used in a variety of ways, including group meetings (both among yourselves and also with the TA and/or me), presentations by groups to other groups, etc.
  • Project Requirements
  • Large-scale software projects require teams of designers, implementors, and support staff. Because of this, the construction of these projects demands not only technical abilities but also skills in group dynamics. To give you some experience with these dynamics, you will form groups of four to six people to specify the requirements of, design, and implement the assigned project (described below).
  • You must produce your system according to the schedule that will be handed out on Friday. The schedule includes several milestones, each represented by a specific artifact. (As a preview, the draft of the requirements specification document, the first milestone, will be due on Wednesday 18 January.) It is not necessary that every group member be involved in meeting each milestone. For instance, a person in charge of testing the complex system may not need to understand the low-level implementation choices. However, you are required to state explicitly who has been involved in each milestone and in what capacity. I recommend strongly that each document be written by a single person, with editing help from the others.
  • I will provide additional information, on a timely basis, about what I expect from each artifact; the document describing requirements specifications will be handed out on Wednesday. (I do not have a full set of high-quality artifacts for a similar project. This would be nice, but it is surprisingly difficult to acquire.) Sticking to the schedule for each artifact is essential, so that you can complete the entire project during the quarter. If for some reason the schedule does not meet the needs of your group, I will consider alternatives if careful, reasoned motivations are given. Don't plan on working on just one milestone at a time; you must always have (at least) part of your team looking ahead towards milestones that are coming up.
  • The project description is intentionally under-defined. As a group, you will be responsible for making decisions about the user interface, the data structures, and so forth. One goal of the milestones is to help your group make these decisions in an orderly manner. Feel free to ask questions about what is expected. The TA and I will try to answer these questions as if we were your customers (although with some special knowledge about the constraints of a one- quarter course).
  • Some other details include:
  • Every team must select a name.
  • Every team must take and keep minutes at all of your meetings. The motivation for the minutes is that you may otherwise forget decisions that you made, which is costly in terms of time and energy. Do not spend time formatting these; handwritten minutes are just fine. They should be copied and distributed to all appropriate group members. Bring an extra copy of these minutes every Tuesday during section; we'll scan these to see how your team is progressing and will keep them for our records.
  • Every individual must keep a personal log. The logs will be checked on occasion at sections. They are intended to help both you and us keep track of where your time is going. The log, which is not very different from time sheets that many employers require you to complete, includes the date, the description of the activity, the time it took, and some explanatory text. The following is a sample; you may select different categories, but be consistent. As with the minutes, don't format these. You may find that keeping them in a bound notebook is effective. Bring these to Tuesday sections; we'll also want to have them turned in at the end of the quarter. Here is an example of a few entries from a personal log.
    
    	Date	Category		Time (Hours)	Notes
    	30 Sep	Lecture			1.0		Notkin's intro
    	1 Oct	Project Planning			Jane & Biff join group
    	2 Oct	Lecture			1.0		Intro continued
    							Didn't follow a word
    	2 Oct	Reading			3.0		MMM Chaps 1-7
    							(Better than he said!)
    	2 Oct	To Do in Future				Read "No Silver Bullet"
    	3 Oct	Lecture			1.0		Basic SW life cycle
    	3 Oct	Reading			2.0		Finished MMM
    
    Note that some of the entries are essentially instantaneous (forming your group may or may note be like this) and need not have times attached. Others are prescriptions for later things to do (either during or even after the course). You may have categories later in the course for group meetings, planning, editing, debugging, etc.
  • The development language you will use is either Ada or C++. In some cases, given a good motivation, I might grant permission for a group to use an alternative language. But in no case will I permit a group to use a language for which all group members who will be programming do not have expertise; there is too much to do this quarter to add on the burden of learning another programming language.
  • Your group must communicate well. In addition to selecting a management structure, I recommend that you decide on firm times for group and subgroup meetings. You may wish to distinguish among status updates, brainstorming meetings, decision-making meetings, etc.
  • Your group may lose a member for various reasons. If this happens, you will be expected to close ranks and adjust to the problem. Losing personnel does happen in the real world and is another motivation for carefully documenting each step along the project path.
  • Because software development is less predictable than is desirable, you should plan from the beginning for reasonable subsets of the system.
  • Computer resources always seem to be the most precious when they are needed the most. The real world is no different from academia in this respect: machines are often loaded or unavailable at critical times. You have been warned.
  • People in projects make mistakes. They don't save their files before a crash, or they inadvertently delete key directories. Be careful and try to develop managerial or technical approaches for reducing this kind of error. Similarly, you need approaches for helping your group keep track of multiple versions of artifacts, including code.
  • This course is time-consuming, so make sure to use your time well. Don't stare off into space while a program is compiling. Don't draw complex figures using a computer if a quick sketch by hand is sufficient. Don't debug by just permuting the statements in your program.
  • Project Description
  • Check the Project Description for information about this quarter's project.
  • Check the Project Schedule for information about the project schedule.
  • 
    
    

    notkin@cs.washington.edu (Last Update: 1/6/95)