Win a copy of AWS Security this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

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

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 759
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I documented my decision while developing. If you do it at the end there is a big chance you forget things.
 
Jacob Bridge
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 759
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 123
Hibernate Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I used the following format as outlined in this thread: Passed 364/400
 
I'm gonna teach you a lesson! Start by looking at this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic