Assigned work
In addition to the
assignments and projects below:
- 5% of your grade will be for class participation,
broadly construed including lecture, the course mailing list, etc.
- 7.5% of the grade is not yet defined, but will likely
require a mixture of a small assignment or two and some summaries of
selected research papers.
- There are no examinations.
- Assignment #1 "Looking backwards" (5%
of
course
grade):
Due on Monday April 4 @
10PM
- 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 2011 there
is evidence that they were correct or incorrect.
- 2-3 pages means reasonable spacing, reasonable
margins,
reasonable assumptions.
- It's perfectly fine to share ideas, references, have
discussions, etc. But you are to write it yourself.
- Due on Catalyst Collect
it by
4/4/2011 @ 10PM,
ideally in pdf.
- Assignment #2 "Looking sideways" (2.5% of course grade):
Due on Monday
April 11 @ 10PM
- I will assign each of you responses to Assignment
#1
written by two of your peers (by close-of-business on Tuesday 4/5).
- You are to write informal, but careful,
evaluations of each
of the two assignments; I expect these to be about a page, but it could
be more or less, if you think it is sufficient, necessary, etc.
Think of this as the kind of thing I might write when grading an
assignment :-).
- Due
on Catalyst
by 4/11/2011 @ 10PM, ideally in pdf.
- Project #1 "Pushing
your boundaries" (35% of course grade): Due Monday May 2,
2011 @ 10PM
- 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.
High-level examples include:
- The Daikon
invariant detector.
- One of CMU's many model checkers
-- I haven't vetted any of these recently, so caveat emptor.
- 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).
- You might find some other interesting tools from
Microsoft Research here.
- 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. On the linked page, this is
assignments 2 through 7 (inclusive); 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
Pushing
the field's boundaries (45% of the course grade): Due Wednesday June 8,
2011 @ 10PM
A "research" project (primary or secondary research) -- done
individually or in "right-sized" groups. The project must be
approved by me. [More
information will be forthcoming.]
- Primary research examples 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)?
- ...
- Secondary research examples include:
- State-of-the-art of automated testing: probably a
slightly narrow variant.
- State-of-the-art of <your favorite topic>.
- People who did the "development"
variant of Project #1 can do (a slightly more aggressive version of)
its "research" variant for Project #2.
|