I came away from Monday's discussion frustrated, probably for several
reasons.  I wasn't sure we came to terms with the content before 
attempting to discuss it.  Also, the discussion wasn't focused.  
This was in part because I didn't have time to prepare on short 
notice, but that doesn't accout for all of it.  In any case, we 
jumped into evaluaton before everyone was up to speed.  

Let me suggest a format for these discussions and at the same time
summarize what strikes me as the important points from Monday.

Please send elaborations or other views (on form and/or content)
to this list (which I believe to the the current list of interested
parties).

Thanks to Jim Tomayko for coming.  

I. Overview (Road Map):  Where this topic fits in to SE and more 
specifically analysis, what the major goal for the topic is, how 
today's readings bear on the topic.
        For Monday's papers, this would be: development managers 
        need ways to estimate resource needs so they can decide 
        how to set schedules.  As an improvement over subjective
        judgement based on experience, they can sometimes use
        models based on experience.  These models correlate actual
        development measures (effort, elapsed time, code size) with
        measures available early in the development process.

II. Content (The Papers):  Be sure everyone understands what the
papers actually say reasonably well.  In a course, there would be
a presentation of the material; here we can lay out the major
points and ask for questions about things people don't understand.
        This didn't get much attention Monday.  Offhand, I'd say
        everyone should at least have gotten:
          - COCOMO model and how it depends on character of project
          - Function point model as contained in Appendix to paper 3
          - Progressive accuracy of estimates as time passes and
                data accumulates ("funnel", Putnma time parameter)
          - Use of Rayleigh curves for staffing levels given some 
                level-of-effort prediction (this was actually murky)
          - Variety of curve shapes in Putnam paper (but I doubt if
                many followed the equation hacking --  or should)
          - Empirical nature of models (i.e., fit curve to historical
                data; recalibrate for new organization or method)

III. Interpretation (Significance):  How is the material actually 
used, how well does it actually work, what are its strengths and 
limits, what has happened since the papers, what are the open 
questions, are these the right papers?
        We talked around this a lot. There was lots of skepticism       --
        partly because limits of applicability aren't defined, partly
        becuase management too often doesn't use whatever guidance 
        is provided, partly (I fear) because models are so crude.   
        We should look at COCOMO-II when there's a paper available.
        Personally, I'd rather have paper about function points
        than a paper about applying software science to them.
        
IV. Evaluation of the Topic (What Should a PhD Student Carry Away):
We should take a few minutes at the end to think about what role
this material would play in a PhD SE elective.  This includes not 
only the material directly presented, but the techniques, models,
appraoches, ... that it exemplifies.
        For COCOMO/function points, etc ...
        - At least COCOMO and function points appear to be actually
          useful; a lot of data is available to support this.
        - The possibility of reasoning from things you can observe
          early to things you care about later helps understand the
          factors that affect SW development.  Thinking about use of
          resources is part of engineering.
        - These models are quite good examples of empirical models
          that correlate observed data without relying on knowledge
          of underlying causes.  We'd rather have the latter, but
          an engineer should understand this alternative for those
          times when a well-founded model isn't available.
        

Mary