Elaboration Presentation Guidelines

<p>
The purposes of elaboration are twofold.
<ol><li> First specify the system requirements
in sufficient detail that the managers will agree that this system 
is wanted and useful and in sufficient detail that the designers will
know what to build and the managers will agree that the requirements 
have been met when it is done.
<li> Design the organization of the design and the stages of the implementation.
<strong>Specify the classes of objects that will
be implemented</strong>.  Determine the units to be built in each phase of construction,
with full detail for the first stage.  Include who is responsible for what.
Suggestion: Assign to pairs of programmers.  For instance, 
A and B will do X, C and D will do Y, A and C will do Z, and B and D will do W.
</ol>


<ul>
<li> Content points:
<ul>
<li> Introduction (1 minute):<br>
State your name clearly.
Succinctly summarize your project (title and goals).
<li> Requirements(3 minutes):<br>
Show top level <strong>system functions</strong>, attributes, risks analysis. 
<p> Based on this part of the presentation the audience should 
be able to comment on this functionality.   
You want to put them in a position where they understand what the 
system will perform, so they can give comments like:
<br> "A system meeting these requirements would be really neat.  I'd use it because..."
<br> "I suggest you provide alternate form X to function A, for this reason.."
<br> "How about in place of function A (as illustrated by use case U),
you could use function AA of the sort I saw on this neat system..."
<p>
In other words the audience understands the project intent enough to 
usefully discuss the requirements at the domain of activity level.
One or two use cases presented may help with the goals of this section.
</p>

<li> Design structure(10 minutes):
<ul>
.
<li> For sure use one or more of your use cases,  if not already introduced above.
<li> For sure use one or more class diagrams.
<li> As appropriate use sequence diagrams, state diagrams, activity diagrams,
package diagrams, use case diagrams.
<li> As appropriate use other documents. For instance stopwatch project
used 
a short glossary of terms.
and a sketch of a display.
Your project may suggest something else.  It might be useful to include a draft of user documentation, for instance.
</ul>
<li> Plan (1 minute);<br>
Finish with a statement of the specific plan for construction phase 1.
(What subset will be constructed,  How the team will be organized for
the effort.  Testing:  How success will be measured.)

</ul>
<li> Presentation points:
<ul><li>
Each team has 15 minutes, each of two speakers should have at least 7 minutes.
<li>
Speak slowly, clearly, and in full sentences.
<li> Make eye contact with your audience. Also, don't just focus
on one individual or one section of the audience.  In the classroom
it is easy to end up looking at only the instructor, for instance.  Avoid this.
<li> If you wish to project overhead transparencies:  Saunders can make
them for you.  He must have pages to copy at least one hour before class.
Cost is $1.00 per transparency.
<li> Online projection will not be available
<li> You may provide handouts instead of projection if you wish.
Again Saunders can help:  25 copies times 5 cents each = $1.25 per (two sided)
page.
<li> Use 6 pages of projected or handed out diagrams:
<ol>
<li> Title, goals, System functions, System attributed, Risks comments.
<li> Use case 1 (most common user activity, say)
<li> Use case 2 (most common employee activity, say)
<li> Class diagram 1 (object types in the display, say)
<li> Class diagram 2 (object types in the database interface, say)
<li> Plan for construction phase 1 (the next 3 weeks).
</ol>
<li> Use 6 pages...   Use at least 4, at most 8.  For instance I can imagine
using 4 if the requirements page is pretty wordy and if you have one
complex class diagram that you spend 6 minutes discussing.
Notice that Saunders
had 8 transparencies for the Stopwatch informal presentation last Monday.  
It was a rushed presentation and the text transparencies had too many 
words on them.  
I consider that NOT to have been
a good example of a successful 15 minute presentation, the reason being that
the documentation was a draft of the elaboration phase paperwork and not
taylored to the needs of the presentation.  The audience should be able to
take in all that is written on a page during the time that you are 
speaking about it.
</p>
</ul>

<li> Subsequent paper submission for the elaboration phase (due Mon, Oct 9):<br>
<br> Submit your revised and fleshed out inception document, i.e., submit
a requirements document organized on the same titles as the inception document.
Pay particular attention
to the sustems functions section.  This is where you convey to the manager
what the system will be able to accomplish for the domain of application.
<p>
It is acceptable to include remarks about functions that were considered
and rejected, variants that are under consideration, etc.
There may be adjustments in the requirements down the road.  It is useful
to record thoughts in that direction that have occurred at this point.
<p> Submit use cases (at least 6)
<p> Submit UML diagrams.  Class diagrams should now be down to system
level, showing the classes that will be implemented.
Submit several class diagrams showing the interactions in parts of the 
system, or 
one complex covers-everything class diagram
(if it works for you - it wouldn't for me).
<p> Include at least one diagram of type sequence, state, activity, or package.
<p> Include a use case diagram if you feel it helps reveal relations among
your use cases.

</ul> <!-- overall -->