SENG411: Human and Organizational Aspects in Software Engineering (Fall 2001)


 

Joint link to CPSC451/SENG411: http://sern.ucalgary.ca/courses/cpsc/451/F01/


Details
Course:

SENG411 (CPSC 451) – Fall 2001
Instructor: 
Mihaela Ulieru (Room: ICT540)
ulieru@enel.ucalgary.ca
Class hours: 
Wed./Fri. 8:00-9:00
Room: 
ICT116
Labs: 
Mo: 8:00-9:00; Wed. 2-4

 
Room#
Group/Day
TA
ICT116
1/Mo
Geras
ICT221
2/Mo
Geras
ENA235
1/Wed
Geras
ICT221
2/Wed
Geras

Office hours: 
Wed/Fri 9:00-10:00 and by appointment 
Course Web site:
http://sern.ucalgary.ca/courses/cpsc/451/F00/
Mail list server: 
SENG411 (students MUST subscribe
TA: 
Adam Geras, adam@adamgeras.com 




 
 

Purpose of Course: To provide an overview of techniques and methodologies for applied software engineering.
 
 

Objectives: After completing this course the student will be able to:

  1. Describe the main requirements for software engineering.
  2. Be familiar with the variables affecting programming as human performance.
  3. Be familiar with interviewing and other information gathering techniques.
  4. Understand the importance of human factors and interface design.
  5. Understand the importance of documentation and manuals, their structure and production.
  6. Understand the measurement of the complexity of systems and software quality assurance.
  7. Be familiar with object oriented development in software engineering, and the issues in choosing class libraries.
  8. Be familiar with object oriented design.
  9. Understand the main privacy, security and other legal issues in software development.
  10. Understand the importance of social, ethical and professional issues in software development.
  11. Be familiar with the Software Engineering Institute software process improvement.
  12. Be familiar with the Software Engineering Institute capability maturity model.
  13. Be familiar with some techniques for cost and effort estimation.
  14. Design, manage and implement a medium sized project in a large group as a supplier.
  15. Assess the design, management and implementation of a medium sized project in a large group as customer.
  16. Be aware of the difficulties and necessity of keeping records in developing systems. 
Course notes and course books:
Course notes will be on the World-Wide Web at http://sern.ucalgary.ca/courses/451/F00/
You are advised to use Netscape to view these documents. 

There will be no compulsory text book, but the following are highly recommended: 

  1. Software Engineering: A Practitioner's Approach by R.S. Pressman, McGraw-Hill (3rd ed.), 1992. 
  2. Software Engineering by Ian Sommerville, Addison-Wesley (4th ed.), 1992. 
  3. Software Engineering: Methods and Management by A. von Mayrhauser, Academic Press, 1990. 
  4. Foundations of Business Systems by Andersen Consulting, Dryden Press, 1989. 
  5. Managing the Software Process by W.S. Humphrey, Addison-Wesley, 1990. 
  6. Making Software Engineering Happen by R.S. Pressman, Prentice Hall, 1988. 
  7. Controlling Software Projects by T. de Marco, Yourdon Press, 1982. 
  8. Software Design by D. Budgen, Addison-Wesley, 1993/4. 
  9. Object Oriented Design With Applications by Grady Booch, Benjamin/Cummings, 1991. 
  10. Using the Booch Method by Iseult White, Benjamin/Cummings, 1994. 
Course structure
In order to cover the basic issues and techniques, and to understand future directions there will be two main parts to the course: 
 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. 
 


Assessment
This is in three parts. All three parts must be passed to achieve a pass in the course. Part A is theory and consists of items 1 and 2 below, worth a total of 40%. Part B is individual record keeping and assessment and consists of item 3 below, worth a total of 10%. It is an essential learning experience for project management, and each report must be submitted by the due date. Part C is practical and consists of item 4 below, worth a total of 50%. 

 
1. Midterm examination 
This will be 1 hour in class time (see schedule). It will cover any material up to the date of the exam. Answers to all exam questions should be written with a pen (NOT pencil) and given in point form if appropriate, with clear examples, unless otherwise specified.  (20%)

 
2. Final examination 
This will be 1 hour in class time (see schedule). It may cover any material from the entire course with strong emphasis on the material after the midterm. Answers to all exam questions should be written with a pen (NOT pencil) and given in point form if appropriate, with clear examples, unless otherwise specified. (20%)

 
3. Logs and group reports 
(i) This involves an individual record keeping or log of all your activities on the supplier project. Set it out in the form of a diary with dates, what was done, and time spent on each item. Due in with supplier group reports (ii below). Only the current month is required. 
(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 ulieru@ucalgary.ca; and your TA (adam@adamgeras.com) 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 must read "451-supplier group #1" if you are in supplier group 1, ("...#2" if group 2, etc). Each report will 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. Note that failure to include all this information (especially the format of the subject line) will result in the system loosing your email, and you will not be given credit for the report (which could result in failure or the courese).  So get it right!

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.

(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.

Note: This is NOT optional. (10%)

Hints on writing logs and supplier group reports

  1. The subject line should contain your supplier group number and your name. 
  2. Submit logs and reports together, logs first. 
  3. Only include project work in logs, not what books you read etc 
  4. If your log is less than one page, (single spaced) either you did not do enough work, or you did not write it all up. 
  5. Make sure you include yourself in the reports (marks off otherwise). 
  6. 2 or 3 lines per person is not sufficient. You need 1/3 of a page per report. 
  7. Do not use N/A, or otherwise omit grade or mark. 
  8. Do not give all As or all any other grade -- this is not proper grading. Better still, use categories. 

 
4. Project 
(50%)
I. Customer 
You will be assigned to a group of about 12 students. (Assignment to groups may be changed when the final class list is known.) Each group will prepare an informal requirements document for the project (subject to be provided) and be responsible for its evaluation and criticism as it progresses. In effect, you will be the customer for the system. You will be expected to be present at all presentations, and comment on the write-ups. Your grade will depend on how thoroughly the evaluation is carried out, the extent to which it is fair and reasonable and the extent with which it agrees with the judgments of your TA. and instructor. Groups are advised to show all first drafts to the TA., and discuss any problems or disagreements. Marks will be deducted for documents that exceed the maximum number of pages specified, and for those which are late. Documents should have a title page which has the title of your project; the name of your group, a list of members and the date. You should submit all documents by putting them up on your web page before 1pm on the required date (IMPORTANT: the 1pm deadline is ensure that the supplier group can review the documents before their lab). 


Dates as below.

(1) 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.(2%).

(2) 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. (6%). 

(3) 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. (6%). 

(4) 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.  (4%).

(5) User manual:

As before mark clearly, in italic or bold type, any comments or amendments on the supplier's user manual. (4%).

(6) 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. (4%). 

(7) 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.  (4%).
 

II. Supplier 
Your group will work with a different group to receive informal requirements for a system, and will produce a more formal specification, produce the analysis and design, code a prototype, evaluate and refine the prototype, and present a final product according to the details below. You will be the supplier of the system. Oral presentations and discussions will be required at various points within the project, and will be evaluated and assessed by the customer. You should submit all documents on the web, before 1 pm on the required date. All documents should have a title page which has on it the title of your project; the name of your group, a list of members indicating who was responsible for which parts, and the date. You should notify (by email) all interested parties concerning any re-submitted documents as soon as they are completed. Groups are required to show all final drafts to the TA. Groups are advised to show earlier drafts to the TA., and discuss any problems or disagreements. Marks will normally be deducted for documents that are late. Dates as below. 
(1) 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 customer 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 Octber; 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.  (10%). 

(2) 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). 

(2a) 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. (5%).

(2b) 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. (5%)

(2c) 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. (20%).

(3) 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. (10%).

(4) 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.) (10%). 

(5) 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.


 
Summary of marks and dates for the project 
Date
Artifact
Marks
(% of project)
17 Sept
2% 
24 Sept
10% 
26 Sept
6% 
8 Oct
5% 
15 Oct
6%
26 Oct
5% 
26 Oct
4%
24 Oct
20% 
14 Nov
10% 
21 Nov
4% 
Weeks 12-13
10% 
Weeks 12-13
4% 
One Day after Demo
4% 
Two Days after Demo
10% 
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.

Summary of other marks and dates 
Date
Artifact
Marks
3 Oct
(note 1) 
19 Oct
Midterm Exam
20% 
7 Nov
(note 1) 
23 Nov
Final Exam
20% 
Two days after demo
(note 1) 
30 Nov
(note 1) 
Notes


1. The 4 Logs and reports together are worth 10%.


Course Schedule
Week starting
(Monday)
Due Dates
Monday
13:00
Lectures/Presentations
Wed. 8:00-9:00
Due Dates
Wed.
13:00
Lectures/Presentations
Friday 8:00-9:00
Sep. 10
 
Introduction -- The Problem 
 
The Projects , and also 
Project Tracking on the Web 
Sep. 17
C1
Data Gathering Techniques
also see Dana Damian's notes of requirements enginneering
 
Programming as Human Performance
Sep. 24
S1
Human Factors
Documentation and Manuals 
C2
Software Quality Assurance
Oct. 01 
R1
Software Quality Assurance
(Complexity Metrics)
 
Formal Methods
Oct. 8
S2a(Thanksgiving).
 Formal Methods (individual work).
 .
Formal Methods (follow up)
Oct. 15
C3
Testing
 
Midterm -- 20%
Oct. 22
 
Cost and Effort Estimation
S2c
Presentations (S2b,C4
Groups 3,4,6,5,1,2
Oct. 29 
 
Design Patterns
 
 Design Patterns
Nov. 05
R2.
Requirements Engineering.
 .
 Social, Ethical and Professional Issues 
and Case Studies
10 
Nov. 12
S3
READING DAYS No class
 
Privacy and Security 
11
Nov. 19
C5
review for final
 
Final -- 20% 
12
Nov. 26 
 
prep for presentations
R3a,R3b
Presentations (S4,C6
Groups 2,1
13
Dec. 03 
 
Presentations 
Groups 5,6
 
Presentations 
Groups 4,3

Re-use




[1] SENG 411 and CPSC 451 are team taught by instructors from Computer Science (Dr. Rose Joshua) and Electrical and Computer Engineering (Dr. Mihaela Ulieru). The outline for both courses is the same. Dr. Ulieru has full responsibility for SENG 411 and Dr. Rose Joshua for CPSC 451.
[2] This course was designed by Dr. Rob Kremer, Software Engineering Research Network, UoC
[3] Exceptionally Mo. Sept. 10 will be Lecture, in Room ICT 116.