Class hours: Tues/Thurs 5:00-6:15 pm
Labs: Tues/Thurs 6:30-7:45 pm.
Office hours: Tues/Thurs 3:45-4:45 pm and by appointment.
TA's: TBA
You are advised to use Netscape to view these documents.
There will be no compulsory text book, but the following are highly recommended:
1. Techniques in software engineering: covers some of the techniques currently in use in organizations;
2. Large group project: involves the carrying through of a project from specification through implementation and testing, and also the evaluation of another group's project.
February 13. (20%)
March 27. (20%)
(ii) 3 monthly reports of an assessment of each member of your supplier group. You should have one per person (in alphabetical order of last name), including yourself, outlining who did what during the month, and how you assess their work. Some sort of grading on one or more criteria should be applied. (This is in addition to your personal log.)
Each month you should submit to kremer@cpsc.ucalgary.ca; and your TA your own log for the current month and all the previous monthly reports on each person, one person per report. Please use the template to construct your report. The subject line should contain your supplier group number and your name. Each report should have at the top the name of the person and your name and supplier group number. Each report should be about a third of a page long. You will be marked on how perceptive and reasonable your comments are.
Do NOT submit reports in the same mail as other messages.
Get to know the people in your group as soon as possible, or you will find this difficult.
Due by 1 pm on 29 January, 11 March, and with final project evaluation.
(iii) One final report of an assessment of each member of your customer group. You should have one per person (in alphabetical order of last name), including yourself, outlining who did what during the project, and how you assess their work. Some sort of grading on one or more criteria should be applied as with the supplier reports. Each page should have your name and customer group number at the top. Each report should have the name of the person and should be half a page long. Your customer group number and your name should appear on the subject line Submit as with supplier reports.
Do NOT submit reports in the same mail as other messages. Due by 1 pm on 3 April.
Note: This is NOT optional. (10%)
Hints on writing logs and supplier group reports
(i) Informal specification of requirements:
This should outline the project and customer requirements. Make sure the project is suitable for completion in one term. Remember that it is not a competition; do not aim to destroy the supplier but give an honest set of requirements. (Marks will be deducted for a project considered too easy or too difficult.) No more than 5 pages (if it were printed), including the title page. 16 January. (2%).
(ii) Functional specification and management plan:
This is to be assessed and evaluated against actual requirements. Make sure that you are satisfied at this stage that your supplier is aiming to meet your requirements. Mark clearly, in italic or bold type on the supplier's document, any comments or amendments on the document. You may add up to 2 additional pages. Do not add any new requirements at this stage, or make the project any larger. 31 January. (6%).
(iii) Overall design document:
The functional specification and the overall design together describe the proposal from your supplier. When accepted, these documents are a contract between you and your supplier about what they intend to deliver. Changes can be negotiated later and should be recorded as an appendix. Mark clearly, in italic or bold type, any comments or amendments on the supplier's overall design document. You may add up to 2 additional pages. 18 February. (6%).
(iv) Presentation:
A preliminary review of about 5 minutes will be presented by the supplier in class, with up to 5 minutes of questions and discussion from you, the customer. Everyone should attend and take part. You should address any points which need clarification or for which you suggest changes, which should be minimal. After you have seen the amendments you will be required to sign a contract with your supplier. Week 7. (4%).
(v) User manual:
As before mark clearly, in italic or bold type, any comments or amendments on the supplier's user manual. 24 March. (4%).
(vi) Demo:
Use the demo time to assess the system and the (possibly revised) user manual. Everyone should attend and take part. You should ensure that the demo relates closely to what has been negotiated and agreed in the contract. In Weeks 11 to 13. (4%).
(vii) Evaluation:
Write a project evaluation (4-5 pages) which should include a discussion of how well the project satisfies your original requirements or what has been added or subtracted; how useful the design process was and what differences (if any) you propose for the design assignment.
Submit by 1pm one day after the demo. (4%).
(i) Functional specification and management plan (about 15-20 pages):
This should explain what you are going to do for your project as opposed to how you will accomplish it. When writing this, do not assume that your customer has any deep knowledge of computer science. Cost estimation is not required. The functional specification should include a title page which has on it the title of your project; the name of your group (which you can invent); the people who contributed to the document, including authors of individual sections and editor of the whole paper, outside consultants etc; and the date. In about 2 pages you should summarize the project you are working on. Give your system a name and describe what it does and who will use it. What needs will it satisfy? How will it help the users? Outline the most important features of your system. Describe the hardware your system will use, and any important performance goals that it should satisfy, e.g. time or space efficiency, security, or reliability.
The next section of about 10 pages concerns the user interaction and will form the basis of your user manual (see part iv below). It should describe the function that the system will perform from the point of view of the user. Cover the kinds of inputs your system expects, the actions it will take on both expected and unexpected inputs, and the types of outputs the user will see in those cases. (Marks will be deducted for a poor user interface regardless of the opinion of the customers.) Include several sample transcripts of the interaction with your system in the form of a dialogue. Include a glossary of all specialized terms used in the document, either computer science terms that the programmer may not know, or terms from the field in which you are working.
The management plan of about 5 pages should include a breakdown of the different features of the project, the major classes of functions and the relationship between them. It should also include a preliminary decision on your main data structures and algorithms, and a page or so discussing possible implementations. Make sure that you do not give the impression that you are promising more than you intend to deliver. Cover yourself by including a page on a minimal system that you think you can complete by the end of February; and the enhancements you could include if all goes well. Finish with a summary restating the main points you want the customer to remember, then include a page on the structure of your team and who will be responsible for which parts of the project. 27 January. (10%).
(ii) Design documents:
The functional specification and the overall design together describe the proposal to your customer. When accepted, these documents are a contract between you and your customer about what you intend to deliver. Changes can be negotiated later and should be recorded as an appendix. 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 complex system -- one of your major goals is to get something working by the deadline!
The main goal of the design process is a detailed design document that is complete enough to be a reference from which any competent computer scientist can produce code and a user manual, and carry out tests. This document will eventually evolve into the code and usually the system maintainer's guide. An intermediate goal is the overall design specification which is 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 review carefully 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).
(iia) Overall design document:
Based on the examination of the module interactions, you should prepare a set of interface definitions. For the overall design document, (about 40-50 pages) you should define your major data abstractions and modules, focusing on the design, submodules, error-handling, exports and imports of the major modules. Fill in as many details as possible in order to get feedback on it. Include sections discussing the modification and the management questions, an executive summary and a list of contents. Make sure that you provide a top-down description of your system. You are advised to consult your TA. frequently on this document. Provisional feedback will be given as an indication of what you might expect for the detailed design document. 11 February.
(iib) Presentation:
A preliminary review of about 5 minutes will be presented in class, with up to 5 minutes of questions and discussion from the customer in Week 6. (Marks will be deducted if this is not well organized or runs over time.) Provisional feedback will be given as an indication of what you might expect for the detailed design document. Week 7. (10%)
(iic) Detailed design document:
The final step is then to prepare the detailed design document. The detailed design document (about 80-100 pages, built on top of the overall design document) should include answers to all the questions for as many levels as possible. Write pseudocode or code outline for all modules (this should be in terms of calls to other high-level functions and be easy to read). Include test schedules as part of this document. Update the sections describing coding responsibilities. 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.
Testing must be carefully planned and documented as to 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 be agreed on, documented, and carried out. Several stages of tests must be scheduled, and several testing procedures should be explored. Scheduling is required for unit tests, integration testing, functional testing, performance evaluation, and an acceptance test (demo). These should include practice in the techniques of walkthroughs, logic testing and input/output testing. The test and evaluation plan should contain a statement of objectives and success criteria, integration plan e.g. the order in which modules are to be combined, testing and evaluation methodologies, and responsibilities and schedules. You must devise a monitoring process to ensure that tests are designed and carried out on schedule, report lack of compliance to other group members, and decide on a procedure for reporting and correcting bugs.
The test plan (about 10-15 pages) should contain an introductory section that summarizes the objectives, a list of tests and dates and people responsible, summary of the monitoring, reporting and correcting procedures, and proposed dates for submission of individual test reports; a discussion section covering a short defense of the integration plan, details of the tests with objective and success criteria, details of monitoring, reporting and testing procedures, and details of individual group member assignment. Each person should be involved in at least one set of tests. You are advised to use walkthroughs regularly, and to consult your TA. frequently on this document. 27 February. (20%)
(iii) User manual (about 20-25 pages):
This should be a self contained description of how to use your system. It should have a clear structure, a table of contents, and an index. Do not discuss any implementation. It should contain an introduction, a section on how to use the system, error recognition and handling, and a section showing a sample interaction complete with screen dumps, and a list of known bugs and deficiencies. 18 March. (10%).
(iv) Demonstration:
This should exhibit the best features of your system. It will be followed by questions from your customer, with suggestions of input to try, and discussion. With your evaluation you must submit the complete code and a transcript of your demo. (Marks will be deducted if the demo is not well organized.) To be given in Weeks 11 to 13. (10%).
(v) Evaluation:
The final document required is a project evaluation (about 10-15 pages) which should include a discussion of how well your project satisfies your original functional specifications or what has been added or subtracted; how useful the design process was and what differences (if any) you propose for the design assignment; how the test plan worked, how the real management structure resembled the planned one; comparison of actual times taken for each part; how you would have done it differently if it were a "real" project (dissenting opinions in the group may submit an additional statement); and in what way you could make the project less work if you were to do it again. Include a section on "lessons learned" from doing this project. (10%).
The final documents should be submitted by 1 pm two days after your demo.
(i) 2%, 16 Jan
(ii) 6%, 31 Jan
(iii) 6%, 18 Feb
(iv) 4%, Wk 7
(v) 4%, 24 Mar
(vi) 4%, Wk 11-13
(vii) 4%, Wk 11-13
II.
(i) 10%, 27 Jan
(iia) 11 Feb
(iib) 10%, Wk 7
(iic) 20%, 27 Feb
(iii) 10%, 18 Mar
(iv) 10%, Wk 11-13
(v) 10%, Wk 11-13
Notes
1. No part will be accepted until all previous parts are
completed;
2. The group grade may be adjusted for individuals depending on
their contribution to the group.
Exams: (i) 20%, 13 Feb; (ii) 20%, 27 Mar
| Week starting (Mon) | Tuesday 5:00-6:15 | Thursday 5:00-6:15 | |
| 0 | 970106 | No class | Introduction -- The Problem |
| 1 | 970113 | The Projects , and also Project Tracking on the Web |
Data Gathering Techniques (C) |
| 2 | 970120 | Programming as Human Performance | Human Factors / Documentation and Manuals |
| 3 | 970127 |
Object Oriented Programming: An Introduction (S) |
Object Oriented Programming: Class Libraries (CR) |
| 4 | 970203 | Software Quality Assurance | Software Quality Assurance (Complexity Metrics) |
| 5 | 970210 |
SEI Software Process Improvement (S) |
Midterm -- 20% |
| 6 | 970217 |
Privacy and Security (C) |
Design Patterns |
| 7 | 970224 | Project Groups |
Project Groups (S) |
| 970303 | READING WEEK No class | READING WEEK No class | |
| 8 | 970310 |
Social, Ethical and Professional Issues and Case Studies (R) |
Object Oriented Design |
| 9 | 970317 |
SEI Capability Maturity Model (S) |
Cost and Effort Estimation |
| 10 | 970324 |
Presentation Preparation (C) |
Final -- 20% |
| 11 | 970331 | Project Groups |
Project Groups (R) |
| 12 | 970407 | Project Groups | Project Groups |
| 13 | 970414 | Project Groups | Project Groups |
N.B. The exact date and time of project group presentation will be assigned by ballot.
Practical Software Engineering, Department of Computer Science
Rob Kremer