Turn on thread page Beta
    • Thread Starter
    Offline

    2
    ReputationRep:
    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.
    Offline

    18
    ReputationRep:
    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..
    • Thread Starter
    Offline

    2
    ReputationRep:
    (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.
    Offline

    7
    ReputationRep:
    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.
    Offline

    18
    ReputationRep:
    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.
 
 
 
Reply
Submit reply
Turn on thread page Beta
Updated: December 19, 2017

2,683

students online now

800,000+

Exam discussions

Find your exam discussion here

Poll
Should predicted grades be removed from the uni application process

The Student Room, Get Revising and Marked by Teachers are trading names of The Student Room Group Ltd.

Register Number: 04666380 (England and Wales), VAT No. 806 8067 22 Registered Office: International House, Queens Road, Brighton, BN1 3XE

Write a reply...
Reply
Hide
Reputation gems: You get these gems as you gain rep from other members for making good contributions and giving helpful advice.