CS 569, Fall 2014, Dr. Burnett
Term Case Study Project (Team)

With your team, report on your case study. Rules/Reminders:

• Your term case study project can be exploratory, descriptive, or explanatory.
• It must be about some aspect of software development / programming.
• You will need to understand the readings, lectures, and homeworks.
• Be sure to follow the principles from class and the readings about rigor in design, analysis, chains of evidence, theory, etc.

Executive summary page:

The first page should be an executive summary that provides items 1-5 below in a summary table, like this:

Report:

Then start a new page and provide your full report, written up as though you were going to submit it to a conference or journal. Your full report should be structured with at least these sections. (You may insert additional sections, subdivide them, etc., as desired.)

• Introduction: Explain the research question and initial propositions or more detailed research questions, theory ties the research question/propositions have to scientific literature (with citations), any other motivation about why the research question is interesting. You can include other information in the introduction too, if you think it makes your report more readable or understandable. Usually the introduction is fairly brief, about 1 page. Sample #1 worthy of an A (but needs to cut back on scope). Sample #2 worthy of an A (but needs to analyze fewer interviews to fit into the remaining weeks of the term.)
  Here are some additional notes to help you with the theory part:
  • What counts as a theory: In here, when we say "theory", we mean any prior academic proposition that could be tied to software development or programming. It must be implicit or explicit in refereed scientific literature, not be just some theory you conjure up from scratch. It may have been presented as a theory or model (eg, Alan Blackwell's Attention Investment model, Bandura's self-efficacy theory, any of the hypotheses contributed by the theory chapter of Laura Beckwith's thesis, Information Foraging Theory, etc.), may be a previous empirical result that you think needs follow-up (eg, prior results on the efficiacy of pair programming, any of the hypotheses contributed by the Seaman/Basili paper, prior results suggested by one of the papers referenced in the Dittrich et al. editorial, etc.), or may be unproven claims/beliefs among computer scientists that have not been empirically explored (eg, monads as a Good Thing in the Haskell programming language).
  • Include citations to any theories you tie to.
  • Ideally, your theory basis will be of interest/use to you in your later research. For example, it could be useful in your thesis research topic, or in something you're doing as a TA or focusing on in another class, etc. You may need to do some reading to find useful theories for your interests.
• Design of the study: In this section, explain your design choices. Your goal is to convince me that this is a professional, scientific study with good design choices. Sample #1 worthy of an A (but needs to cut back on scope)
• Describe the "case" -- what situation exactly did you study? In what organization(s)? Etc. Especially: What were your criteria for selecting the particular instance(s) of the case to study from all the instances you could have selected?
• Include the other design information from the table, say why you chose them, any other substantiation you think you need here to convince me your answers are correct. If there were any "natural controls" involved, this is the place to point them out.
• Include your case study protocol, i.e., the procedures you followed. (See textbook for examples of these.)
• The database structure: Explain what you collected and what's in your database. A table showing its fields and structure might be useful. (Include the actual database in the appendix. Refer to the handout I provided from last year's "throwaway" case study for an example.)
• Pilot: Briefly explain what you learned from your pilot run of the study. Who you chose for your pilot and what it caused you to refine/change aspects of your case study's design, protocol, or procedures. This section will be brief, maybe 1/2 page.
• Results section(s): This is where you put what you found out. Repeat particularly interesting pieces of data here in your reasoning (so that I don't have to flip back and forth looking it up in your database). A sample from a previous year that received an A. Reminders:
  • The more concretely your reasoning is tied to the data, the more credible it is.
  • Use solid chains of evidence/reasoning that tie back to the database, and be explicit about what these chains have in them. Diagrams, matrices, etc., showing this reasoning may be helpful.
  • Don't forget use of rival theories/explanations.
  • Carefully consider predictions that come from whatever theories you're using
  • Keep your reasoning solid by thinking about when you're doing induction, when deduction, and when verification.
• Threats to validity: Every study has threats to validity. Discuss the ones pertinent to your study here. (This section is expected to be brief, around 1/2 page.)
• Conclusion: What are the main results of your study, and anything else you'd like to say to summarize what you did. (Usually about 1/2 page.)
• References: The papers you referenced in your report, in any usual format for research papers.
• Appendix: Include your database.

You may want to look at other case study papers of software development as examples of what such reports contain, such as the Seaman/Basili paper and other examples from the main class web page.

What format to turn in: Turn in **hard copy**, single-spaced. Be sure both teammates' names are on it.

What to turn in for the design assignment due date: Turn in both the executive summary table and the Introduction and Design sections of the report. (Note: Of course, the database structure part of this will be likely to change as you collect more and more data.)

When everything is due: See class schedule for the due dates.

Date of last update: Nov. 1, 2014.