To reiterate what I said in class, if you're taking the class "for the
writing component", you need to have your own version of your group
report which is very distinct in writing style from your group's
report. One way to create such a report would be to writeup the
report individually and then come together as a group to form a group
product. I'm not exactly sure how Dr. Browne will grade the
individual report. He'll probably look for improvement from the
individual report to the group report, but I doubt he wants the
individual report to be garbage. It takes time to write quality prose
-- start early!
I personally don't have any specific requirements for your reports
(although Dr. Browne might). As mentioned in class, one possible
format is to navigate through each part of the project. As a
suggestion, you could use an outline like the following. You need to
include all of the work products for parts B-L, so if I left something
out, make sure you cover it. These are just ideas anyway. If you
have an interesting idea to contribute, feel free to respond to the
newsgroup.
(1) Intro/Overview of application
-- summary of part A
(2) Specification
-- functional specification of the system (parts B and C)
-- execution environment of the system (first third of part E)
(3) Design
-- An overview of the component relationships (part D i and iii)
for each component {
-- explanation of component's functionality (part D ii)
-- exact specification of the component
}
(4) Implementation
-- Testing plan and implementation (part F and G)
-- Explanation of code (you can also attach your code as an appendix
at the end) (part G). Can also include some screenshots of
application if a screenshot would make sense.
(5) Verification
-- Overview of verification approach (part H)
-- Explanation of model checking efforts and successes (part I)
-- Explanation of theorem proving efforts and successes (part J)
-- Explanation of runtime monitoring efforts and successes (part K).
It would be nice if the properties uncovered by model checking and
theorem proving were covered by runtime monitoring.
(6) Conclusion
-- Recap on what your system does, what you formally verified, and
what you left to runtime monitoring.
-- Quantify your time spent on each part of the project (perhaps a
pie chart with percentages) and evaluate how much more efficient you
might be at each portion now that you have experience in it.
-- Postulate how engineering efforts could be better focused to
allow less bugs to creep through and why a more rigorous process like
the one you did should result in less buggy code and hopefully less
man hours on large projects.
-- Any other succinct discussion you think we will find interesting
Hopefully the length of this email has convinced you that you do
indeed have enough material to write at least 25 pages,
David
On Thu, Dec 4, 2008 at 4:52 PM,
> Hey David, if I already have my writing component do I get to completely skip
> the individual report?