4 Replies - 921 Views - Last Post: 08 October 2010 - 04:36 AM

#1 Larsonator  Icon User is offline

  • D.I.C Head

Reputation: 6
  • View blog
  • Posts: 77
  • Joined: 13-August 10

out of curiosity

Posted 07 October 2010 - 05:49 AM

im eager to know how the system works when developing programs for a company.
i mean, obviously, each company has is own way of going about it.

for example,
do you each ge a certain part to complete, and you all put it together at the end, following a UML diagram?

how do ya test that your part works?
or you just write supder dooper code that just works when you put it togeather?
or do you write your part, put it togeather, and then iron out the errors?

i mean, iv had group work before, but its only been in a pair, and projects have never been all that big.

so i was just wondering, or looking for some sort of insight into the industry its self, from people who work in the industry.

Is This A Good Question/Topic? 1
  • +

Replies To: out of curiosity

#2 Shane Hudson  Icon User is offline

  • D.I.C Technophile
  • member icon

Reputation: 343
  • View blog
  • Posts: 1,286
  • Joined: 06-December 09

Re: out of curiosity

Posted 07 October 2010 - 08:10 AM

Well, whether or not this is correct I am not sure but I know at college we are taught there are different methodolgies. These include RAD (Rapid Application Development), Agile and Spiral. Might be worth looking into those?
Was This Post Helpful? 0
  • +
  • -

#3 Brewer  Icon User is offline

  • Awesome
  • member icon

Reputation: 179
  • View blog
  • Posts: 1,044
  • Joined: 14-June 10

Re: out of curiosity

Posted 07 October 2010 - 08:44 AM

My understanding is that it varies, mainly based on company size. You have your small start-ups which has 1-5 programmers (estimation) who will work together to make an entire program, each working on certain pieces. Then you have your corporations like Google where you are working with literally thousands of other Software Engineers and each of you is working on a very small piece for a very large project.

It can go either way, depending on where you work!
Was This Post Helpful? 0
  • +
  • -

#4 Larsonator  Icon User is offline

  • D.I.C Head

Reputation: 6
  • View blog
  • Posts: 77
  • Joined: 13-August 10

Re: out of curiosity

Posted 07 October 2010 - 08:35 PM

mmm yeah i realise that the different methodologies can depend on the company, what sort of programs they create and such.

but when it comes to creating small parts of a program, im givin to understand that you have a rather detailed report of firstly what the program is to do, which is broken down into a uml, and ultimately a description for each variable and functions.

i suposed with such a document, there isnt much room for error in the coding, but say for inexperiences programmers still learning such as my self, who is still studying at uni, and i cant really talk for everyone else, but i find that my course does not really focus on the planning side of a project. Most assesment, your giving a detail of what the program is ment to do, and what language it is to be writtin in. but there is no requirement for any documentation for the project.

hense many students dont follow any documentation, and purely follow the requirement of the project specifications.

i personaly, try to design some soft of documentation writting in paper, a rachonel if anything, of what each functoin needed is ment to do.

but its usualy not detailed, hense when i come around to making my project, its mostly from my head, and multiple parts are designed at once, purely to solve small parts of what the project is ment to do, and the expanded as i go, as i had more functionality.

while i may increase the skill in debugging, how do you supose one would addapt when they join the industry?

personly the part i hate most in any project is writing up a test report.
Was This Post Helpful? 0
  • +
  • -

#5 Bench  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 856
  • View blog
  • Posts: 2,339
  • Joined: 20-August 07

Re: out of curiosity

Posted 08 October 2010 - 04:36 AM

Even within a single organisation, the approach to individual projects can vary widely (especially where there are multiple teams working on multiple different projects). There are some common themes/practises which most software developers will follow as a matter of course, but there is no one-size-fits-all answer to this question, nor are there any "development lifecycle" models which can truly accurately describe how you should approach a project, since it is as much down to a person's preferred way of working as it is to the project itself.

This is one reason perhaps why Universities generally don't give you too much guidance on the specifics of how to complete a project (Also probably because they want you to "think" for yourself). In general, all projects will start out with some description of a problem to solve, so many universities will insist you start out your development effort with a statement of requirements which you are aiming to meet. Even for a medium/large project, this might only be a few pages with a bunch of bullet-points with some vague high-level feature descriptions.

The next logical step is to investigate each of the requirements (This could involve building prototypes or test programs already, to try to understand exactly what you need to do); building upon them to create your specification. This is possibly the most important document for any project - its the document which gives nontechnical detail about what your solution must eventually do. Again, there's no standard way of writing a specification - you'll probably want a little bit of high-level "block" architecture and a description of end-user functionality, as well as all the other little bits which go on the side such as compatibility, hardware/software dependencies etc.
(Incidentally, you could look on the internet for "template" documents to use - they might help you if you get stuck trying to work out what kind of content/detail needs to go in your specification)

The next step after having a reasonably well-formed specification is pretty much open. It might be a good idea to come up with a rough design; if you've got a bunch of isolated prototypes, then you'll probably be in a position to bang together a rough framework.
Design, development and testing usually work well when they're done side-by-side - keeping everything in small, managable increments should help you stay on track. After one or two increments you'll likely have a much better understanding of your initial requirements too; which means you may need to go back and rewrite parts of your specification to reflect anything you've since discovered.

The most important thing to do with any project is to keep open communications with anybody who is involved with your effort. for a student project, that almost certainly means keeping your tutor informed on your progress - including any new information you've found out, any problems you've had, any changes you're making, and also asking for help when you need it. (It might also mean keeping in touch with other students who you're collaborating with). Most projects which fail usually do so because information stopped flowing between people. This is just as true in the 'real world' as it is in university.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1