Syllabus for CS 687 Empirical Software Engineering
Fall 2009
Instructor:
Dr. Jane Hayes (www.cs.uky.edu/~hayes).
Room
233,
Office hours TR 0915 - 1000 (Robotics (CRMS) Bldg, Room 514D)
or by appointment
Course information:
Course homepage http://selab.netlab.uky.edu/homepage/CS687-emp-sw-eng-fall09.htm
Course: CS 687 Empirical Software Engineering
Section: 002
Meets: TR 11:00 – 12:15
Location: Oliver H Raymond Building-Rm.C226-OHR
Description:
The course will present the following: Detailed study of the scientific process; particularly using the experimental method. Examination of how empirical studies are carried out in software engineering (by industry and by researchers). Review of the distinction between analytical techniques and empirical techniques. Study of when experimentation is required in software engineering, and what kinds of problems can be solved using experimentation. Examination of how to control variables and to eliminate bias in experimentation. Examination of analysis and presentation of empirical data for decision making. Students will learn how the scientific process should be applied, how and when to apply it in the software engineering area, and how to evaluate empirical evidence. The principles will be reinforced by examination of published experimental studies, and through designing and carrying out small experiments. On completion of the course, students will be in a position to design and carry out experiments in ways appropriate for a given problem, and will acquire skills in analyzing and presenting experimental data.
Course Outcomes:
Outcome 1 - The student shall know the scientific process
Outcome 2 - The student shall understand and be able to perform experimental design
Outcome 3 - The student shall understand the principles of experimental research and be able to carry out small experiments
Outcome 4 - The student shall be able to critically evaluate the empirical research carried out by others
Course Materials:
Required Text:
Clases Wohlin, Per Runeson, Martin Host, Magnus C. Ohlsson, Bjorn Regnell, Anders Wesslen
Experimentation in Software Engineering: An
Introduction
November 1999
Kluwer Academic Pub
ISBN: 0792386825
You must obtain a copy of Wohlin et al.
Other readings, as assigned: See list below.
Course web page:
Course materials will be available on the course web page. The course web page and e-mail will be important methods of distributing information for the course.
Grading:
Your grade in CS 687 will be determined according to these weights:
M.S. students:
Attendance and participation: 10%
Paper summaries: 20%
Presentation: 30%
Ph.D. students:
Attendance and participation: 10%
Paper summaries: 20%
Individual research project: 40%
Presentation: 15%
Lecture Presentation: 15%
Where:
A= 92 - 100%
B = 83 - 91%
C= 74 - 82%
D= 65 - 73%
F = 64 and below
Papers:
The first nine papers are about experimentation, and the rest are descriptions of experiments. It is important that you read the papers BEFORE the lectures, as the discussion will be very interactive. Turn in simple summaries and evaluations of four of the first nine by Tuesday, 9/15/09. For one half of the remaining papers (10), turn in a short (about one page) summary of the paper by Tuesday 12/1/09. The summaries should: (1) describe the problem in general terms, (2) paraphrase the experimental hypothesis, (3) summarize and critique the design, (4) discuss the conduct of the experiment, (5) explain whether the hypothesis was proved or disproved, and (6) critique the presentation of the paper. Paper evaluations will be graded according to the following scale: 0: not submitted, 1: marginal, 2: what was expected, 3: outstanding. You are expected to have read all articles. Proper language usage is required.
Whining Lowers Grades [1]:
You are always welcome and encouraged to discuss exams and assignments with your professor; it is an excellent way to learn from your mistakes. If the grading does not make sense to you, please ask. You may not yet have understood your mistake -- or there may be an error in the grading. However, whining, demanding a re-grade instead of requesting one, or saying that you deserve more points are good ways to convince a professor to re-grade your entire assignment or exam, perhaps with more careful attention to your mistakes.
Attendance:
Students are expected to attend and participate in all scheduled classes. Arrival after attendance has been taken at the start of class will be considered an absence. The following are acceptable reasons for excused absences: 1) serious illness; 2) illness or death of family member; 3) University-related trips (S.R. 5.2.4.2.C); 4) major religious holidays; 5) other circumstances that the instructor finds to be "reasonable cause for nonattendance." It is the student’s responsibility to provide sufficient documentation regarding the nature of the absence, and the instructor retains the right to ask for such proof.
Late Policy:
Assignments must be submitted in person at or before class time on the day the assignment is due. Assignments turned in after class starts are late. Credit will be deducted for late assignments. Assignments will not be accepted after solutions have been distributed.
Academic Honor Code:
Individual work (homework, exams) must be your
own. No sharing of computer code or
other work will be allowed. Group
projects allow the sharing of ideas and computer code within the group. No sharing of work between groups will be acceptable.
The
Accepting Responsibility for
Failure [2]:
Failure is an unpleasant word, with bleak connotations. Yet it is a word that applies to every one of us at different stages of our lives. No one is exempt. Our icons, gurus, religious leaders, politicians, rock stars and educators all fail. It is simply a reality of being human. It is also a label that we fight desperately to avoid. And it is this fight to avoid failure that drives us forward towards our life accomplishments. So--why can't we take responsibility for our own failure when it does occur?
We need to accept responsibility for a very important reason--namely, maturity. We cannot reach a full level of maturity until we accept ownership of our own mistakes. As an educator, I am confronted with this problem on a daily basis. When a student is late for class, it is because a parent failed to wake them up. A failed test becomes the responsibility of the teacher, the system, society, an after school job, but never the fault of the test taker. An incomplete assignment is inevitably due to the needy demands of a friend, or an electrical failure. I feel particularly blessed because the power circuits leading to my home must be exceptionally fine, as I have yet to experience the myriad of blackouts that have plagued my students.
Nevertheless, the daily onslaught of excuses has left me questioning the value of our education system. What, after all, is the point of "higher learning" if we fail to master the basic task of owning up to our own mistakes?
As we proceed through our education system and indeed life, our excuses for failure become more grandiose and perhaps more grotesque because the crude reality is that we have failed to mature in any significant sense of the word. To continually shift responsibility away from ourselves is worse than being a coward. Even a coward will admit that their failure is a result of their own lack of courage.
Accepting failure takes strength of character, honesty and humility. It provides a building block for future achievements. When we deny culpability, we rob ourselves of the chance to learn from our mistakes. We condemn ourselves to a lifetime pattern of avoidance and deception. Like Marley's ghost, dragging his chains of missed humanitarian opportunities behind him, we crawl forward pulling our chains of pathetic excuses behind us--never fully maturing, never fully reaching our true potential. This stale baggage is far more character eroding than any of our individual failures could ever be.
Computer Facilities:
You will be assigned an account for this course in the Multilab, a PC laboratory administered by the Computer Science department and located in Room 203 of the Engineering Annex, as well as the CSLab. For information regarding these laboratories, see links under “facilities” from the Computer Science homepage (www.cs.uky.edu). You may use alternative computer systems for developing and testing your work, provided that your submitted work will compile and run under the proper software environment as directed in class.
Group Projects:
The group projects for the course will require you to work together with other students in the class. You will be evaluated on your contribution to the group project and presentations of the project results. The instructor retains the right to make group assignments. Group members are not guaranteed to receive the same grade; evaluation of the group will be individualized to determine individual understanding, commitment, and mastery of the project goals. As part of the project, written reports will be required. Proper language usage is required.
Schedule:
|
Week |
Date |
|
Topics |
Project, Homework, Exam |
|
1 |
Thu 8/27/09 |
Paper 1 |
Introduction, Overview of Scientific Method Lecture 1 |
|
|
2 |
Tues 9/1/09 |
Paper 1,2 |
Lecture 1, Experimentation in Software Engineering, Lecture 2 |
|
|
2 |
Thu 9/3/09 |
Papers 2 – 5, Wohlin Chapter 1, 2 |
Experimentation in Software Engineering, Lecture 2 – 4, |
Hand out project assignment |
|
3 |
Tues 9/8/09 |
Papers 6 - 9, Wohlin Chapter 3, 4, 5, 6, 7, 10 |
Experimentation in Software Engineering, Lecture 5 – 8, Guest from Ag Center (Dr. Joe Chappell) |
|
|
3 |
Thu 9/10/09 |
Papers 6 - 9, Wohlin Chapter 3, 4, 5, 6, 7, 10 |
Experimentation in Software Engineering, Lecture 5 - 8 |
|
|
4 |
Tues 9/15/09 |
Papers 10, 11, 12, Wohlin Chapter 8, 9 |
Metrics and Complexity, Guest from the Writing Center |
Four summaries due, Topic
selection |
|
4 |
Thu 9/17/09 |
Papers 10, 11, 12, Wohlin Chapter 8, 9 |
Metrics and Complexity, Ethics |
|
|
5 |
Tues 9/22/09 |
Wohlin Chapter 11, 12 |
Project Day |
|
|
5 |
Thu 9/24/09 |
Wohlin Chapter 11, 12 |
Project Day |
|
|
6 |
Tues 9/29/09 |
Papers 13, 14, 16 |
Testing, lecture Assert-Assess |
Experiment Design Reviews |
|
6 |
Thu 10/1/09 |
Papers 13, 14, 16 |
Testing, lecture Assert-Assess |
Experiment Design Reviews |
|
7 |
Tues 10/6/09 |
Papers 23a, 21, 22 |
Maintenance, lecture Writing |
|
|
7 |
Thu 10/8/09 |
Papers 23a, 21, 22 |
Maintenance, lecture Writing |
|
|
8 |
Tues 10/13/09 |
Papers 32, 33, 34, 35 |
Traceability |
Hand out sample paper |
|
8 |
Thurs 10/15/09 |
Papers 32, 33, 34, 35 |
Traceability |
|
|
9 |
Tues 10/20/09 |
Papers 23, 24 |
Requirements & Design |
|
|
9 |
Thurs 10/22/09 |
Papers 23, 24 |
Requirements & Design |
Artifact Review |
|
10 |
Tues 10/27/09 |
Papers 25, 26 |
Design |
|
|
10 |
Thurs 10/29/09 |
Papers 25, 26 |
Design |
|
|
11 |
Tues 11/3/09 |
Papers 27, 28 |
Design, Lecture Presentations |
Draft paper due |
|
11 |
Thurs 11/5/09 |
Papers 27, 28 |
Design, Lecture Presentations |
|
|
12 |
Tues 11/10/09 |
Papers 29, 30 |
HCI, Management and Inspections |
Reviews due , Hand out sample presentation |
|
12 |
Thu 11/12/09 |
Papers 29, 30 |
|
|
|
13 |
Tues 11/17/09 |
None |
HCI, Management and Inspections |
|
|
13 |
Thurs 11/19/09 |
None |
|
|
|
14 |
Tues 11/24/09 |
None |
Project Presentations |
Final research papers due |
|
14 |
Thurs 11/26/09 |
NO CLASS Have fun, be safe! |
|
|
|
15 |
Tues 12/1/09 |
None |
Project Presentations |
All reading paper summaries due |
|
15 |
Thurs 12/3/09 |
None |
Project Presentations |
|
|
16 |
Tues 12/8/09 |
None |
Project Presentations |
|
|
16 |
Thurs 12/10/09 |
None |
Project Presentations |
|
|
Final |
Tues 12/15/09 1030 - 1300 |
None |
Project Presentations – if time slot needed |
|
The syllabus is
subject to change, and you are responsible for keeping informed of any
alterations.
23a. Hassan, A. E. 2009. Predicting faults using the complexity of code changes. In Proceedings of the
2009 IEEE 31st international Conference on Software Engineering - Volume 00 (May 16 - 24,
2009). International Conference on Software Engineering. IEEE Computer Society, Washington,
DC, 78-88 PDF
[1] Dr. Judy Goldsmith
[2] http://www.scs.ryerson.ca/~dwoit/failure.html.
[3] www.uky.edu/Ombud/acadoffenses/letterOfWarningExample.doc