ik neem aan dat dit het juiste forum is, voor een applicatie dient een functioneel ontwerp te worden geschreven. hier heb ik nog geen template voor. nu wilde ik hiervoor de 'yourdon' (voorganger hatley phirbay) methode gebruiken. kan dit, oftewel is dit gebruikelijk voor een software project. zoniet, zijn er evt andere goede methodes.
Ik pak altijd gewoon Word en een paar kladjes
Serieus: heb je een goede reden om formele methoden te pakken, dwz. vraagt de klant erom, of werk je in een (groot) team of zo? Als je alleen aan een project gaat werken is de kladje-approach met wat UML diagrammetjes en wat kriebels in Word meestal een stuk sneller en bruikbaarder.
Serieus: heb je een goede reden om formele methoden te pakken, dwz. vraagt de klant erom, of werk je in een (groot) team of zo? Als je alleen aan een project gaat werken is de kladje-approach met wat UML diagrammetjes en wat kriebels in Word meestal een stuk sneller en bruikbaarder.
het is voor een opdracht voor een bedrijf
voor het technisch ontwerp ga ik inderdaad uml schema's gebruiken.
het functioneel ontwerp is in principe af, alleen niet erg samenhangend, ik dacht als ik het in een yourdon vorm giet (wat wel mogelijk is) wordt het mooi geheel, nu wilde ik weten of dit gebruikelijk was...
voor het technisch ontwerp ga ik inderdaad uml schema's gebruiken.
het functioneel ontwerp is in principe af, alleen niet erg samenhangend, ik dacht als ik het in een yourdon vorm giet (wat wel mogelijk is) wordt het mooi geheel, nu wilde ik weten of dit gebruikelijk was...
Als het bedrijf er niet expliciet om vraagt zou ik mezelf de moeite besparen...
ok goed, maar kan zo'n yordon methode nou of niet...
Verwijderd
Tuurlijk kun je Yourdon gebruiken voor een fo! Heb het eigenlijk alleen op de Haagse Hogeschool gebruikt. In de praktijk zijn het al snel een paar kladjes. Of reverse documenteren. Eerst bouwen dan beschrijven
Yourdon is vooral handig als een andere partij de app gaat bakken.
Cheers
Cheers
Het zal wel aan mij liggen hoor.. maar "Yourdon" (we hebben het hier over "Gestructureerde Analyse") geeft hulpmiddelen, ideeen en technieken aan om te gebruiken, maar heeft het in heel zijn boek niet over een FO (of een TO).
Als je een FO gaat schrijven kan je bepaalde technieken die in het boek staan gebruiken, maar die technieken alleen maken geen FO (of TO)
De methode Yourdon bestaat niet... je kan Yourdon wel inpassen in een bestaande methode.
Als je volgens het boek een Essention Model, enviromentel model en een gebruikersimplementatie model hebt gemaakt ben je een eind opweg naar een "volledig" FO, maar wat er precies in het FO komt te staan is afhankelijk van de gebruikte methode (bijv. SDM)
Wat verwacht het bedrijf van je TO? Welke methoden gebruikt het bedrijf zelf? Welke methode heb jij gebruikt? (zo te zien de JBF methode... (Jan Boeren Fluitjes
)
Als je een FO gaat schrijven kan je bepaalde technieken die in het boek staan gebruiken, maar die technieken alleen maken geen FO (of TO)
De methode Yourdon bestaat niet... je kan Yourdon wel inpassen in een bestaande methode.
Als je volgens het boek een Essention Model, enviromentel model en een gebruikersimplementatie model hebt gemaakt ben je een eind opweg naar een "volledig" FO, maar wat er precies in het FO komt te staan is afhankelijk van de gebruikte methode (bijv. SDM)
Wat verwacht het bedrijf van je TO? Welke methoden gebruikt het bedrijf zelf? Welke methode heb jij gebruikt? (zo te zien de JBF methode... (Jan Boeren Fluitjes
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
ik zie wat je bedoelt... ik maak idd gebruik van sdm, waarbij ik me dus op dit moment in de ontwerpfase bevind. in deze ontwerpfase ga ik dus beschrijven hoe de applicatie technisch in elkaar steekt, danwel functioneel. eerst functioneel. functioneel ontwerp is in princiope dus het document van eisen. hierin staat exact beschreven wat het programma kan, en wat er wanneer precies gebeurt. om dit functionele ontwerp te vervolmaken wil ik deze functionaliteiten dus ook nog onderbrengen in dfd schema's met de bijbehorende beschrijvingen volgende yourdon (ik zie wel in dat dit niet echt een methode is, maar meer een soort van beschrijving). nu wilde ik dus weten of dit vaker gedaan is binnen? ik hoop dat duidelijker is, of heb ik echt iets gemist tijdens de les...?
Verwijderd
In principe is er geen een echt vaste methodiek.
Yourdon,(D)Sdm,RUB(<- een goeie nieuwe gebaseerd op allerlei UML notaties)
+
Gezond verstand is zeker minstens zo belangrijk.
- Wat documenteer,diagrammeer,etc ik
- Hoe diep ga ik, je kunt alles tot de comma uitwerken maar houdt er rekening mee dat je dan in de praktijk nooit code/docs synchroon kan houden wat alleen maar verwarrender werkt.
Zelf houdt ik van :
1. Use cases = fijn manier van requirement engineering alleen niet die stomme UML plaatjes gebruiken, gewoon uitschrijven.
2. Package/Class diagrams = opdelen van probleem in 'hapklare brokken'
3. Activity diagrams = sequence + Flow diagram (welke object doen wat in welke volgorde)
Yourdon,(D)Sdm,RUB(<- een goeie nieuwe gebaseerd op allerlei UML notaties)
+
Gezond verstand is zeker minstens zo belangrijk.
- Wat documenteer,diagrammeer,etc ik
- Hoe diep ga ik, je kunt alles tot de comma uitwerken maar houdt er rekening mee dat je dan in de praktijk nooit code/docs synchroon kan houden wat alleen maar verwarrender werkt.
Zelf houdt ik van :
1. Use cases = fijn manier van requirement engineering alleen niet die stomme UML plaatjes gebruiken, gewoon uitschrijven.
2. Package/Class diagrams = opdelen van probleem in 'hapklare brokken'
3. Activity diagrams = sequence + Flow diagram (welke object doen wat in welke volgorde)
Verwijderd
Als je alleen maar UML gaat gebruiken voor je TO dan wordt dat een weinigzeggend TO, maar goed....
Voor FO kan ik use cases erg aanbevelen. Duidelijk en overzichtelijk. Aanvullen met beschrijving van de UI. Voor de rest hoeft er in een functioneel ontwerp niet zo veel te staan, gewoon beschrijving van wat het doet en hoe het er uit ziet.
In TO beschrijf ik
- Class Diagram / functiematrix
- Program Flow Diagram
- Error handling
- Logging/tracing
- Relaties met andere programma's (environment)
- Externe interfaces
- Overzicht deliverables + sources + compiler/linkersettings etc.
Vergeet ook niet een testplan te maken (FAT testplan op basis van FO, systeemtestplan op basis van TO), iets wat toch echt erg belangrijk is en waar vaak niet zo op word gelet.
Prettig om te zien dat er voor dit onderwerp toch nog zoveel belangstelling is (ik weet uit ervaring dat documentatie de eerste fase is in een project waar uurtjes vanaf gesnoept worden als men in tijdnood komt)
Voor FO kan ik use cases erg aanbevelen. Duidelijk en overzichtelijk. Aanvullen met beschrijving van de UI. Voor de rest hoeft er in een functioneel ontwerp niet zo veel te staan, gewoon beschrijving van wat het doet en hoe het er uit ziet.
In TO beschrijf ik
- Class Diagram / functiematrix
- Program Flow Diagram
- Error handling
- Logging/tracing
- Relaties met andere programma's (environment)
- Externe interfaces
- Overzicht deliverables + sources + compiler/linkersettings etc.
Vergeet ook niet een testplan te maken (FAT testplan op basis van FO, systeemtestplan op basis van TO), iets wat toch echt erg belangrijk is en waar vaak niet zo op word gelet.
Prettig om te zien dat er voor dit onderwerp toch nog zoveel belangstelling is (ik weet uit ervaring dat documentatie de eerste fase is in een project waar uurtjes vanaf gesnoept worden als men in tijdnood komt)
Pagina: 1