07-23-2002, 03:33 AM
hi all, Rubber Band Boy here,
im currently doing a project in my software design class and it needs to be "fully documented". exactly what documentation would i need to include?
i know i need a feasability study in there somewhere, but hw exactly do i do this
07-23-2002, 05:32 AM
Why not ask your teacher?
The documentation would vary depending on who it was for... for example - if it was your teacher, it would include "how i did this bit of code" documentation, if it was for the end-user it would contain "how to use the program" type documentation.
07-23-2002, 05:35 AM
to be honost, my teacher doesnt like to help us with it. he gets pi**ed off real easy so i dont wanna risk it till there is something i am REALLY stuck with. any help would be appreciated
07-23-2002, 05:42 AM
Well, I could help more if I knew who the documentation was aimed at... and you really should ask your teacher. If he gets angry - then he's not doing his job properly and you can complain.
I know how you feel - my A level computing teacher was an idiot -I basically took the classes while he sat and fiddled with his laptop.. ;)
07-23-2002, 06:20 AM
This is how we do dcoumentation. Obviously this is in a company context, so I hope it has some relevance.
1. Feasibility study (don't know much about this - never done one). some thing along the lines of Is this humanly possible? Can our computers do it?
2. The next documentation in a project is the Project Definition. This is supplied as the reason for the software (i.e. your teacher has asked you to do a particluar project - this is the project definition)
3. Write a user requirement document.
The purpose of this document is to:
a. Clearly identify all the requirements that must be satisfied by this project.
b. Provide Systems Developers with sufficient detail of the Users requirements to enable them to produce a Software Design Description.
4. Software Design Description. The purpose of this document is to provide:
a. Sufficient detail of the proposed solution to advise Programmers.
b. An estimate of the development time.
c. The basis for acceptance testing.
5. Write a User guide explaining in concise clear non technical language what the software was designed to do and who should use it. Then explain the full functionality of the software.
Documentation seen by many as a chore, is a good habit to pick up if your are considering programming for a job. I hope this may have given you some ideas.
07-29-2002, 03:12 AM
ok, cool thanks. is there anything else to it?
does anyone know how to do a feasability study?
07-29-2002, 07:18 AM
Feasability is basically whether it is economically viable to produce the product. So, work out how much it would cost to produce it in the real world, then either how much profit could be made off it, or how much money could be saved by using it.
07-29-2002, 07:24 AM
To add to what Chief said, you also have to take lifetime into
consideration. If it known that the whole system would only be
used for 2 years, and it would take 3 years to get back the
original investment, it is a losing proposition. Sometimes there is
no single way to do what is needed without losing, so then it
becomes a matter of the method that loses the least.