system development methodology

[Verwijderd]

Hallo iedereen,

Als onderdeel van het System Development Methodology, zijn we hier een Data Flow Diagram aan het tekenen. Is het de conventie in het eerste niveau DFD de gegevensstromen tussen
procedures ook te tekenen, of is het de gang van zaken de gegevensstromen tussen de procedures
niet mee te tekenen?
Danwel, maakt het niet uit en kan ik doen waar ik zelf zin in heb?

groetjes,

digi42

[Mental]

Een standaard (wat DFD dus niet is) zal niet vaak zeggen 'doe maar waar je zin in hebt', DFD dus ook niet en dit is tot in den treure beschreven in de standaard van de methodiek waarvoor je de DFD maakt.
Welke documentatie / modeleer standaard gebruik je en waar heb je zelf al informatie ingewonnen?

[ Voor 24% gewijzigd door Mental op 13-06-2012 13:41 ]

[Verwijderd]

Mental schreef op woensdag 13 juni 2012 @ 13:40:
Een standaard (wat DFD dus niet is) zal niet vaak zeggen 'doe maar waar je zin in hebt', DFD dus ook niet en dit is tot in den treure beschreven in de standaard van de methodiek waarvoor je de DFD maakt.
Welke documentatie / modeleer standaard gebruik je en waar heb je zelf al informatie ingewonnen?

We gebruiken de SDM-TIS zoals die beschreven staat in het boek "systeemontwikkeling 1" van
Vogelaars en Merk. ( die zegt dingen als "in het eerste niveau worden de buitenwerelden niet meegenomen"
en "zorg voor drie tot zeven processen in het eerste niveau" ) .

Het lijkt me logisch alle gegevensstromen te tekenen, maar ik geloof dat ik ergens gelezen heb
dat dat niet hoeft, al weet ik niet meer waar.

groetjes,

digi42

[Mental]

Je kunt jezelf afvragen hoe handig een flowchart is zonder 'flow', als je dat gedaan hebt weet je precies waarom je die vraag nooit meer moet stellen

[Verwijderd]

Mental schreef op woensdag 13 juni 2012 @ 13:52:
Je kunt jezelf afvragen hoe handig een flowchart is zonder 'flow', als je dat gedaan hebt weet je precies waarom je die vraag nooit meer moet stellen

Daarnaast denken we hier dat we best een eigen draai aan het SDM kunnen geven.
Ik teken wel

[Bartjeh]

Mental schreef op woensdag 13 juni 2012 @ 13:52:
Je kunt jezelf afvragen hoe handig een flowchart is zonder 'flow', als je dat gedaan hebt weet je precies waarom je die vraag nooit meer moet stellen

DFD != flowchart. Alhoewel ik het fijne er niet van uit kan leggen

[D-Raven]

Allereerst, tweakers groeten elkaar altijd, je hoeft het dus niet in je post expliciet te doen

Verwijderd schreef op woensdag 13 juni 2012 @ 13:51:
[...]
We gebruiken de SDM-TIS zoals die beschreven staat in het boek "systeemontwikkeling 1" van
Vogelaars en Merk.

Dit boek heb ik thuis ook liggen... gekocht toen ik in t eerste jaar van mn opleiding zat, alweer bijna 8 jaar geleden... ik vond het toen al een vaag frut boek en als ik jou reactie zo lees, is het er niet veel beter op geworden.
Software ontwikkeling ala waterval methode, waarbij je alles van te voren tot in de details moet gaan verzinnen, terwijl vaak de opdracht die je krijgt van zichzelf al vaag genoeg is...

( die zegt dingen als "in het eerste niveau worden de buitenwerelden niet meegenomen"
en "zorg voor drie tot zeven processen in het eerste niveau" ) .

Het lijkt me logisch alle gegevensstromen te tekenen, maar ik geloof dat ik ergens gelezen heb
dat dat niet hoeft, al weet ik niet meer waar.

Vergeet die regel. Ga gewoon globaal nadenken over uit welke onderdelen je applicatie zal bestaan. En teken daar de informatie stromen tussen (een pipeline genaamd communicatie zou genoeg moeten zijn ). DFD 0 moet je zien als het beschrijven van je applicatie processen in brede stroken.
DFD 1 ga je in iets meer detail in op je processen, DFD 2, etc etc.

owja... en gecondoleerd... IMHO is SDM-TIS het meest onrealistische en belachelijke methode ever verzonnen om mee te werken.
Bij normaal software development ga je niet al meteen tot in de detail verzinnen hoe je app zijn interne processen gaat werken, totaal onrealistisch, veranderd toch weer tegen de tijd dat je het daadwerkelijk gaat ontwikkelen.
Mijn apps leken ook altijd in verste verte niet op wat ik in code had, en wat ik in mn DFD's had beschreven..

[/latente opleidings frustratie]

[Verwijderd]

jah dan ben ik blij dat ik met behulp van het DFD een bestaande applicatie aan het documenteren ben.
( dus of het SDM SDM2 of SDM-TIS is maakt mij allemaal niet uit )

merk op dat ik op dit moment er wel uitkom

[The Eagle]

Kort antwoord: Nee, in het eerste niveau van een DFD zet je geen datastores of whatever. Simpelweg omdat je op het eerste niveau de processen op hoofdlijnen beschrijft. Zou je dan datastores oid moeten gaan gebruiken, dan worden je verzamelingen van data wel erg groot
De integratie tussen de subprocessen wek je pas op een lager niveau uit. daar heb je WEL een datastore nodig, en dat kan ook, omdat je dan al op grote lijnen weet welke subprocessen er welke data nodig hebben

Maar als het goed is staat dat ook allemaal in je boek

[Kwistnix]

D-Raven schreef op woensdag 13 juni 2012 @ 15:43:

Dit boek heb ik thuis ook liggen... gekocht toen ik in t eerste jaar van mn opleiding zat, alweer bijna 8 jaar geleden... ik vond het toen al een vaag frut boek en als ik jou reactie zo lees, is het er niet veel beter op geworden.
Software ontwikkeling ala waterval methode, waarbij je alles van te voren tot in de details moet gaan verzinnen, terwijl vaak de opdracht die je krijgt van zichzelf al vaag genoeg is...

[..]

owja... en gecondoleerd... IMHO is SDM-TIS het meest onrealistische en belachelijke methode ever verzonnen om mee te werken.

Ik deel die frustratie
Ook ik heb op m'n opleiding SDM-TIS geleerd uit dezelfde boekenreeks.
Tragisch. Daarbij heb ik de methodiek in de praktijk nog nooit toe gepast.

[The Eagle]

Wij kregen destijds (1997) Yourdon - Gestructureerde analyse.
Ofschoon het watervalmodel best leuk bedacht, maar - zeker in mijn line of work - niet praktisch is, biedt het wel een verdraaid goede basis om e.e.a. te modelleren

Dat voor een dergelijk model in de praktijk nooit tijd is, is een ander verhaal

[Remus]

The Eagle schreef op donderdag 14 juni 2012 @ 21:00:
Wij kregen destijds (1997) Yourdon - Gestructureerde analyse.
Ofschoon het watervalmodel best leuk bedacht, maar - zeker in mijn line of work - niet praktisch is, biedt het wel een verdraaid goede basis om e.e.a. te modelleren

Dat voor een dergelijk model in de praktijk nooit tijd is, is een ander verhaal

Het watervalmodel is in de jaren 70 bedacht door een onderzoeker als illustratie in een paper om aan te geven dat zo'n werkwijze dus juist niet werkt. Grappig (of eigenlijk: treurig) dat het daarna vaak als voorbeeld is gebruikt hoe het wel moet.

Overigens zijn een aantal van de elementen van Yourdon ook prima te gebruiken in een agile omgeving. Je moet er alleen - net zo als met alles - met beleid en terughoudendheid mee omgaan.