As part of a course assignment, I am learning how to use the different types of professional writings that are pertinent to my desired field of employment. I am interested in learning what types of documents you must prepare as a Computer Programmer and the purpose of those documents. Can anyone give me a few examples and an explination of those examples? Any help would be greatly appreciate.
I'm not a working programmer, but I've worked in a Systems/Operations environment in the city and I can give you an example of what, we, on the operations side .......... to the systems side about on their documentation. Also, beyond documentation for the end-user, you also must provide (much more thorough) documentation to the people maintaining your system. To the end user you provide a simple to follow explaination on how to navigate through your system, any options available to suit their personal needs, and definitely troubleshooting on any bugs they might run into. Think of Windows Help system... like that except not as crappy.
To the maintainance programmers, and I can't answer this as fully as a working programmer, you have to provide thorough analysis of the classes and methods designed in the system. Where they are defined and where they are used. I suppose you should also explain any implementations you have in your class if you have more than one... I'm not sure what else to say, but I'm sure there is much more. I'll leave the rest to a working programmer.
Sent from my iPadŽ
Code:------------------------- | | | WILL WORK | | FOR | | FOOD | ------------------------- || || ||
That's the documentation for the unsuccessful programmers.Originally Posted by 7stud
Sent from my iPadŽ
> Can anyone give me a few examples and an explination of those examples?
Requirements - defines 'what' you're going to do.
Eg. the calculator will provide a means of entering numbers
The calculator will support the primary mathematic operations add, ...
Design - defines 'how' you're going to do it.
Some waffle about on-screen keys or keyboard input
Maybe some UI diagrams.
Any particular algorithms, say for factorial or large integer maths
Test - defines how you will prove that the implementation matches the requirement.
A list of things to do - press the 1 * 2 = keys and observe the answer 2
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I've been working as a programmer for a year, and had 3 years of computer labs in college before that.
The documents for both were pretty much the same.
PRE GAME DEVELOPMENT:
1. Game Description/Analysis - A complete description of what the game is about, what some key features are.
2. Game Requirements - This is not only what the "goal" system requirements of the game are, but also the requirements of what it would take to create this game, ex: Computer types, Software, etc.
3. Flow Charts - These are a step by step depiction of what will happen during the game. Here is a good site that describes this more: http://deming.eng.clemson.edu/pub/tu...ools/flowm.htm
DURING DEVELOPMENT:
1. Well for me, it's hundreds of pages of notes. I will start the day by making a "To Do list", and crossing out each item as it is completed. Then the next day, I simply start a new "To Do list" with the items that weren't crossed out, adding in anything new that needs to be done.
The other notes are little bits of information I jot down while designing the game. Sometimes it's variable names, sometimes it's a new flow chart for a specific function, etc.
AFTER DEVELOPMENT:
1. Documentation - This is what one might call a "manual". It has the game description, key features, minimum system requirements, etc.
--------
This is just the documentation that I use, I'm not speaking for all programmers. I'm sure at larger companies with many programmers, they probably use documentation for meetings, etc.
Hope this helps.
it all depends on the company.
You may have to write nothing, everything from the functional specs to the end user documentation, or anything in between.
Well for me, it isn't possible to write nothing for a big project.
Design and formulas I almost always have to write out on paper first.
I think something important you could include is that programming is done more on paper than most people think.
I would say in average, on the game I'm working on now for Silak Gaming, I write 50% on paper, and 50% in the computer.
At our company, the product manager (not a programmer) writes the requirements. The QA manager writes the test plan. We, the developers, write a design document only for large projects. I haven't had to write a design document in years because I have been focused on adding features to an existing product. All I write our emails upon emails describing existing functionality, clarifying the design documents, or identifying bugs.
The documents that we write are generally written in Word and have an introduction and several sections for the different requirements or design decisions. Even for design documents we never go into real detail, it is all about high-level design decisions.
Thanks for all the help!
