Archief - Taken/Opdrachten programmeur (bedrijfswereld)

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
B

Bosman.jr

Legacy Member
Beste,

In de schoolboeken staat alles mooi uitgelegd van maak deze klas aan, creëer dit object, ...

Hoe krijg jij je taken/opdrachten voorgeschoteld in de bedrijfswereld?

Is dit aan de hand van bijvoorbeeld uml-diagrammen, gewoon een papier waar staat wat het moet kunnen en ga je gang of hoe mag ik mij dit voorstellen?

Met vriendelijke groeten,
T

Tyfius

Legacy Member
Dat hangt van bedrijf tot bedrijf en van project tot project af.

Je hebt projecten waar alles op voorhand uitgetekend en uitgeschreven wordt en je in principe maar de tekst moet omzetten in code. Langs de andere kant heb je projecten waar je alleen een vage omschrijving krijgt van wat het moet kunnen en ben je op jezelf of je team aangewezen om dat zo goed mogelijk uit te werken.
J

Jerre Muesli

Legacy Member
Meestal bestaat er enkel een db schema van een analyst en een document van requirements. Maar zaken als sequence diagrammen enzo moet ge in elk geval niet verwachten.
D

Dastardly

Legacy Member
in kleinere bedrijven krijg je vaak al die specifieke zaken niet. eerder functionele omschrijving wat er moet gebeuren (neem een factuur. bedragen zijn a,b en c. naargelang d en e moet de btw anders worden berekend, indien c dan moeten er administratieve kosten bij). nadien ga je gewoon je gang op de manier die jij het beste acht.

programmeren is geen exacte wetenschap. dat merk je ook als je met enkele mensen samenwerkt aan een project. je kan er zo uithalen wie welke code heeft geschreven.

uml diagrammen en consoorten komen zelden voor zover ik weet. misschien dat het bij bepaalde "strikte" jobs meer voorkomt (banken e.d.), maar bij de normale jobs zal het inderdaad eerder een simpele analyse zijn met eventueel db structuur.
K

Krueger

Legacy Member
Wij gebruiken soms wel eens een UML- of sequence diagram om te brainstormen, en wat van ideeën te wisselen. Maar dan gaat het meestal over een bepaalde beperkte functionaliteit, en is het schema dus ook wel beperkt in grote (grootorde 2-8 blokken ofzo). Om UML zo te gebruiken vind ik het zeker nuttig.

Echt gigantische A1's maken met UML doen we echt nooit. Voor een volledig programma op voorhand in UML uit te tekenen zou zeer lang duren, en na een beetje programmeren zou je al rap merken dat je dingen over het hoofd hebt gezien, waardoor delen van je UML toch waardeloos worden.
C

Cycloon

Legacy Member
Het hangt er ook heel sterk af van op welk project je werkt. Als je ergens een standalone stukje software moet maken dan zal er meestal geen haan om kraaien hoe het gemaakt wordt. Moet je echter aan groot stuk ERP-software meehelpen dan zijn er vaak grote uitgetekende lijnen en regels om te volgen. Schema's zijn dan vaker voor handen omdat er al verscheidene analisten hun visie hebben losgelaten op het probleem. Alles is dus gewoon héél sterk context-afhankelijk. Als wij bv. consultants hadden lieten we sommigen gewoon begaan (diegene die duidelijk kwaliteitsvolle code konden afleveren), anderen moesten we dan volop supporteren met klassen- en sequencediagramma om toch maar iets van redelijke code te krijgen.
f

fat-beavis

Legacy Member
Wij maken ons eigen pakket om toegangscontrole te realiseren, wij krijgen ons werk aan de hand van BUG tickets die we doorkrijgen van de testers of van de personen die de ondersteuning bieden aan de software ( helpdesk dus ).

Wij hebben ook 1 a 2 analisten die zelf ook mee programmeren.
w

woony

Legacy Member
Dastardly zei:
in kleinere bedrijven krijg je vaak al die specifieke zaken niet. eerder functionele omschrijving wat er moet gebeuren (neem een factuur. bedragen zijn a,b en c. naargelang d en e moet de btw anders worden berekend, indien c dan moeten er administratieve kosten bij). nadien ga je gewoon je gang op de manier die jij het beste acht.

programmeren is geen exacte wetenschap. dat merk je ook als je met enkele mensen samenwerkt aan een project. je kan er zo uithalen wie welke code heeft geschreven.

uml diagrammen en consoorten komen zelden voor zover ik weet. misschien dat het bij bepaalde "strikte" jobs meer voorkomt (banken e.d.), maar bij de normale jobs zal het inderdaad eerder een simpele analyse zijn met eventueel db structuur.
Klik om te vergroten...

second
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan