This Document Contains Appendix 1 to 2 APPENDIX I AN ANNOTATED PAPER DESCRIBING A TYPICAL SOFTWARE ENGINEERING COURSE In 1981, Elaine Kant (ACM Software Engineering Notes, August, 1981, vol. 6, no. 4, pp. 52-76) of Carnegie Mellon University published a detailed discussion of software engineering course design. Professor Kant gave me permission to include her paper in the Instructor's Manual for the first edition of SEPA and I have included it in every subsequent edition. Kant's paper is pragmatic and based on actual experience. Although it is now almost 30 years old, it remains one of the best discussions of software engineering course design that I have encountered. Undoubtedly, some of the concepts Kant notes must be updated for current technology and modern students, but the overall recommendations are as valid today as they were when the paper was originally written. The Kant paper is reproduced with permission and is presented in the following manner: 1. Reduced type font (i.e., reduced font) is used for all text reproduced directly from the Kant paper. 2. Bold sans serif type font is used to include my comments and supplementary notes. You should note that parts of the Kant paper are direct extracts of student handouts and are therefore addressed directly to the student. Notes to the instructor (which do not appear in the actual handouts) are denoted with boldface font. 4.1 A SEMESTER COURSE IN SOFTWARE ENGINEERING Elaine Kant, Carnegie-Mellon University 1. Introduction Software engineering is a difficult subject to teach. The field is not a rigorous one, and there are few good textbooks [RSP note: hopefully, SEPA remedies this problem] or model courses to follow. To add to the confusion, the course is taught at many different levels to students with widely varying backgrounds. This paper discusses a project-oriented software engineering course aimed primarily at sophomores and juniors with at least two previous computer courses. Readings, suggested projects, and assignment descriptions are included.… The rest of this paper is a modification (what it should have been, rather than exactly what it was) of the handout given to the students on the most recent version of the class. It introduces the schedule of lectures and assignments for the project documentation. Comments for instructors are noted in boldface type. RSP: Although Professor Kant indicates that the course has been designed for and taught to an undergraduate audience, there appears to be no reason why the same presentation (with added work and a bit more rigor) cannot be offered in a graduate curriculum. 2. Course Organization This handout describes the course Software Engineering Methods. It explains the organization of the course, outlines the lecture topics and project assignment due dates, and gives some hints about working in groups and writing up the project documents. Finally, some suggested projects are given, and all of the assignments related to the project are described in detail. 2.1 Course Overview Software engineering is concerned with long-term, large scale programming projects. This course introduces the topic through lectures and by giving you a chance to help design, manage, and implement a medium-sized project. The lectures and the group project will cover topics in software engineering management, problem specification and analysis, system design techniques, documentation, system testing and performance evaluation, system maintenance, reliable software, current programming and run-time environments, and possibilities for the future. The course will be difficult and time consuming, so you must have satisfied the prerequisites listed below. 2.2 Prerequisites The prerequisite courses at CMU use covered basic data structures (including a number of implementations for lists and sets), recursion, data abstraction, formal specification and verification, and finite state machine models. Prerequisites should probably also include a data structures course and an algorithms course and previous experience in writing small packages. I strongly recommend giving a pretest during the first week in class to make sure students have sufficient programming abilities. I gave out a questionnaire on programming background to help us spot potential strengths and weaknesses, but I had to take some of the answers with a grain of salt. For example, some students claimed to have written 106 lines of code! Homework Most homework will be related to the course project described below. There will also be reading assignments and occasional other exercises. There is an assignment writeup for each step of the project that includes a reading assignment. The readings should be done before you do the assignment. You are encouraged to read ahead as much as possible. Another course requirement is a weekly log of how much time you have spent on different activities related to the course. A sample log sheet is attached. You should turn in your log sheet each week at your section meeting. The students generally do not like keeping logs. Although the logs gave me valuable feedback the first time I taught the course and although I think the students who kept them carefully learned from the experience, I'm not sure I believe they are critical. Perhaps they could be optional for extra credit. Group Project The class will be divided into groups of people. Students are strongly encouraged to form their own groups of compatible people. Projects normally will be selected from the list of suggested topics and be written in Pascal, but other projects can be negotiated. Each group will have regular weekly meetings with a "consultant" ( a graduate student or member of the research staff) from the Computer Science Department. The projects will take most of the semester with major write-ups due at approximately two week intervals. There will also be some oral presentations, including a final demonstration of the project. Sample documents from the last course are on reserve in the library. Five-person groups were chosen partly because of the large size of the class and partly to force students to face issues of project management. Smaller groups would probably cause fewer problems but would teach fewer lessons about programming in groups. The last time I taught the class I scheduled two hours of lectures and made the section meeting the third class hour. It is important to impress on the students that these meetings are required and that they are if anything more important than the large lectures. Of course the success of this approach depends on having good teaching assistants, which I have been very fortunate to have. RSP: Although allowing students to make-up their own teams ("groups") has definite advantages from the compatibility standpoint, it might be worthwhile to define teams based on the overall performance of individual students. If you take no part in defining the make-up of the teams, it is likely that you'll get one team of superstars and other teams with less capable performers. Distributing the superstars among various teams benefits everyone. Tests and Individual Projects There will be an in-class mid-term exam. Rather than a final, individual programming projects will be required during the last several weeks of class. The project will involve a modification or extension to a group project on a topic in software engineering. I would suggest giving a final or second in-class test to make students read the second half of the textbook. There usually isn't much time for individual projects; if you want students to take them seriously you must make it clear to them that they are important. Grades About 50% of your grade will be based on the group project documents and demonstration. You are graded on the quality of the work you produce, not on how many hours a week you spend. Use your energy wisely! The rest of the grade will depend on individual tests, projects, and contributions to the group projects. It is very important that project assignments be turned in promptly, both to allow you time to complete the entire project on schedule and to allow us time to evaluate your work and make suggestions. I strongly recommend insisting that the new students stick to a strict schedule. Groups that get more than a few days behind usually stay behind and never catch up. If a group is just lazy, insist that they turn things in on time and lower their grade if they don't; if their project is harder than it appeared at first, give them an extra week to figure out how to simplify it, but then insist that they stay on schedule. Also, make it very clear from the beginning that grades are not assigned in proportion to the number of hours spent or you will get a lot of complaints. Assigning individual grades in a projects course is difficult. I suggest stating exactly how much documentation and how many lines of debugged code, not counting comments and write-in statements, you expect from each person for an A, and what the grade penalties are for lateness and poor or incomplete documents. A reasonable breakdown for the grade might be 35% on whatever the group project as a whole deserves, 35% on the student's contributions to the project, and 30% on tests and individual projects. It is important to identify people who try to do their share as early as possible and convince them to shape up or drop the course, but this is difficult in practice. RSP: I have found that the following method works well on team projects: A team leader is elected by the team within one week of the start of the project. (Kant discusses the leadership question later and I will make further comments at that time.) At monthly intervals, each member of the team submits a confidential rating sheet for all other members to the Professor. The grades submitted by the team leader receive extra weight. Poor individual performance is relatively easy to spot and a conference with offenders can be arranged if serious deficiencies are being reported. Comments from previous students . . . Warn people ahead of time what to expect... a lot of work is involved and anyone that doesn't have the time or perseverance should drop the course. This has been the most worthwhile course I have taken since I learned to write in first grade.....I've learned a lot about computing, time management, people management, and my ability to stay logged in for days at a time. I even liked the course. There is only one major problem. My QPA is dropping faster than a wingless airplane because I've spent my semester working on 311. CHORUS: This course is too much work!!!! The course really was too much work for the number of units given. Textbooks RSP: For undergraduate courses, the only required textbook for my course was SEPA. However, like Professor Kant, I put a good selection of related texts on reserve at the library. It would also be worthwhile for you to review the References and Further Readings and Information Sources sections at the end of each SEPA chapter. Of course, the Web provides a vast library of sources. Kant's required and recommended texts are dated and have not been reproduced. As an alternative to supplementary textbooks (which students tend not to use), emphasize the Software Engineering Resources section of the SEPA Web site and encourage students to visit the Web sites noted. Keeping a Log Each person is to maintain a log of the time spent on course work and to break down the total time into categories. For example, categories might include time spent reading textbooks or articles, reading project problem descriptions, devising specifications, testing your program, etc. Some of the numbers that students give seem a bit inflated, but in general they do spend an impressive amount of time on the course. Unfortunately a lot of time is wasted when the machine is heavily loaded. We hope these logs will help you see how you spend your time and help you to make better predictions of the time needed by the different phases of a software project. Many companies in "the real world" actually require this sort of time-keeping. RSP: The idea of a log is a good one. To help the students keep the log and to establish a consistent format for data collection, it might not be a bad idea to establish a Web site in which each student can build her or his own log. When in doubt, use as many categories as occur to you. You may want to compute the time breakdown in several ways for later summaries; for example, total computer time, or total time spent on the testing phase. You may want to make a special category for the time you spend in the computer center when you aren't really working on your project. When you make computer runs, record the reason for the run, the changes since the last run, and the result of the run. I think you will find this interesting to look back on and see how your time was spent and how it compares with your predicted times. Comments from Previous Students KEEP THE LOG SHEET. It may be a pain, but I wish I would have kept mine. It would be interesting to look back on it now and see how much time I really spent on the project in front of a terminal and how much I spent away from it. 3. Lecture Schedule RSP: The schedule proposed by Kant assumes two lecture periods and a project session. When I was teaching, we met once a week for a 2.5 hour lecture and allowed students to schedule their own outside meetings. Frankly, I like the CMU approach better. Unfortunately, not all institutions have the resources (grad assistants, support faculty, etc.) to properly pull it off. I believe that the schedule of topics proposed by Professor Kant could be improved somewhat. Alternative schedules are proposed in section 4.2 of this Instructor's Manual segment. Week 1 Lecture: course overview, background questionnaire, possible pretest Lecture: working in groups, management structures Section: no meeting; students should be picking groups and projects Week 2 Lecture: software requirements analysis, functional specifications Lecture: Paradigms, common system organizations Section: no meeting, but project/group proposals due Week 3 Lecture: user interfaces, error/exception handling Lecture: technical writing Section: draft of functional specification due Week 4 Lecture: abstraction in design Lecture: modularity in design Section: functional specification due Week 5 Lecture: more on modules and abstraction Lecture: more on modules and abstraction; families of systems Section: top level code, overall design draft due Week 6 Lecture: using libraries, journals, and references on algorithms Lecture: checking interfaces, separate compilation Section: overall design specification due Week 7 Lecture: reliability Lecture: midterm exam Section: interface definitions and stubs due Week 8 Lecture: testing -- integration order, estimation, and scheduling Lecture: testing -- individual module testing, test drivers Section: detailed design specifications due, compiled module drivers due Week 9 Lecture: discuss midterm, group interactions Lecture: programming tools and environments for Pascal Section: module top level code due Week 10 Lecture: programming style, hints, and tricks Lecture: more programming hints Section: draft of test plan due Week 11 Lecture: performance evaluation Lecture: advances in programming environments (good debuggers, version control, syntactic editors Section: test plan due, trade undebugged code Week 12 Lecture: automated tools, program synthesis Lecture: structure of organizations in the real world, types of jobs Section: user manual due Week 13 Lecture: computers and law Lecture: computers and law Section: practice demo Week 14 Lecture: personal computers, networking Lecture: project demonstrations Week 15 Project demonstrations Final evaluation and individual projects due 4. Working in Groups The students seem to feel that the groups won't be a problem in most cases, or don't want to face the issue early enough even if they have suspicions that there are problems in their group. I strongly recommend being very aware of group dynamics in the first few weeks of class. I will let the student experiences speak for themselves for the most part. Most students prefer a democratic group organization. In a minority of groups, those in which all students have a reasonably equal commitment to the course, this can in fact work, as the following comments indicate: . . . As a group, we did manage to work well without any strict leadership structure, partly because everyone was kept pretty well informed as to the work that was due. Also, everyone participated in the writing of all papers, no one person was dumped on. We each were given a section that was later critiqued and made a part of the total paper. I think that most groups would probably need some sort of structured management, but because of our group members' personalities, we worked well without any .... . . . Our group worked together very well with no formal division of management. As in any society, there are leaders and there are followers. It seems that we had a good mix between leaders and followers. However, most groups find they need some sort of leader; either because they all try to do everything and waste a lot of time arguing over details or because some people don't know what they should do unless someone gives them fairly explicit assignments. Some groups may want to have a design leader who is responsible for final technical decisions and a manager who is responsible for making sure everyone comes to meeting and does their share of the work. You may wish to have a permanent leader or to rotate leaders at different stages of the project (such as letting the editor for a document be the manager for that part of the project) Additional student comments follow: . . . Unfortunately none of us had worked on a software team before. We were foolish and thought we could use the 5 - pointed star managerless technique where everyone talked to everyone and each did his equal share of each assignment. We realized pretty late in the game that this would not work ... any project group must have a leader or manager. The sooner the group realizes this the better off they'll be ... As few people as possible should write a particular document. One person (definitely not the author) should edit the entire document. . . . The design process should, in my opinion, have a single person in charge of both the design and the paper. He should have final say in major disputes that seem to be unresolvable by any other course ... As many of the design decisions should be delegated as can be done reasonably... he must take care to limit the discussion of relatively minor points in order to keep the meetings from getting extremely long. Finally, let me say something about communication. In a word, you can't have enough. While it is to be expected that some members of your group will be better writers, some better programmers, and so on, you are not to divide the labor on these grounds alone. This class is to be a learning experience, and each of you should get a substantial amount of practice in all of these areas, not just the ones you are already good at. Each person must write some of the documents, must edit one (see the next section), and must write code. You are not to turn one person into a full time typist and help - module writer just because you don't think their code will be perfect. If one group member is a fantastic writer, by all means let him edit the first document and help teach the others how to write better. He might be assistant editor for some of the other documents, but he is not to write them all. If another member is a "wizard", go ahead and have her be design manager, but she is not to develop the software for the whole system, rather she should help the others improve their design and programming skills. One problem that the students who were nominal leaders pointed out was that they had no power to back up the responsibilities that went with their authority. I don't have any good answers to this, except possibly to point out that the professor might believe this person's opinions about how much the other group members are contributing to the project. Another alternative is to get the TA to be a manager. To some extent this happened informally anyway, but I suspect it would require much more of a time commitment for them to take a formal leadership role. RSP: The team approach to course projects is, as Professor Kant indicates, a difficult one to resolve. The following scheme tends to eliminate some, but not all, of the problems associated with "no-work team members" and a need for leadership authority: 1. A team leader is elected by the team. 2. Because the leader has more responsibility, she/he should receive rewards for good technical management and "take some of the flack" for a poor showing. 3. Given the philosophy indicated in (2), the team leader will receive 1.10 of the overall team grade, if that grade is above 75% and no reward if the grade is below 75%. 4. At monthly intervals, each member of the team submits a confidential rating sheet for other members. Comments of the team leader are weighted heavily in a final assessment. 5. At the end of the project, a "bonus pool of points" (usually some percentage of the final grade) is distributed to team members based on the cumulative ratings. This scheme tends to keep everyone actively involved in the project and provides the team leader with a "club" for those members who are not contributing. 5. General Comments on Documentation This course involves a lot of writing. You are not being graded directly on your writing style, but good writing usually conveys ideas more clearly than poor writing, and the process of writing down your thoughts often clarifies them. Thus it is to your advantage to make the effort to organize your thoughts and write well, and we will often make comments about your style as well as about the project you are describing. At the beginning of the semester you should skim all of the the assignments, then reread each several times before you begin to work on it. If you still have questions about the assignment after reading it carefully, be sure to ask your TA or the instructor. You are to turn in two copies of each final document. One will be read by your TA and the instructor and will be returned to you with comments and a grade; the other will be kept in our files for future reference. Drafts of documents will only be read by your TA who will give comments but not a grade; you only need to turn in one copy for this. Each document is to have one (not five!) editors, and each group member must edit one of the documents. Let us be very clear about what it means to edit a document. The editor has the final responsibility for turning in the document, sets deadlines for what the other members are to write, and may have to apply pressure to the other group members to do their part unless you have another manager for this. To make things easier for you, we suggest you decide on a standard format (especially for the design documents). You may use the outline in the class directory as a model. Most of the assignments suggest an organization for the document. You do not need to follow it exactly if you have a better idea, but you should be sure to cover all the same material. Be sure to include acknowledgements at the end that say who wrote which sections and who the editor was. I made up some grade sheets as guidelines for what to look for in evaluating the documents, but mostly they just reiterated the points made in the assignments, and I don't think it is worth reproducing them here. RSP: The above material presents a good set of guidelines for students. I suggest that you require your students to follow predefined document outlines (See Document/Work Product Outlines at the SEPA Web site). First, this drives home the need for standardization in software engineering and second, it makes the task of reviewing and grading the documents much simpler. You should save the best work from year to year so that over time, a sample "software configuration" can be provided as a guide for new students. I have found that outlines, in and of themselves, provide the students with inadequate guidance. Sample documents do a much better job. The Case Study presented at the SEPA website can also be used to help students by example. 6. Project Suggestions Due Dates Week 2: Turn in a description of the project you have chosen, one page minimum, five page maximum. Include a name for your group, a list of the names of the members, and a list of possible meeting times for your group. Include evening times; some TAs prefer them. General Comments Each group should select a project from the list given below; other project ideas may be used if approved by the teaching staff. A project should be feasible given the time constraints, but large enough that a cooperative team effort is required to complete it. Read the functional specification assignment and some of the others to get an idea of what will be expected of you. Note that you are asked to propose four increasingly difficult versions of your system. The first should be something you are sure you can do, and the last something you think you probably won't have time to finish. You should try to select a project that spans that range for your group. After a group proposes a project, a teaching assistant should be assigned, and the TA and the instructor should give the group a critique of the proposal. Is it too ambitious or not enough? Are the goals clear? Can it be expanded or reduced later if necessary? Will it be possible to split it into smaller modules? The instructor should decide on the dates for each group's final demonstration fairly early in the semester so the group has a definite date to work towards. Suggested Projects [an abbreviated list is presented here] A registrar's program to manage registration and scheduling, including printing student registration status, class lists for instructors, room use sheets, and process add-drop cards. A program to teach arithmetic to a little brother or sister (i.e., a program for computer-aided instruction). This could include a scoring system, for example, and perhaps some analysis of errors to determine what kinds of problems to concentrate on. This is not a well-defined project and the group must be careful to decide what is to be handled. A system to perform differentiation and simplification on symbolic expressions. Warning - simplification is quite tricky. I recommend encouraging groups to use existing algorithms first and then augment their programs. One group attempted this project and did a reasonable job with a pretty printing expression display and with function definitions but got bogged down on simplification. They had a hard time believing that simplification is in the eye of the beholder and the next step of the problem solving. A database system, perhaps to maintain SCRIBE bibliography databases. This would make it convenient to add new entries to the database, along with key words, and also allow searching of the database, either by key word or by other fields, or with a special query language. Keep the on-line database alphabetized. A database system for maintaining voting records of Federal and/or State Senators and Representatives. The system should keep all districts and their current representative along with their party, data of election, and a set of user-determined votes. There should be a way to score votes; for example, to determine how a person rates on a set of issues about the environment or the ERA or the space program. In the congressional record, votes recorded include yes, no, did not vote, paired for/against, unknown, etc. The user should be able to specify how these correspond to 1 or 0 or whatever for computing scores. There should be various ways to print out this information (again, perhaps with a query language), deal with people winning and losing elections, resigning, dying, etc. A prototype simulation of a small, low-cost computing engine that one might find for sale in stores to the average consumer in the foreseeable future. It could be for children or adults; it might perform a common routine task now performed manually, or it might be a game. The Texas Instruments "Speak-and-Spell" ~(a registered trademark of Texas Instruments~) game would be one example. A modest version of a game of Adventure or Dungeons and Dragons. The computer would serve as the dungeon-master. Alternatively, a game where the computer is a competitor or the board manager for a group of people. Depending on the game, an attractive display may be an important part of the project. Parker Brothers' "Clue" is an interesting game: you have to keep track of what other players know as well as what you know. Other possibilities are mastermind, checkers, bridge, backgammon, chess, and Go. Keep in mind that writing the programs to handle these games may not be nearly as fun or easy as playing them; certain of last year's students have threatened murder if anyone mentions the Rivets game to them again. Mastermind is perhaps too simple a project, checkers is a bit more complex but still pretty straightforward if existing approaches are used, and adventure games can be made reasonably difficult. An on-line recipe file and meal planner. This could compute the overall nutrition value of a meal, summarize the necessary ingredients, and estimate cost. It might also be able to suggest a meal given "I want to use up this ground beef" or "I'm out of eggs and lettuce." A teacher's program to detect similarities in programs (i.e., a "cheat detector"), for programs of about the size and complexity required for week long homework assignments. A program version comparator and updater. This is like the previous suggestion, but the emphasis is on determining differences rather than similarities. One might use this system after a day's editing, to get a summary of all changes. Suppose that two people edit the same program, adding different fancy features. This system might determine the differences between them and automatically or (more likely) interactively merge them to produce a new program with the features of both. An automated bank teller. This would keep track of accounts, and let users perform various transactions: shuffle money between accounts, make deposits and withdrawals, pay bills (manually or automatically), include a display similar to the ones at the real money machines, etc. The system should be resistant to abuse and should be reliable (able to keep everyone's money straight in spite of system crashes). This is a simple project unless it includes features like multiple tellers and simultaneous deposits and withdrawals, bank manager programs, and good backup systems. A string handling package. This would provide dynamic allocation of variable-length character strings, with either explicit or automatic de-allocation. In addition to managing storage, the package should include facilities for operating on strings (copying, concatenating, comparing, sorting, searching, matching, etc.). This project is straightforward but can involve a lot of work, especially if fancy pattern matching is attempted. One group did a nice job on a moderately sized string package. A complex string-matching package, expanded into a spelling and diction checker. (The string matching might be based on regular expressions a la Aho). It could check a document for commonly misspelled words, as well as instances of such redundant fragments as "-ing behavior", "added increment", and so on. A personal finances manager. Something to balance the checking account, keep track of bills, match receipts to credit card statements, do taxes, provide summary reports in various categories, and so on. One group did a modest version of this. A calendar maintainer. This would schedule your time, send reminders when necessary (through the computer mail system), perhaps coordinate with other people's calendars for scheduling meetings, and so on. Printing parts of the calendar on demand is a must ("What's up for today?" or "Let's see next week at a glance." or "What in the world was I doing last Tuesday?" or "On what day of the week for the next four weeks is there an hour free starting at 10:00?"). A verification condition generator. A tree (or graph) structured bulletin-board system, with the root allowed in any user's directory. Any user could post notices for others to read. Notices (especially replies) could be associated with other notices (hence the graph structure). A user might want to ask such questions as "which notices of mine have had answers attached that I haven't read yet?" Some branches of such a bulletin board might serve as a structured on-line documentation system. This would have to have a nice user interface; it should also lead the beginner by the hand (possibly by guiding them through a documentation tree!) A stripped-down version of the user interface for hard-copy terminals should be a part of the core system. One group tried a similar project but was overly ambitious and had trouble completing the project. Write a program for analyzing the NFL playoff situation, which has a complex set of rules for resolving various situations that can arise. One portion of the project would be an evaluator to determine the playoff choices given the end-of-season scenario. The rules should be modularly implemented so that they can be changed (as they frequently are). The user interface could vary from something simple to a system capable of answering questions like "If Pittsburgh loses to Houston, what must occur for Pittsburgh to enter the playoffs?" (expressed in some more formal notation). Incremental improvements might include something like the capability to guess, based on the season record so far, how some upcoming games might be decided or what games might be crucial. Other possibilities are limited only by your imagination. While projects such as display and window packages, command interpreters, and general menu handling systems would be quite feasible, some projects such as a poem or music composer or simple language translator or simple theorem prover boarder on research topics and you will have to be very careful not to waste all your time fighting about what you are going to do or which of the many possible approaches you will take. We want you to have a chance to complete a project, not just start one. RSP: Some of the projects noted above are somewhat frivolous, but all will serve to demonstrate software engineering methodology. It is often worthwhile to poll various departments at your institution for small, but "real," projects that students might attempt. If you do this, your students will get to communicate with real customers and the results of their work may have lasting benefit. Be careful here, however, there is a tendency to bite off more than your students can chew! Another project approach for a software engineering course is to have students develop a "Tiny Tool" for inclusion at the SEPA website. A wish list for Tiny Tools and instructions on how to submit such tools for evaluation is provided at the SEPA website. The difficulty of each of the above projects can be tuned to the sophistication of the students and the number of people on a team. For many of these, the students will have to "learn ahead" for topics that are not discussed until late in the course. First Reading Assignment SEPA assignment: See alternative course outline presented in section 4.2 of the Instructor's Manual. 7. Functional Specification Assignment Due Dates Week 3 draft of the paper described here; week 4 final version of paper, hand in two copies, one returned with comments, one for our files. General comments on the assignment It is very important for the students to make definite commitments about what their project will involve. Insist on a draft and make them rewrite the final version if necessary. Points to stress are: coming up with realistic versions of the system for the "plain and fancy" section; writing samples of the system behavior, and making sure the functional specification is a very good first step towards the user manual. The main purpose of the Functional Specification is to explain what you are going to do for your project as opposed to how you will accomplish these goals. The functional specification, coupled with a management plan (which we will not write up formally) and an overall design (which will be your next assignment), describe the proposal to your client. When accepted, these documents are a contract between you and your client (the teaching staff) about what you intend to deliver. Changes can be negotiated later and should be recorded as an appendix to this document. When writing this paper, therefore, you should keep in mind that your audience will be a client (who, in general, is not an expert in computer science) and your group members, who will want to refer back to this document periodically to be reminded of what they are supposed to be doing. The fact is that in this course your clients are computer scientists and that your document will be graded might encourage you to think and write as carefully as possible. RSP: It is important to have each team develop an abbreviated Software Plan for the project they undertake. The plan should emphasize scheduling, in fact, you should insist that each team develop a week by week schedule and encourage them to schedule on a daily basis for 7 to 10 days in advance. It is critically important to have the students assign responsibilities within the team. If possible, it would be nice to provide the students with a scheduling tool (e.g., MS Project) that will make this effort a bit easier. Cost estimation is not nearly as important in this context, but you can provide data for LOC costing and suggest the use of an empirical model such as COCOMO to help in estimating. Discuss what you want your system to look like and produce as many examples as possible of its behavior. In your group meetings you can take turns playing different roles. One person could be the system user, one could play the system, one could be system implementer and make sure the "system" is feasible, one could be the group facilitator. Contents of a Functional Specification Title Page This assignment, as well as all others throughout the year, should be turned in with a title cover or cover page that includes the following information: - A title that identifies the document - The name of your group (such as "Great Hacks, Inc.") - The people who contributed to this document - Course name, instructor's name, TA's name, date Functional Summary In about 2 pages, you should briefly summarize the project you are working on. Give your system a name. Describe what it does and who will use it. What needs will your system satisfy? How will it help the users? Outline the most important features of your system. Describe the physical environment in which your system will be used, including any other systems with which the new system will interface. Are there any important performance goals for your system: time or space efficiency, security, or reliability? Details concerning system user interactions The main point of this section (which should be approximately ten pages) is to describe the functions that the system will perform from the point of view of the system user. You need to cover the kinds of inputs your system expects, the actions it will take on both expected and unexpected inputs, and the types of outputs that the user will see in those cases. Part of this section will eventually be developed into a user manual. First we'll consider the content, then the form, of these descriptions. The inputs, state changes, and outputs should be described in reasonable detail. You need not stick to the exact wording of messages, but you should make definite statements. You can negotiate major changes later. Describe what legal values or ranges your system will accept for inputs, what precision or accuracy constraints you will follow, and how you will handle errors. Your functional description should employ some of the following techniques: Sample transcript . A very important part of the description is a sample interaction with the system in the form of a transcript of a dialogue between a user and the system. Use upper and lower case or some similar convention to distinguish between what the program types and what the user types. Students resist doing this, but I would insist that they produce a number of examples. RSP: I had each team develop a "paper prototype" of the system that they are to build. This is particularly useful for graphics applications but has benefits for all types of projects. One way to overcome students' resistance is to convince them that the prototype will be a useful artifact if disaster strikes and they can't get their application "up and running FSM model . If your system can be thought of as being in a number of states, you can draw a finite state machine model (FSM). The different states might correspond to different prompts for user response that are shown in your dialogue. BNF specification . If much of your system involves commands specified by the user, write a BNF describing the syntax of these commands. Boxes, arrows, and tables . As appropriate, use pictures of equipment, data flow or control flow diagrams, decision tables, etc. Be sure that any diagrams are captioned and that there is a key explaining what various boxes and arrows mean. Glossaries . Be sure that all specialized terms are defined in the body of the document or in a collection at the end. This could include computer science terms that you wouldn't expect your client to know or application terms (from accounting, geology, or whatever) that programmers working on the project might not understand. Feasibility Make sure your project has a chance of being completed in a semester. What are your preliminary thoughts on how you will break down the different features of the project? What are the major classes of functions and the relationships between them? Think a little about your main data structures and algorithms, and spend a page or so discussing possible implementations. Don't waste a lot of time fighting over details, but be sure to ask your TA or the instructor if you aren't sure how hard something will be. Our system, plain and fancy Predicting how much can really be accomplished in a finite period of time is often tricky. It is important to decide what a bare bones version of your dream would involve. Describe, in one or two pages, the composite of your skeletal system. What functions will not be included, and why? Cover yourself by making sure that reading between the lines doesn't make your customer think that more is being promised than you plan to deliver. Now sketch out which features will be added as time permits. Try to organize the bells and whistles into packages that could be added independently or in some predictable order. Also think about the order in which parts of the system can be dropped so that you can retreat gracefully if necessary. (You may wish to look ahead at the Parnas readings listed in the design document handout to find out more about subsetting.) A good way to describe your series of systems is in the form of user reference cards. You should make a series of three or four cards outlining what is contained in (or added by): - a kernel system with absolutely minimal features (that you are positive you can finish in 3/4 of a semester) - a cheap but usable system (that you expect to finish) - a standard system (that you have a good chance finishing) - a super system (that you probably won't be able to finish but would like to; don't make this something impossible though) Summary Don't drop the reader off a cliff at the end of your paper. It's been a long time since the beginning of the paper. Restate the main points you want remembered. Acknowledgements Write down the authors of individual sections, the editor of the whole paper, outside consultants, etc. (Do this for all future papers as well.) This will help people figure out who to ask for more details. RSP: I try to emphasize to the students that all documentation should stand on its own—that is, they should not assume that "We'll be around to answer any questions, so we can be sloppy about ambiguity, etc." Optional Sections A real functional specification would include a number of items that you may wish to skip at this point. Some of them require more experience to predict and may be covered later, some are not relevant to all projects, and some have already been discussed. Use your good judgement. - Make some general statements about the performance goals for your system. What are your goals for system run time, main and disk memory use? What kind of reliability will you guarantee? Security of information? What kind of performance trade-offs have you decided to make? - Can you say anything about compatibility with existing software or hardware? What about an installation agreement? Maintenance contract? - What resources are to be committed to the project? Who are the people on the project? Their skills and background? What is the promised delivery date? How much computer time and space will be used to develop the project? - What publications will be produced? Who are the intended audiences? Readings SEPA assignment: See alternative course outline presented in section 4.2 of the Instructor's Manual. Some comments by previous students . . . Writing down the functional specifications is fundamental to having a good start on a well-designed project. No matter how much you discuss something there will be loose ends and not until you write your ideas down will these unresolved parts become visible. The most important sections of the paper are those dealing with the functions of the system. You need to understand thoroughly "the transformations from the user point of view." You should not have vague points unless you absolutely cannot help it. . . . In some respects the Functional Specification was the most useful of the documents. It forced the group to adopt a rigid management structure (we quickly found that five people writing the document causes tremendous amounts of bickering) and outlined the goals of the project. It also provided a first look at the more serious problem which the project would have to overcome. 8. Design Documents Due dates Week 5. bring in top-level code and design draft; divide responsibilities for overall design sections Week 6. overall design specifications due (2 copies) (preliminary grade) reapportion responsibilities, group review Week 7. interface definitions and stubs due (preliminary grade) Week 8. detailed design specifications due (2 copies) major grade) module drivers for kernel system due (compiled but not tested) reapportion and review remaining tasks in section The design process The design of large systems is still a bit of an art. To put a little order into the chaos, we've established a few milestones for you. During the design process you should focus on the parts of the design essential to producing a core system and merely outline extensions to a more complete system. One of your major goals is to get something working by your deadline, even if it isn't the full system. Thus, you should determine what needs to go into a skeletal system and schedule the design of those components first. The end goal in the design process is a detailed design document that is complete enough to be a reference from which any competent [software engineer] computer scientist can produce code, test plans, or a user manual. (This document should eventually evolve into the code and system maintainers' guide.) An intermediate goal is the overall design specification. This can be considered a draft of the detailed design document with some of the details missing. Interfaces between modules should be clearly defined. Once the design has been written down, everyone in the group should read the entire document to make sure they understand the design. Individuals should be assigned responsibility for particular modules and should design these in more detail. Each person should carefully review at least one other person's section (and all sections should be reviewed by someone other than the author). Pick the one(s) with which your module has the strongest interaction(s). Based on the examination on the module interactions, you should prepare a set of interface definitions. The final step is then to prepare the detailed design document. Most of the work will be done by individuals filling in the details of their modules, but you must review the document as a whole to make sure people are using the same interface definitions and to make sure that everything has been covered and that the parts of the document hang together. RSP: SEPA introduces a review technique that can be applied by the students during design. You should encourage the use of walkthroughs. Be sure that students apply a formal (data flow, data structure or object-oriented) design technique. A preliminary design "review"—a 15 minute in class design presentation by each team—is recommended during the early weeks of design. Writing the documents First of all, remember Brook's comment (The Mythical Man-Month, page 165 Most documentation fails in giving too little overview. The trees are described, the bark and leaves are commented, but there is no map of the forest. To write a useful prose description, stand way back and come in slowly. Your goal should be to provide a recursive (top down) description of your program in a form something like the following. You probably won't be able to design your project completely top down, but such a description should be a good explanatory and reference tool. For each level, you should cover the following: Abstract—What services does this program, module, routine, etc. provide to outsiders? Implementation Documentation—Are any special instructions need for the system user; for the writer of other modules? Design—What is the basic design of this module or routine? How are the design decisions reflected in the submodules or routines which make up the whole? How are the pieces combined to accomplish the main function described in the abstract? Exports—What routines does this (sub)module make available to other modules? What type declarations? What constants? (Remember, types can be exported, but not parameters.) Imports—What procedures defined in other modules are used? (Beware: a procedure, function, or type cannot be both an import and an export of the same module!). Input/output—Make sure all necessary actions are specified. Subparts—What are the names of the submodules, routines, and/or data abstractions that make up the module or submodule? Pre and Post conditions—What are the pre and post conditions on the main routines in your module? What are the important invariants on your data structures? Error Handling—What is the range of legal values? What happens when other values are found? Test Cases -- List all your fiendish ideas for cases that might break the system or module or routine. If you do a good job here, you will be more sure of having a good design and most of your test plan will be already written. Concrete Implementation—For (sub)modules that are data abstractions, give the concrete representation (Pascal declaration) here; the access functions will be listed as subparts. For routines, this is where the code goes. Make clear what data structures are private to the module. Define any technical terms relevant to the module. Side Effects—Hopefully there aren't any, but if there are, you'd better make them explicit. Miscellaneous—Just in case you think of anything else (for example, an estimate of how frequently various routines might be used or how much code will have to be written), throw it in! Obviously, not all categories are needed at all levels. For access routines, for example all that is needed maybe a good function declaration. (Also, please don't call all of your procedures modules!) Where appropriate, write your description in Pascal or in a formal high-level language. RSP: In the above discussion, Kant uses terminology that is specific to her course. Refer to the SEPA Web Site for a discussion of recommended design document format. I would recommend against using the above section verbatim (as a handout) in that conflicting terms may cause some confusion. Comments from previous students . . . The specifications were extremely helpful when designing the code. Our specifications were detailed enough that attempting to write a piece of code for a module could almost be taken directly out off of the specifications. Writing the design specifications twice helped us a great deal. Many things were pointed out to us that needed improvement, and the second set of specifications gave us time to think things out a little longer. . . . Every time I violated the principles of abstract design, I suffered. Abstract data types, modular decomposition, and information hiding can really work. The design process was definitely a major factor in simplifying the debugging process. It is interesting to note that we had almost no interface errors. We attribute this to good communication within the group. 9. Testing Plans Assignment Due Dates Week 9. top level code for main modules, tested with drives and stubs, due Week 10. test plan document due Overview About this time students often start to fall behind or decide that the test plan isn't important. All I can suggest is making sure they stay on time beforehand or having them write test schedules as part of the design document. Testing is an important part of a software project. The software team must therefore carefully plan and document the order in which modules are to be integrated and the order in which the individual modules are to be completed and tested in isolation. Testing and debugging methods must also be agreed upon, documented, and eventually carried out. The grade you get on the test plan is tentative; a final grade will be assigned after you complete the testing process. The purpose of a test plan document is to convince the management (in this case, the teaching staff) that a feasible test plan has been designed and also to provide the project members with directions for the testing phase of the project. This assignment outlines some constraints on the test plans. Several stages of tests must be scheduled, and several testing procedures must be explored. Scheduling is required for unit tests, integration testing, functional testing, performance evaluation, and an acceptance test (the demonstration). These tests must include practice in the techniques of walkthroughs, extensive logic testing, input/output testing, and optionally verification. The following sections give details of the contents and style of the test plan document, and the final section lists some reading material that should help you design a better test plan. Design the test plan The test and evaluation plan should contain the following components: statements of objectives and success criteria, integration plan, testing and evaluation methodologies, and responsibilities and schedules. These components are described in more detail below. 1. Objectives and Success Criteria: The test plan document should contain a statement of the overall testing objectives and the objectives of the individual tests that are planned. 2. Integration Plan: An important decision to be made about testing is the order in which modules are to be combined and therefore the order in which they will be tested individually. You must plan for individual module tests, the combination of modules during integration testing, a functional test, and an acceptance test (the demo). The test plan document should describe and defend your integration method. The "big bang" method of integration is not acceptable, but many variants or combinations of top down and bottom up integration are acceptable if convincingly defended. 3. Testing Methodologies: You should design a plan to test all of the modules of your system. Your test plan document should name at least one module to which each [testing] technique is to be applied; you may decide the testing technique for the other modules later on. Each person on the software team is to perform at least one set of tests and turn in a couple of pages describing the process at a later date. 4. Responsibilities and Schedules: The test plan should provide a schedule describing dates and responsibilities. - First, determine an order in which to perform integration and functional tests. In scheduling, you should make use of the dependency graphs based on the external functions that the modules require. - Next, this order should be used to determine the order in which the individual modules are to be tested. Determine the dates by which tests are to be completed and the individuals responsible for the testing. Prepare a master test plan schedule and include it in the document. - Finally, you must define a monitoring procedure to ensure that tests are designed and carried out on schedule. Someone will have to keep a notebook and report lack of compliance to the other team members. Similarly, there must be a procedure for reporting and correcting bugs. Writing the document The test plan document is to contain an introductory section that summarizes the whole document in a page or two and discussion sections that cover the plans in more detail. A total number of pages between 15 and 25 is about right. Remember that this document is intended for several audiences. The document should be organized so that it is easy to find schedule summaries and monitoring plans and easy directions on their personal responsibilities. The test plan should not be very long; if you find that the writing of the document is taking significantly longer than the design of the test plan, consult a member of the teaching staff. Representative samples of your tests are to be turned in later (as scheduled in the test plan). The introductory section of the test plan document, which should only be about three pages long, should include the following: - Overall objectives and success criteria - Summary of the integration plan -- a list of tests and dates and people responsible - Summary of the module-to-test-technique mapping for the four required testing techniques - Summary of the monitoring, reporting, and correcting procedures - Proposed dates for submission of individual test reports The discussion sections should contain: - Defense for the integration plan (about half a page) - Details of the tests with objective and success criteria for each test or group of tests (assuming you have proposed most of the tests in your design document, there should not be more than 20 entries in this list, and each entry should be less than one page long; if you did not have good tests in your design document however, you should include them here) - Details of the tests with objectives and success criteria for each test or group of tests (assuming you have proposed most of the tests in your design document, there should not be more than 20 entries in this list, and each entry should be less than one page long. - Details of monitoring, reporting, and testing procedures (a page or so should suffice) - Details of individual team member assignments (just a page or so, this is basically a cross reference list. Readings SEPA assignment: See alternative course outline presented in section 4.2 of the Instructor's Manual. Comments by Previous Students ... we proposed to implement on a few functions in various categories, but instead actually tried to implement all. As a result, it was difficult to test the integrated system. It would have been better to try running a small system which handled all modes, rather than a large one that was buggy ... design was generally adaptable to the smaller, more complete system and certainly wasn't responsible for hindering us from building it. 10. User Manual Week 11. draft due Week 12. final version due This document should be a self contained description of how to use your system. A user manual should be a polished, professional piece of technical prose that a software company is proud to have accompany one of their products. (And it is a handy accomplishment to show off at job interviews!) The document should have a structure that is evident to someone who is reading it straight through and someone looking for a particular topic or fact. A table of contents is required, and the organization that it reflects should be considered carefully. An index and Appendices might also be helpful. Remember that the document should be completely self explanatory. Do not assume the reader has your functional specification. You may of course edit the sections of prose from your previous documents. Do not discuss any implementation unless it directly affects the user's interface with the system. RSP: I suggest to students that any interactive system, if properly designed, should be capable of being used without repeated and heavy User Manual references. If you haven't done so already, this might be a good place to discuss key aspects of User Interface Design (SEPA, Chapter 12). In my opinion, the single most important part of the User Manual is the Index. Even if your students do not have the tools to develop one, you should emphasize its importance. In fact, if you don't have an indexing tool, this might be an excellent course project. Your User Manual should be no longer than 25-30 pages. A short command summary or pocket reference card might also be useful. Your document ought to cover the following list of topics. The exact order in which you present material and whether certain topics are combined should be dictated by your particular project and your own writing style. Introduction—a concise statement of what your program does, possibly including motivation and philosophy. How to use your system—an overall description of the style of user interaction, device constraints and any arbitrary design choices you made that the user ought to know about. Detailed system operation—an organized list of all use commands and when they are appropriate; some examples might be helpful [RSP note: mandatory in my courses!] A section for novices and experts are also possibilities. Error recognition and handling—what to expect and what to do. An extended example—show exactly what the user does and how the computer responds. Use appropriate conventions to indicate user actions and computer responses. A list of known "features" [actions that some would call bugs!] and deficiencies Everyone complains about how cryptic computer manuals are. This is your chance to show us what a good manual looks like. RSP: In her original paper, Professor Kant goes on to say that she has mixed emotions about the User Manual, indicating that students rush through it and often write what they hope the system will do as opposed to what it really does. On the other hand, learning how to properly prepare this form of documentation is one of the most valuable lessons for a budding software engineer. In a modern context, the ‘user manual’ is an on-line help facility, but regardless of the presentation format, I would recommend attaching a reasonably heavy grade weight to this ‘document’—thereby forcing students to focus on it. 11. Demonstration You should prepare about 15 minutes of material that exhibit the best features of your system and allow about five minutes for questions and feedback from the audience. If your system has been properly debugged, you can let the audience tell you what to type to show off your error handling and user help facilities. Because time is so short, it is important to practice what you are going to say and do. You should give one practice demo to your TA about one week beforehand. Twenty minutes is not nearly enough time to do the demo properly, but it's enough time to give the other students a flavor for what has been done. Many of the groups gave another demo outside class so that there was enough time to find out how their system really performed. The deadline for the demo seemed to be a good forcing function for most students; without it, I suspect that many students would never finish their project. 12. Final Project Evaluation I didn't give these a letter grade but did insist that they turn them in. I find the feedback helpful (and a good source of quotations!) and believe it gives the students a chance to express their feelings about the course. The purpose of this document is to evaluate your final project. The document provides an opportunity to step back and put things in perspective and appreciate how much you have accomplished. If your group doesn't agree on the evaluation and recommendations, feel free to write individual versions. Code and Demo Description You should turn in the complete code for your system and a transcript of your demo along with the rest of the evaluation. Functional Performance Discuss how well your project satisfies your original functional specifications. What has been added or subtracted? What advice would you give next year's students about writing functional specifications? Suggest improvements to the assignment description. Compare the actual performance of your system to the predicted performance (LOC, memory requirement, response times, calculation times, etc.). Can you come up with reasons for the discrepancies (if any)? The Design Process Were you satisfied with your design process? How helpful was the process of writing out the specifications? How would you go about the design process next time? What differences, if any, would you propose for the overall and detailed design assignments? Testing Did the order of integration that you chose seem to work out reasonably well? Did you stick to your test plan schedule? If not, why, and what would you change if you had to do it again? What method did you use for recording test results? Was debugging easier or harder than you expected? Do you think that the design process significantly reduced the amount of time needed for coding and debugging? Discuss the types of bugs you encountered. Were they limited to one module? The result of errors in the interface specifications? How did you handle fixing bugs? Management What was the real management structure within your group? Does it bear any resemblance to the structure that you had planned? Did you have any problems getting people to do their share of the work? Do you have any suggestions on how this could have been handled better? Compare the actual time spent designing, coding, testing, debugging, and managing the project with your predicted times. Break this down by individual modules and individual people. Have you learned anything that will help you to make better predictions next time? What would you suggest to next year's students? The Real World Discuss what you might have done differently if this were a real world project. How much additional work would be required to complete the project to the level described in the functional specification? How much would you consider selling the system for? Do you think the system is worth its cost? Recommendations for Next Year What changes would you suggest for next year? Be more specific than "less work." Try to summarize what you have learned and which aspects of the course were most helpful. Which would you suggest shortening or eliminating? What changes or scheduling would you suggest? Were the regular weekly meetings with the TAs helpful? Would you recommend easier projects, or would you rather start with more specific specifications and decomposition, or would you rather not choose your own projects? What about the number of people in the group? Any other topics that you would like to have covered (or ignored)? 13. Alternate Course Organizations The course as it is currently organized is really too much work for one semester. It should get more credits for being a lab course or be split into two semesters. If there were two semesters, the first could be spent on the readings and on writing a very small system or a module for a system to learn about abstraction. This would also allow students to read about testing beforehand so that they can plan the design and implementation schedule for easy testing. Another organization, which is unlikely at most schools, is to have a full semester schedule of software engineering -- a total immersion experience. This would involve a team teaching effort with lecture on technical writing and more serious grading of the assignments for writing style, a social psychology course focusing on the interactions of small groups (or a management course), and another set of computer science lectures on algorithms and data structures (or perhaps on compilers and operating systems. Concluding Comments by RSP The course described by Professor Kant is an ambitious undertaking. The project flavor is essential for a complete understanding of software engineering, but the time pressure and demands of other courses may blunt its impact. It is possible to conduct the course with a series of controlled "mini-projects," each addressing one key software engineering activity, and still get all important points across. Ideally, the course should span two terms—the first emphasizing readings and lectures and the second dedicated to a full term project (with necessary oversight). Such a course would be ideal for a senior year in CS or computer engineering, providing the student with a real world project flavor before he/she graduates. Some professors have told me that they assign all reading in SEPA (the entire book!) during the first four to six weeks of a term, enabling students to get a feel for all aspects of software engineering. Lectures are paced throughout the term and the project commences immediately after the "reading period." I've never tried this, but everyone who has reports uniformly good results. Note: I think SEPA7e is too much reading for such a short time span and I don’t recommend this approach! Kant's paper doesn't mention a number of important topics that should be covered in every software engineering course and encouraged in all projects. Project planning, elements of system engineering and software maintenance and SCM are important for all young software engineers to understand. Course content should include them! Formal technical reviews (walkthroughs) are an essential SQA mechanism. You should encourage your students to conduct them as part of their projects by requiring that Technical Review Summary Reports be submitted as part of the project deliverables. You should note that software engineering courses can be successfully conducted without TAs and with somewhat less ambitious project goals. The design of your course should, of course, be guided by the backgrounds, interests and capabilities of your students. However, the overall framework proposed by Kant can serve as an excellent foundation. APPENDIX II SEPA, 6/e WEB SITE SOFTWARE ENGINEERING COURSEWARE TERMS & CONDITIONS SEPA courseware provided at the SEPA, 6/e Web site includes a complete set of transparencies to complement your lectures. GENERAL TERMS AND CONDITIONS IMPORTANT, PLEASE READ CAREFULLY: SEPA courseware elements are provided exclusively to adopters and users of Software Engineering: A Practitioner's Approach, 5/e 1. If used in a classroom setting, SEPA courseware is available only to and may only be used by accredited colleges and universities in the United States and worldwide during those school terms for which Software Engineering: A Practitioner's Approach, 5/e, has been adopted for classroom use. 2. SEPA courseware may be used only in conjunction with "for credit" courses offered as part of an institution's normal computing curriculum. The courseware (including transparencies and video modules) may NOT be used for "short courses," or for outside consulting activities performed by professors. 3. All SEPA courseware materials are protected by copyright and the all users agree that no copies of materials will be made and/or distributed in electronic form. 4. Title to and ownership of all SEPA courseware materials shall remain with each of the vendors that holds copyright to the materials. NOTICE: The materials included as part of SEPA courseware are made available through the generosity of R.S Pressman & Associates, Inc. (RSP&A) DISCLAIMER: RSP&A, McGraw-Hill Book Company, and the author, make no warrantee, either express or implied, about the availability, fitness for a particular purpose or use of these materials. When available, they are provided "as is" without warrantee of any kind. RSP&A, McGraw-Hill Book Company, and the author reserve the right to discontinue offering any element of the SEPA courseware at any time without written notice. A BRIEF DESCRIPTION OF THE ELEMENTS POWERPOINT SLIDES Over 700 Microsoft Powerpoint transparencies are provided to complement your lectures. They are organized on a chapter-by chapter basis and have been designed both to emphasize important topics presented in each SEPA chapter and (in some cases) to introduce additional topics for discussion. Instructor Manual for Software Engineering: A Practitioner's Approach Roger S. Pressman 9780071267823, 9789355325044
Download
Close
Close
