General comments from ISB in particular:
Pictures, pictures, pictures. Screen-shots, screen-shots, screen-shots. I think there is a tendency to not do enough of this because you know what your tabs look like, you know what your GUI looks like, you know what Netbeans looks like, etc. But your reader does not (or does not necessarily). And a picture is indeed worth a thousand words in a lot of cases.
Keep in mind that programmers and computer science types are more used to graphical, non-narrative communication than you are. You are not writing a book here, or an essay, you are communicating things about your IA and your IA process in as good a way as you can, and the more image-based, or image like (bullet points, diagrams, tables and so on) the better.
And even heirarchies of bulleted lists:
| And tables for sure | too!! |
Tables group |
and organize |
| And are just way more easy to understand |
than long run-on narrative paragraphs
|
And even color. Why not? You will be submitting on-line.
The biggest point here: Less Narrative, More Visual
And Do Definitely have titles, and format them somehow so they stand out, look nice, and are consistent.
----------------------------------------------
Miscellaneous Points
- ISP grading point - a 24/25 is not necessarily a 6/6 or a 4/4 on the IB scale.
- Preferable HW average commitment: HL 20% of 112 = around 22 home assignments to commit to the dossier.
Max commitment: HL 20% of 120 = around 24 home assignments to commit to the dossier.
----------------------------------------------
General Notes from Montezuma IB CS Conference
"Dossier" - now can call finished product the "Solution"
*** You can now "modify an existing solution for a client". ---> Look up the exact wording of this.
Make sure to take a good look at Guidance for the development of the internal assessment
PROTOTYPE ONLY - NO CODE!!! for first prototype
At the end, make your submission pretty. Logos and so on give you up to a 15% edge.
"Measure twice and cut once."
Why not learn from other people's mistakes (in terms of planning.)
Remember you can now take code and add to it is Ok.
Idea of, for Success Criteria:
Criterion --------- Priority --------- Reason
1
2
1
So 1 is "must have", 2 is "should have", and 3 is "bonus".
Chris liked that idea.
At some point I do need to do a lesson on what an algorithm is, and use a classic example like making a peanut butter and jam sandwich, or you have a pile of coins and one of them weighs more than another - there is a binary solution, and also a trinay solution etc. But be explicit about what an algorithm is.
For sure submit a list of why kids got what they got for their dossier - and keep it long; why not.
****** Criteria C needs to be marked at a Higher Level level - they are all marked exactly the same way!!!!!!!!!!!! So at least add in polymorphism etc. at least a little bit.
***** OOP has to be Java!!!!!! The other three options can be other languages.
***** Stuff like linked lists can be used from libraries now; that's what the "Libraries" focus is all about.
***** So you can use a library, and in fact you should use a library, and could lose marks because you didn't use the library - make it clear why they chose their own specialized linked list instead of a Java class.
----------------------------------------------
Coding Points
Have a code buddy with whom you check up regularly. Maybe even exchange partners.
Maybe have them do progress reports for each other. Yep, see hw Spring 2013
Have a To Do list from the beginning, and put completion dates for each thing.
The To Do could come from the Chronological Development Plan, though be more of a summary, or bulleted points.
I have them upload all days for:
- regularity
- time machine backup
Include major accomplishments in your Record of Tasks.
Have a "Pruning Day" where I look at the program after a few days, and prune back all the stuff which is too much.
Each day I ask what their first item on the ToDo list is; i.e. they tell me each time what they are going to do the next 45 minutes or an hour. This, A. keeps me on top of things, and B. gets them to think about what they will do for their "homework"; otherwise they might not get started since they don't know how to get started.
With 7 minutes to go each dossier programming class, revise To Do list and e-mail your code buddy (with a Cc to me) your plan for home work on it.
----------------------------------------------
C - Development Points (From Montezuma)
- high level of complexity
- appropriate use of tools
- all techniques explained (so have a section where they discuss using arrays, why I had various tabs etc. but do get them to write this.)
- all sources identified (pictures, Java libraries, etc.)
(another video - or make sure you reference the video and have the kids alt tab to the code to show the complexity.)
(he does have this sort of stuff in section C - take a look!!!!!! (including Algorithm overview.)
And note that having pseudocode in section C makes it more extensible. But do note that the algorithms only appear here, after the coding has been done. (In the example, make sure they reference the appendix.)
Functioning (video & CD)
- The video & CD ROM of program (jar)
Extensibility (code) *******SUMMER START******
- So it can be extended by you or others in the future.
--> Add comments, plus explanations of major algorithms.
--> Check variable names
Evaluation (writing)
- Go through Success Criteria and to both of the following:
--> COMPLETED / NOT COMPLETED (possibly with a comment if you think it is needed or would help.)
--> Feedback form or interview from the client.
***As part of this, do a bunch of "Post Coding Comments" boxes at the bottom of each A and B stage noting what changed while coding happened; rather than ever considering changing anything as it was written at the time. Maybe group all of these together, or at least their titles in one section, though they appear in sections A and B separately also.
Recommendations for Improvements (writing)
- Use the things done in the above Evaluation to suggest future development.
D - The Extensibility Stage (From Montezuma)
- fully evaluated with respect to A
- feedback from client/adviser
- recommendations
One way around that is to have various tiers of goals back in A
tier 1 goals
tier 2 goals
plus "Stretch Goals" (and these could turn into "Phase 2" half way through, why not, and these in turn will be the recommendations) (Do make sure you include noting who the advisor is - in all cases that is me.)
Evaluation
Make sure to include feedback from the advisor and client. (There is none of this in the Mulkey example.)
**** Change my instructions to make sure I have Sub-Headings for each part, and that those terms come from the rubric. (I think I have done this, but check and add - to help cranky markers.)