How to describe "out of scope" things in choices.txt

[Jacob Bridge]

Hi,

I starting with final stages of my assignment - documentation. And I have question about choices.txt.

I have some things, that I decided to describe in choices.txt rather than implement them. One of them is Client crushes handling.
I believe, that this implementing this task is out of the scope of the assignment.

And my questions are:
What is the best way to describe such decision choices.txt?
How do you describe such decisions?
Do you think it would be Ok to directly say that "I think that this task is out of the scope"?

What do you think about the following schema of describing such decisions:

-----------------------------------------------------------------------
Problem: problem description...
Possible solutions: we can make this (solution #1) or we can implement it in that way (solution #2)...
Decision: I think, that this task is out of the scope of the assignment, so the solution of this problem is not implemented by me,
but if company's IT director will decide make new project iteration, than I think that solution #1 is the best for solving this problem.
-----------------------------------------------------------------------

looking forward to your comments!
Thank you in advance!

[Jeffry Kristianto Yanuar]

Problem: problem description...
Possible solutions: we can make this (solution #1) or we can implement it in that way (solution #2)...
Decision: I think, that this task is out of the scope of the assignment, so the solution of this problem is not implemented by me,
but if company's IT director will decide make new project iteration, than I think that solution #1 is the best for solving this problem.

I think it is more informative, I didn't do that. As long as the accessor will understand what you mean, you can use any format. You create documentation as a final step, I think documenting while doing the assignment is better. Good luck in you exam.


Jeffry Kristianto Yanuar (Java Instructor)
SCJP 5.0, SCJA, SCJD (UrlyBird 1.3.2) --> Waiting for the result

[Jethro Borsje]

I documented my decision while developing. If you do it at the end there is a big chance you forget things.

[Jacob Bridge]

Hi,

thank you very much for the answers!

I agree with you about documenting during development, at least for choices.txt. I actually wrote this documentation during development. But I wrote brief description of a problem and my solution for each decision, in order not to forget to document it later in choices.txt.

Sorry, but I still don't understand how you document such decisions. Do you think it's Ok to write that "I think that this task is out of the scope" or it's better to argument this decision according to instructions.html? I mean find different clues in instructions in order to prove that this task out of scope? For example I can write in choices.txt:

------------------------------------------
... Since B&S intends to use that system as a learning exercise before going on to a web based system, client crushes handling is goes out of scope of the assignment. Web based system most probably will require another algorithms for handling client crushes. The implementation of this algorithm will also raise the complexity of the code, that will be bad for understanding it by junior programmers ....
------------------------------------------

Jeffry, had you also decided to not to handle client crushes? How do you described this (or maybe some similar decision)?

Thank you in advance.
And, of course, all you comments are highly appreciated!

[Jeffry Kristianto Yanuar]

I didn't document about client crashes.

My format is like this :

<the package name>
- document 1
- document 2
- etc

<the other package name>
- document 1
- document2
- etc

Good luck on your exam and wish me luck too !!

Jeffry Kristianto Yanuar (Java Instructor)
SCJP 5.0, SCJA, SCJD (UrlyBird 1.3.2) --> Waiting for the result

[Justin Rundle]

I used the following format as outlined in this thread: Passed 364/400