📄 http:^^www.cs.washington.edu^education^courses^403^95w^intro.html
字号:
Date: Wed, 08 Jan 1997 21:51:41 GMTServer: NCSA/1.4.2Content-type: text/html<HTML><head><title>CSE 403 General Info</title></head><body><h1>CSE 403: Software Engineering - General Info</h1><h3>David Notkin, Winter 1995 </h3><MENU><li><b>Where & When</b><MENU><li>323 Sieg, MWF 10:30--11:20</MENU><li><b>Instructor</b><MENU><li>David Notkin<li>414 Sieg Hall<li>685-3798<li>notkin@cs.washington.edu</MENU><li><b>Teaching Assistant</b><MENU><li> <!WA0><!WA0><a href="http://www.cs.washington.edu/homes/kingsum/">Kingsum Chow</a> <li>kingsum@cs.washington.edu</MENU><li><b>Office Hours</b><MENU><li>Check the <!WA1><!WA1><a href="http://www.cs.washington.edu/education/courses/403/95w/sched.html">online schedule</a> for definitive information about office hours for the instructor and the TA. </MENU><li><b>Required Work</b> <MENU> <li> Participation in designing, building, and presenting a team project. <li> A midterm examination. <li> A final examination. </MENU><li><b>Readings</b><MENU><li> Brooks,<cite>The Mythical Man-Month [MMM]</cite>.<li> Ghezzi, Jazayeri, and Mandrioli [GJM], <cite>Fundamentals of Software Engineering</cite>. (You may use other similar books: see Notkin for details.)<li><b>There's also a lot in this and other handouts; I expect you to read them carefully.</b></MENU><li><b>Exams</b><menu><li>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.</menu><li><b>Grading</b><MENU><li> Your contribution to the project will account for about 75% of yourtotal grade. The midterm will account for about 10% of your grade,and the final will account for another 15%. Intangibles, such asclass participation, may affect your grade as well. Your projectgrade will be based on the quality of your work, not just on youreffort. You, not the project, will be graded; individuals in a groupgenerally receive different grades.<li>Final evaluation of the group projects is done by (1) a demonstrationof the project, (2) a group discussion of the project and the processof building it, and (3) separate discussions with each individualgroup member. This is a time-consuming process that will take placeon Tuesday March 14 and Wednesday March 15. Plan accordingly. </menu><li><b>Lectures</b><MENU><li>Most of the lectures will cover topics such as the software lifecycle,characteristics of large systems, software specification, softwaredesign techniques, development tools, testing, verification, andvalidation, maintenance, etc. As much as possible, lectures will becoordinated with associated stages of the project. There may be twoor three invited lecturers, giving their impression of softwareengineering, and of the problems with software engineering, at variouscompanies.<li>The following chart shows the tentative schedule for lectures, exams,etc. It is subject to frequent change.<pre> 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</pre></menu><li><b>Sections</b><menu><li>Sections will be used in a variety of ways, including group meetings(both among yourselves and also with the TA and/or me), presentationsby groups to other groups, etc.</menu><li><b>Project Requirements</b><menu><li>Large-scale software projects require teams of designers,implementors, and support staff. Because of this, the construction ofthese projects demands not only technical abilities but also skills ingroup dynamics. To give you some experience with these dynamics, youwill form groups of four to six people to specify the requirements of,design, and implement the assigned project (described below).<li>You must produce your system according to the schedule that will behanded out on Friday. The schedule includes several milestones, eachrepresented by a specific artifact. (As a preview, the draft of therequirements specification document, the first milestone, will be dueon Wednesday 18 January.) It is not necessary that every group memberbe involved in meeting each milestone. For instance, a person incharge of testing the complex system may not need to understand thelow-level implementation choices. However, you are required to stateexplicitly who has been involved in each milestone and in whatcapacity. I recommend strongly that each document be written by asingle person, with editing help from the others.<li>I will provide additional information, on a timely basis, about what Iexpect from each artifact; the document describing requirementsspecifications will be handed out on Wednesday. (I do not have a fullset of high-quality artifacts for a similar project. This would benice, but it is surprisingly difficult to acquire.) Sticking to theschedule for each artifact is essential, so that you can complete theentire project during the quarter. If for some reason the scheduledoes not meet the needs of your group, I will consider alternatives ifcareful, reasoned motivations are given. Don't plan on working onjust one milestone at a time; you must always have (at least) part ofyour team looking ahead towards milestones that are coming up.<li>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 tohelp your group make these decisions in an orderly manner. Feel freeto ask questions about what is expected. The TA and I will try toanswer these questions as if we were your customers (although withsome special knowledge about the constraints of a one- quartercourse).<li>Some other details include:<menu><li>Every team must select a name.<li>Every team must take and keep minutes at all of your meetings.The motivation for the minutes is that you may otherwise forgetdecisions 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 groupmembers. Bring an extra copy of these minutes every Tuesday duringsection; we'll scan these to see how your team is progressing and willkeep them for our records.<li>Every individual must keep a personal log. The logs will bechecked on occasion at sections. They are intended to help both youand us keep track of where your time is going. The log, which is notvery different from time sheets that many employers require you tocomplete, includes the date, the description of the activity, the timeit took, and some explanatory text. The following is a sample; youmay select different categories, but be consistent. As with theminutes, don't format these. You may find that keeping them in abound notebook is effective. Bring these to Tuesday sections; we'llalso want to have them turned in at the end of the quarter. Here isan example of a few entries from a personal log.<pre> 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</pre>Note that some of the entries are essentially instantaneous (formingyour group may or may note be like this) and need not have timesattached. Others are prescriptions for later things to do (eitherduring or even after the course). You may have categories later inthe course for group meetings, planning, editing, debugging, etc.<li>The development language you will use is either Ada or C++. In somecases, given a good motivation, I might grant permission for a groupto use an alternative language. But in no case will I permit a groupto use a language for which all group members who will be programmingdo not have expertise; there is too much to do this quarter to add onthe burden of learning another programming language.<li>Your group must communicate well. In addition to selecting amanagement structure, I recommend that you decide on firm times forgroup and subgroup meetings. You may wish to distinguish among statusupdates, brainstorming meetings, decision-making meetings, etc.<li>Your group may lose a member for various reasons. If this happens,you will be expected to close ranks and adjust to the problem. Losingpersonnel does happen in the real world and is another motivation forcarefully documenting each step along the project path.<li>Because software development is less predictable than is desirable,you should plan from the beginning for reasonable subsets of thesystem.<li>Computer resources always seem to be the most precious when they areneeded the most. The real world is no different from academia in thisrespect: machines are often loaded or unavailable at critical times.You have been warned.<li>People in projects make mistakes. They don't save their filesbefore a crash, or they inadvertently delete key directories. Becareful and try to develop managerial or technical approaches forreducing this kind of error. Similarly, you need approaches forhelping your group keep track of multiple versions of artifacts,including code.<li>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 drawcomplex figures using a computer if a quick sketch by hand issufficient. Don't debug by just permuting the statements in yourprogram.</menu></menu><li><b>Project Description</b><menu><li>Check the <!WA2><!WA2><a href="http://www.cs.washington.edu/education/courses/403/95w/project.html">Project Description</a> forinformation about this quarter's project.<li>Check the <!WA3><!WA3><a href="http://www.cs.washington.edu/education/courses/403/95w/project-sched.html">Project Schedule</a> forinformation about the project schedule.</menu></menu><pre></pre><hr><address>notkin@cs.washington.edu (Last Update: 1/6/95)</address></body></html> ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -