CSE503 Winter 2013: Software Engineering

David Notkin • MGH 271 • 10:30-11:50am Tuesday and Thursday

Basics

• Office hours: on-demand. Send email and I will quickly set up a time to meet.
• TA: Safiye Celik (safiye@cs.washington.edu). Office hours: Friday 12.30-1.30 pm at CSE502
• Readings: Free access to papers (unless marked) through UW Libraries from any UW IP address or by clicking the off-campus access link at the top-right of lib.washington.edu.
• Class email list: cse503a_wi13@uw.edu
• Catalyst dropbox: https://catalyst.uw.edu/collectit/dropbox/notkin/25494
• Catalyst discussion board: https://catalyst.uw.edu/gopost/board/notkin/31410/
• Academic misconduct: This is a very serious offense and will be dealt with through the departmental, college and university processes. Copying others' work, including from this or previous quarters or from publicly available sources without attribution, is considered cheating. If in doubt about what might constitute cheating, send the instructor email describing the situation. For more details see the CSE Academic Misconduct web page. Do not read this in a way that discourages genuine collaboration and discussion.

Required Work

• 5% of your grade will be for class participation, broadly construed including lecture, the course mailing list, etc.
• 5% of your grade will be for Response to Reading #1, due Friday 11 January 2013 at 4:30pm.
• 15% of your grade will be for additional Responses to readings, as announced later.
• 15% of your grade will be for assignments, as announced later.
• 30% of your grade will be for Project #1, more below.
• 30% of your grade will be for Project #2, more below.
• There are no examinations.

Readings and Responses

Software engineering background readings (#1)

• NATO Software Engineering Conferences. These are lengthy, so skimming is in order.
• Barry W. Boehm. Software engineering. IEEE Transactions on Computers, C-25(12):1226-1241, December 1976.
• W. Wayt Gibbs. Software's Chronic Crisis. Scientific American 271 (3), p. 86, September 1994. (Please search for a copy on the web.)

Software engineering background responses: due Friday January 11th at 4:30PM (5% of course grade)

Write a 2-3 page scholarly assessment of what people "got right" and "got wrong" about software engineering through around 1980. That is, based on literature (likely starting with the above, but with more through following citations, searches, asking Notkin, etc.) (a) identify some assumptions or conclusions upon which people based their perceptions of software engineering, and (b) document why in 2013 there is evidence that they were correct or incorrect.

• 2-3 pages means reasonable spacing, reasonable margins, reasonable assumptions. Being reasonable encourages the grading to be more reasonable.
• It is perfectly fine to share ideas, references, have discussions, etc., with others. Indeed, I encourage it! But write it yourself.
• Turn in using Catalyst dropbox, as given above (ideally in PDF format).

Software engineering background readings (#2)

• Edsger Dijkstra (March 1968). "Go To Statement Considered Harmful." Communications of the ACM 11(3): 147-148. doi:10.1145/362929.362947
• Michael Jackson gave a keynote at ICSE 1995 titled "The World and the Machine."  Please watch the video (with friends and popcorn, if you wish, making sure to admire the guy in the tie and the dark beard) at
• http://videosrv14.cs.washington.edu/education/courses/csep503/07au/mj.mp4
• You'll have to put the slides in a separate window (pdf, ppt)

Project Information

Project #1 has two options.

• For those with significant development experience, this should be an aggressive use of a model checker, of selected tools, of some new technology, etc. There should be a focus to the effort; not "just playing around" with the tool or technology. The intent is to have you learn, in some depth, about an approach to build better software or to build software better. The specific project must be approved by me. The results of the project will be a web page that describes the effort, assess the strengths/weakness of the approach, lists problems you faced (you might do this by starting a mini-blog right away), links to the tools, etc. You can work individually or in pairs.
  
  Examples might include the Daikon invariant detector, one of CMU's many model checkers, the SPIN model checker, Alloy from MIT, Pex from Microsoft Research (and conceivably even Pex for Fun, although I'm not sure what the project could actually be), etc. There are lots of other possibilities -- search some, talk to me, etc. for other ideas.
• For those with less development experience, this should be an aggressive "classic" software development effort -- done in groups of two or three people. The intent will be to focus on software design, software implementation, and (to a lesser degree) software teamwork to a level possible in about a month. The specific project must be approved by me. The results of the project will (a) a well-documented software system, including directions on how to easily install and run it, and (b) a one-to-two page description of what was learned about design, implementation and teamwork written independently by each team member. High-level examples include:
  • A soup-to-nuts set of designs and implementations of the (in)famous KWIC system; see D. L. Parnas. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (December 1972), 1053-1058, http://doi.acm.org/10.1145/361598.361623. You should also see David Garlan, Gail E. Kaiser, and David Notkin. 1992. Using Tool Abstraction to Compose Systems. Computer 25, 6 (June 1992), 30-38, http://dx.doi.org/10.1109/2.153255. One specific objective of this example would be to provide a set of designs and implementations that could be used at the undergraduate level for comparing and contrasting designs.
  • If you are looking for an in-depth Java experience, you can do the Husky Maps project from CSE331. You can omit the null-pointer type-checking piece of the project. You also do not have to do the questions in the various assignments, only the coding and documentation. Your team can organize the work as you see fit.
  • There are lots of other possibilities -- search some, talk to me, etc. for other ideas.

Project #2 also has two options

• A primary research project done individually or in "right-sized" groups. The project must be approved by me. Examples might include:
  • As I will discuss in the first week or two of lectures, I am increasingly interested in the notion of software complexity. I have found the work in this area, to date, very weak; and I finally have a hypothesis about why I think it's weak. Specifically, complexity measures look at static program properties, while I posit that the complexity of the relationship of between the static program and its behaviors has been omitted. Projects that explore this notion would be lovely.
  • More generally, the question of getting a strong handle on the gap between essential and incidental complexity intrigues me, and project proposals in that area would be attractive to me.
  • What is the value of a test (roughly in information theoretic terms)?
  • There are lots of other possibilities -- search some, talk to me, etc. for other ideas.
• A secondary research project done individually or in "right-sized" groups. The project must be approved by me. Examples might include:

  (a) State-of-the-art of automated testing: probably a slightly narrow variant.

  (b) State-of-the-art of <your favorite topic>.

  (c) People who did the "development" variant of Project #1 can do (a slightly more aggressive version of) its "research" variant for Project #2.

A proposal (informal, by email) is required by Friday 15 February 2013 at 4:30pm. Project #2 is due Wednesday 13 March 2013 at 4:30pm, with project presentations at the final lecture on Thursday 14 March 2013.

Lecture Information

Notkin will be absent on Thursday 21 February 2013; there will be a guest lecturer. The following is subject to change.