Project documentation help

Watch this thread
thirteen13stuff
Badges: 2
Rep:
? You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#1
Report Thread starter 4 years ago
#1
So I have already chosen a project and am currently messing around with the library to get a feel for it. At some point, I need to start the documentation... but I don't know how. Right now, all I have is the problem definition and justification, and I'm confused as to how to proceed. My teacher hasn't been much help; he's pretty much told our class to write some pseudocode for a UI that doesn't really need any pseudocode.

Basically, it would be really helpful if someone could provide maybe a bullet point list of just the first few things I need to cover.
0
reply
winterscoming
Badges: 19
Rep:
? You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#2
Report 4 years ago
#2
I'd think it depends what type of documentation you're expected to write. Is there any detail in the mark scheme?

For example, Is it a report to describe the things you've learned and/or the problems you've had creating the project? Or is it documentation about the app itself? for example - User documentation, Requirements analysis, Design specification, Test docs..
0
reply
thirteen13stuff
Badges: 2
Rep:
? You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#3
Report Thread starter 4 years ago
#3
(Original post by winterscoming)
I'd think it depends what type of documentation you're expected to write. Is there any detail in the mark scheme?

For example, Is it a report to describe the things you've learned and/or the problems you've had creating the project? Or is it documentation about the app itself? for example - User documentation, Requirements analysis, Design specification, Test docs..
From what I understand, it seems to be a mish-mash of both. So I have to analyse the problem, state the criteria etc. and then when I'm building the actual program, show my thought process and various problems I will encounter and overcome.

I imagine it will get easier to write as I get going, but right now, I can't seem to figure out how to start.
0
reply
username2808788
Badges: 7
Rep:
? You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#4
Report 4 years ago
#4
Basically just follow the SDLC (Software Dev Life Cycle) and just keep writing bull**** about your program based on these principles, but start with each stage and pick a good model (e.g. Waterfall model) that require most of these principles. I am assuming you have a project set and you must follow these procedures in order to write a good documentation of that program/project.
0
reply
winterscoming
Badges: 19
Rep:
? You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#5
Report 4 years ago
#5
The report about your thought process is something which only you can really decide upon, but the other documentation is usually fairly standard, because it's based on the kinds of things which apply to any project

  • User Doc - imagine you're sitting down to explain what your program is to someone who has never used a computer before and doesn't know anything about your app. Or alternatively, imagine somebody has given you an app without telling you what it's for or why it exists, and it's your job to figure out what it is and how to use it. Think about screenshots, explaining terminology, step-by-step workflows, etc.
  • Requirements - You've already got your problem statement, so consider the use-case(s) for the app at a high level - i.e. nothing about how the app actually works, just describe the features and functionality that it needs to support, related to the problem/s you've defined. Usually requirements are written in pure "user speak" - i.e. language which a normal person can understand, and little or no technical detail
  • Project planning - depending on how big your project is, you might pick up marks for describing the development process you're following, listing the tasks which need to be done, and loosely what they involve. (you might argue that documentation is a task too, because it takes up quite a lot of time)
  • Test Docs - A bit like a logical extension to the requirements, except a lot more specific detail about how to actually validate and verify that all the features and functions you've implemented are working correctly - i.e. Imagine a customer sitting down in front of your app wanting to know (without knowing a single thing about your code) that the app does everything s/he expects - e.g. how it behaves on invalid data input, how it handles critical errors like a loss of network , or missing configuration files
  • Design Spec - Think about another programmer reading your code and the information they would need to know to be able to understand why you've structured the code in a particular way, and why you've taken the decisions you've made. for example, what are the benefits of the way you've organised and structured the code, what are the limitations, why you used a particular design pattern to solve a problem, or why you chose to use a particular kind of data format for something, what the alternatives were and the trade-offs between them etc. Put yourself in the shoes of somebody who knows nothing about your code, reading it for the first time, and how they might not immediately understand what happened to be going through your head at the time you'd written the code.


Also, don't necessarily worry about writing documentation in a particular order. Documentation usually isn't ever really 'done' until the code is done and tested. Documentation changes when you're halfway through a project and find out your original assumptions are wrong about the requirements, or your original ideas about design aren't going to work, or you decide you've found a better way to do it which doesn't fit, etc. A lot of documentation is usually easier to write when the code is done, even if you have to pretend for the sake of your course or mark scheme that you'd written all the documentation before writing the code.
0
reply
X

Quick Reply

Attached files
Write a reply...
Reply
new posts
Back
to top
Latest
My Feed

See more of what you like on
The Student Room

You can personalise what you see on TSR. Tell us a little about yourself to get started.

Personalise

Y13's - If you haven't confirmed your firm and insurance choices yet, why is that?

I am waiting until the deadline in case anything in my life changes (18)
20.69%
I am waiting until the deadline in case something else changes (e.g. exams/pandemic related concerns) (11)
12.64%
I am waiting until I can see the unis in person (5)
5.75%
I still have more questions before I make my decision (15)
17.24%
No reason, just haven't entered it yet (19)
21.84%
Something else (let us know in the thread!) (19)
21.84%

Watched Threads

View All