[ALG] Functioneel ontwerp

[kaandorp]

Als je gaat beginnen met het ontwerp van een webpagina, webapplicatie, o.i.d. maak je mijns inziens altijd eerst een functioneel ontwerp (FO). Hebben jullie nog tips hierover? Wat komt er allemaal in te staan? Wat komt er vooral NIET in te staan.

Graag in normaal te begrijpen taal. Zodat het ook voor de gemiddelde thuisklusser ook een mooie richtlijn is.

[TheDane]

mwah, ik zou toch eerst de user requirements eens analyseren

[Dido]

Beetje moeilijk om heel kort een overzicht te geven.
Een FO beschrijft WAT er moet gebeuren, maar niet HOE.

Er staat dus niet in wat voor programma's je gaat maken, wat voor taal(en) je gebruikt, wat voor herbruikbare componenten je onderkent, wat je gebruikt als database, etc.

Wat er wel in komt is dus wat de gebruiker wil. Bijvoorbeeld: een pagina met informatie. Met een mogelijkheid om specifieke dingen op te zoeken. Opzoeken moet op meerdere criteria mogelijk zijn. Sommige informatie mag alleen toegankelijk zijn voor sommige gebruikers.

In plaats van een technisch datamodel maak je en functioneel datamodel, waarbij je dus alleen rekening houdt met de functionaliteit van je gegevens, en niet met technicaliteiten als gegenereerde unieke sleutels e.d.

[PdeHoog]

Toevallig zijn we er net mee bezig op school . Ik geef een verkorte samenvatting (volgens Yourdon / SDM):

- Organisatorische aanpassingen (Hoe ziet de organisatie waarvoor de applicatie ontwikkeld wordt er na implementatie uit? Dienen er aanpassingen in de organisatie gemaakt te worden? Dat is natuurlijk geheel niet van toepassing voor een hobbyist )

- Functionele specificaties (denk aan een beschrijving van af te handelen gebeurtenissen, pre- en postcondities van alle "events" / functies, een overzicht door wie of wat welke functies worden gedaan (het zog. processormodel))

- Functioneel gegevensmodel (Hoe ziet mijn gegevensmodel eruit? Welke relaties liggen er tussen de diverse gegevens?)

- Interface-beschrijving (hoe ziet mijn interface eruit?, welke richtlijnen hanteer ik?, hoe werkt mijn navigatie?, in welke volgorde worden schermen getoond? etc. etc. etc.).

Een FO is vooral NIET technisch, maar puur functioneel geblaat met allemaal gave modelletjes (DFD's, ERD's, Processchema's) waar alle managers op kicken.

[dusty]

Op woensdag 17 april 2002 12:56 schreef PdeHoog het volgende:
[..]
(DFD's, ERD's, Processchema's)
[..]

Voor de mensen die de afkortingen niet kennen:
DFD= Data Flow Diagram.
ERD = Entity Relation Diagram.

[PdeHoog]

Op woensdag 17 april 2002 13:20 schreef dusty het volgende:

[..]

Voor de mensen die de afkortingen niet kennen:
DFD= Data Flow Diagram.
ERD = Entity Relation Diagram.

Sorry! Effe vergeten.:z

[Bosmonster]

Op woensdag 17 april 2002 12:56 schreef PdeHoog het volgende:

Een FO is vooral NIET technisch, maar puur functioneel geblaat met allemaal gave modelletjes (DFD's, ERD's, Processchema's) waar alle managers op kicken.

Een ERD is niet technisch? Een ERD is al een heel stap te ver en hoort thuis in een TO imho. In een FO voor een website hoort bijvoorebeld wel het interaction design. Dus navigatie en schermbeschrijvingen. Maar weer geen grafisch ontwerp.

Oftewel alles waar een klant mee in moet stemmen voor je gaat bouwen om geen tijd weg te gooien. En een klant goedkeuring laten geven over iets als een ERD lijkt me niet zo'n goed idee Als zi'n kennis zover was dat ie wist wat een ERD was dan had ie zelf waarschijnlijk wel de site grotendeels zelf kunnen bouwen..

[PdeHoog]

Op woensdag 17 april 2002 17:37 schreef Bosmonster het volgende:

[..]

Een ERD is niet technisch? Een ERD is al een heel stap te ver en hoort thuis in een TO imho. In een FO voor een website hoort bijvoorebeld wel het interaction design. Dus navigatie en schermbeschrijvingen. Maar weer geen grafisch ontwerp.

Oftewel alles waar een klant mee in moet stemmen voor je gaat bouwen om geen tijd weg te gooien. En een klant goedkeuring laten geven over iets als een ERD lijkt me niet zo'n goed idee Als zi'n kennis zover was dat ie wist wat een ERD was dan had ie zelf waarschijnlijk wel de site grotendeels zelf kunnen bouwen..

Ik heb hier de theorie zoals ik die uit Yourdon / SDM haal beschreven. Zij schrijven dat de te gebruiken gegevensstructuren (vastgelegd in het ERD) tot het FO behoren en daar ben ik wel mee eens. Een ERD is niet technisch. Het beschrijft geen tabellen, maar entiteiten en de relaties hiertussen. Het is puur een referentiemodel aan de hand waarvan de opdrachtgever op een gemakkelijke wijze kan beoordelen of alle gelegde relaties goed zijn en, tezamen met de bijbehorende datadictionary, of alle gegevens zijn benoemd.

Het TO geeft een implementatiemodel, oftewel hier wordt pas de uiteindelijke structuur van de database, inclusief constraints etc, vastgelegd.

Ik heb de onderliggende theorie nog even voor je nagekeken: het betreft hier stap 3.4 Detailleer Gegevensstructuur uit SDM en hoofdstuk 12 uit Gestructureerde Analyse van Yourdon.

[morphje]

Aaaaah nou vooruit ik ga dan ook maar met mijn kennis pronken die me leraar in me hoofd heeft gestampt. (Hoewel, lessen waren saai en we mochten boek bij tentamen houden)

SDM was toch voor grote projecten? Althans niet echt bedoelt voor kleine projecten waarin de fase onderscheidingen niet duidelijk aan te geven zijn, aangezien alles vaak door elkaar word gedaan.

Voor zover ik de theorie had begrepen bestaat het FO uit niet meer als een context diagram (toplayer DFD).

We hadden op school ook project van 7 weken om een cvketel programma te maken. We gebruikte SDM-TIS. Ik was de programmeur Het UI ontwerp had ik in de eerste week af en programmeerde ik in week2. Toen kwamen de algemene modellen en programmeerde ik verder enz enz. Hoewel ... ik bedacht hoe het wel te programmeren was en toen ik functionele code had werd het DFD er op aangepast

[Dennis]

Het gaat hier toch wel om een webapplicatie .

[PdeHoog]

Op donderdag 18 april 2002 07:54 schreef ddc het volgende:
Het gaat hier toch wel om een webapplicatie .

He, een webAPPLICATIE is toch ook een APPLICATIE?

[PdeHoog]

Op donderdag 18 april 2002 07:51 schreef morphje het volgende:
Aaaaah nou vooruit ik ga dan ook maar met mijn kennis pronken die me leraar in me hoofd heeft gestampt. (Hoewel, lessen waren saai en we mochten boek bij tentamen houden)

Wij hebben niet eens een tentamen. We moeten een FO / TO (Detailontwerp volgens SDM) conform SDM opleveren en het cijfer voor dat ontwerp (tezamen met een ontwikkeld prototype van hetgeen we ontworpen hebben) is je eindcijfer

SDM was toch voor grote projecten? Althans niet echt bedoelt voor kleine projecten waarin de fase onderscheidingen niet duidelijk aan te geven zijn, aangezien alles vaak door elkaar word gedaan.

Als het goed is zou je voor elk project een dergelijke fasering moeten doorlopen. Hier moet natuurlijk wel flexibel mee worden omgegaan.

Voor zover ik de theorie had begrepen bestaat het FO uit niet meer als een context diagram (toplayer DFD).

Was het maar zo. Dan had het ons een hoop moeite bespaard.

We hadden op school ook project van 7 weken om een cvketel programma te maken. We gebruikte SDM-TIS. Ik was de programmeur Het UI ontwerp had ik in de eerste week af en programmeerde ik in week2. Toen kwamen de algemene modellen en programmeerde ik verder enz enz. Hoewel ... ik bedacht hoe het wel te programmeren was en toen ik functionele code had werd het DFD er op aangepast

Gaaf! Lijkt me geen probleem, toch? Tenslotte wordt je ook afgerekend op consistentie tussen alle producten

[Bosmonster]

Op woensdag 17 april 2002 22:51 schreef PdeHoog het volgende:

[..]

Ik heb hier de theorie zoals ik die uit Yourdon / SDM haal beschreven. Zij schrijven dat de te gebruiken gegevensstructuren (vastgelegd in het ERD) tot het FO behoren en daar ben ik wel mee eens. Een ERD is niet technisch. Het beschrijft geen tabellen, maar entiteiten en de relaties hiertussen. Het is puur een referentiemodel aan de hand waarvan de opdrachtgever op een gemakkelijke wijze kan beoordelen of alle gelegde relaties goed zijn en, tezamen met de bijbehorende datadictionary, of alle gegevens zijn benoemd.

SDM is heilig ofzo? SDM is antiek en nog van ver VOOR het webtijdperk.

Ik zie me al aankomen bij een klant met een ERD.. moet ik wel uitleggen wat een entitieit is natuurlijk en alle overige structuur, tekens, etc etc.. Nee niet echt

Klant is een noob en weet ECHT niet wat een ERD is en hoe die het moet lezen. DAAR moet je vanuit gaan imho. De klant beschrijft wat ie wil, dit komt in het FO (functioneel). Hoe je implementatie is en dus ook hoe je intern je relaties legt, is voor de klant verre van interessant en overbodige informatie.

Dalijk gaat de klant, die nog nooit een studie of wat gedaan heeft met betrekking tot het onderwerp jouw vertellen dat je ERD niet goed is Dan krijg je dus echt onhandelbare situaties.. jij bent per slot van rekening de adviseur die ingehuurd is ook de datastructuur te ontwerpen naar aanleiding van de fnuctionaliteit beschreven in het FO.

[TheRebell]

Uuuuuhhhhh..... in je FO komen geen DFD's hoor. Denk meer aan een data-dictionary, use-case, klassendiagram, je dialogen, je interfaces. OOk het nut van ERD's voor een klant is nog niet echt duidlijk, die snappen dat meestal toch niet.

[Goodielover]

Dat een klant/potentiële gebruiker het nut van een ERD niet inziet, lijkt me niet een criterium.

Doel van je FO is om alle onduidelijkheid over je de uiteindelijke functionaliteit beschreven te krijgen.
Een ERD beschrijft welke gegevens bijgehouden worden. Je hebt dus vaak een functioneel gegevens model en een technisch gegevens model. Voor beide kan je ERD gebruiken om het model vast te leggen.

Bedenk ook dat het model een commuicatiemiddel is naar het team dat gaat bouwen. Zij zullen blij zijn met een goed functioneel ERD. Alle velden zijn beschreven en als het goed is ook alle constraints op en tussen die velden. Het zijn dat soort constraints waar je met gebruikers juist hele discussies kan hebben.

Ook vragen als: Hou je nu 1 of meerdere adressen bij van klanten, kan je direct grafisch weergeven. Mijn ervaring is dat gebruikers niet zo dom zijn als je denkt, als je maar goede uitleg geeft bij een ERD en de boel een beetje overzichtelijk opdeelt.

[kaandorp]

Mijn visie is inderdaad dat de klant een n00b is.

Dus in het FO zou ik zetten. Wat wil de klant als eindresultaat zien.
"Ik wil een plaatje van een winkelwagen en als ik daarop klik dan..."
"Ik wil altijd de inhoud van mijn winkelwagen rechts gedisplayed hebben"
"Ik wil bla, bla, bla en bla over mijn product in de database kwijt kunnen."
"Er moet een mogelijkheid komen om..."

Zoiets zou toch in een FO moeten komen? En zo'n ERD is zo'n klant helemaal niet in geintereseerd neem ik aan. Als ie uberhaupt al weet wat het is

Ik richt me dan ook een beetje op het MKB die bijvoorbeeld een applicatie on-line willen om hun personeelsinfo in kwijt te kunnen of een online shoppie o.i.d.

[PdeHoog]

Op donderdag 18 april 2002 11:31 schreef kaandorp het volgende:
Mijn visie is inderdaad dat de klant een n00b is.

Dus in het FO zou ik zetten. Wat wil de klant als eindresultaat zien.
"Ik wil een plaatje van een winkelwagen en als ik daarop klik dan..."

Technisch ontwerp

"Ik wil altijd de inhoud van mijn winkelwagen rechts gedisplayed hebben"

Technisch ontwerp

"Ik wil bla, bla, bla en bla over mijn product in de database kwijt kunnen."

Zowel technisch als functioneel ontwerp

"Er moet een mogelijkheid komen om..."

Functioneel ontwerp

Volgens mij vergeet je dat een FO ook voor het ontwikkelteam dient. Dat is niet erg als je zelf het ontwikkelteam bent, maar op het moment dat er een externe partij wordt ingehuurd, en jij hebt onderdelen niet eenduidig beschreven in je FO, bestaat de kans dat het ontwikkelde niet aansluit met wat de klant en jij voor ogen hadden.

Daarbij geldt dat een goed model vaak meerdere pagina's tekst kan vervangen.

[PdeHoog]

Op donderdag 18 april 2002 10:05 schreef TheRebell het volgende:
Uuuuuhhhhh..... in je FO komen geen DFD's hoor. Denk meer aan een data-dictionary, use-case, klassendiagram, je dialogen, je interfaces. OOk het nut van ERD's voor een klant is nog niet echt duidlijk, die snappen dat meestal toch niet.

Hangt ervanaf. In dit geval heb je het volgens mij over een object-georienteerd ontwerp en dat is bij Yourdon niet zo. Yourdon redeneert volgens mij volkomen vanuit de te ondersteunen processen.

[PdeHoog]

Op donderdag 18 april 2002 09:24 schreef Bosmonster het volgende:

[..]

SDM is heilig ofzo? SDM is antiek en nog van ver VOOR het webtijdperk.

Dat heb ik nooit gezegd. Ik kan alleen vertellen over datgene wat ik tot op heden heb geleerd in mijn avondstudie en dat is de combinatie SDM / Yourdon. Ik geef toe dat het allemaal redelijk gedateerd is, maar de principes zijn best goed.

Dalijk gaat de klant, die nog nooit een studie of wat gedaan heeft met betrekking tot het onderwerp jouw vertellen dat je ERD niet goed is Dan krijg je dus echt onhandelbare situaties.. jij bent per slot van rekening de adviseur die ingehuurd is ook de datastructuur te ontwerpen naar aanleiding van de fnuctionaliteit beschreven in het FO.

Volgens mij moet je dit allemaal in samenspraak doen met de klant na analyse van wat de klant wil. Een ERD is simpelweg een notatiewijze van datgene wat de klant wil.

Het is volgens mij van groot belang dat de klant betrokken wordt bij het gehele ontwikkelproces en dat hij goed begrijpt wat er gebouwd gaat worden.

Op het moment dat jij van te voren overlegt met een klant en hij vertelt dat je ERD niet goed is (en hij kan het onderbouwen) dan is het aan jouw beoordeling of de klant gelijk heeft of niet. Heeft de klant gelijk dan is het mooi dat dat er nu nog uit komt (beter dan wanneer de gehele applicatie draait. Daar heb ik ervaring mee ). Heeft de klant geen gelijk dan kun je het hem uitleggen. Daar dient een adviseur tenslotte ook voor!

[Verwijderd]

In het functioneel ontwerp staan op eenduidige wijze de wensen van de gebruiker. Ook de niet-automatiserings-oplossingen voor bepaalde wensen staan erin. Een programma ondersteunt namelijk (een onderdeel) van een proces.

Hierbij hoort dus WEL een ERD (en een semantisch gegevensmodel). Waarom? Omdat de gebruiker aangeeft dat hij geinteresseerd is in bepaalde gegevens. Het is aan te raden om dat dan vast te leggen in je FO, zodat jij, de ontwikkelaar, de tester en de gebruiker precies weten wat de bedoeling is. Het is namelijk alleen de informatie-analist / functioneel ontwerper die contacten onderhoudt met de gebruiker. Natuurlijk wordt de gebruiker bij de gebruikersacceptatietest wel ondersteund door de tester/testcoordinator maar je begrijpt dat dat een beetje laat in het traject is.

Het zou van de gekke zijn als de ontwikkelaar zonder een FO met ERD of de gebruiker te raadplegen zomaar wat tabelletjes gaat maken.

Hoe diepgaand het FO is is vooral afhankelijk van hoe groot het project is en welk scenario je gebruikt. (Versneld OntwikkelScenario, Lineair OS, etc)

En als we dan toch gaan pochen: hier spreekt een informatie-analist met meer dan 10 jaar ervaring en ex-lid van de examencommissie AMBI.

[Scare360]

Op donderdag 18 april 2002 13:12 schreef remedy70 het volgende:
In het functioneel ontwerp staan op eenduidige wijze de wensen van de gebruiker. Ook de niet-automatiserings-oplossingen voor bepaalde wensen staan erin. Een programma ondersteunt namelijk (een onderdeel) van een proces.

Hierbij hoort dus WEL een ERD (en een semantisch gegevensmodel). Waarom? Omdat de gebruiker aangeeft dat hij geinteresseerd is in bepaalde gegevens. Het is aan te raden om dat dan vast te leggen in je FO, zodat jij, de ontwikkelaar, de tester en de gebruiker precies weten wat de bedoeling is. Het is namelijk alleen de informatie-analist / functioneel ontwerper die contacten onderhoudt met de gebruiker. Natuurlijk wordt de gebruiker bij de gebruikersacceptatietest wel ondersteund door de tester/testcoordinator maar je begrijpt dat dat een beetje laat in het traject is.

Het zou van de gekke zijn als de ontwikkelaar zonder een FO met ERD of de gebruiker te raadplegen zomaar wat tabelletjes gaat maken.

Hoe diepgaand het FO is is vooral afhankelijk van hoe groot het project is en welk scenario je gebruikt. (Versneld OntwikkelScenario, Lineair OS, etc)

En als we dan toch gaan pochen: hier spreekt een informatie-analist met meer dan 10 jaar ervaring en ex-lid van de examencommissie AMBI.

100% correct! En dan zijn initieel de niet-automatiserings-oplossingen van groot belang aangezien je hiermee de volgende stap gaat maken. Analyseren/visualiseren van de inforamtiestromen zijn een must om alles netjes samen te vatten in een FO. En vast pinnen die klant he... vastpinnen op specificaties en functionele specificaties. In het FOW (finctioneel ontwerp) kun je weer los gaan, nog maar niet over het (TO) technisch ontwerp te spreken.

De implementatie is helemaal om los te lopen...dan kom je tot de conclusie dat alles kut is en management de hort op kan met hun deadline

[THIJZEL]

Allereerst mijn excuses voor het omhoogkicken van zo'n oud topic..

Mijn vraag:

Ik moet een FO schrijven voor een klein onderdeel(class) dat geintegreerd gaat worden in een bestaande applicatie(intranet). Nu vind ik het moeilijk om een Fo te schrijven voor dit onderdeel aangezien mijn "klant" een technicus is en eisen aan de class vrijwel allemaal technisch zijn.. Hoe los ik dit op? wat zet ik in het FO?

ps: de Class is een class welke op basis van klant en account gegevens een bestand genereerd en hiernaar weer een url naar dit bestand returned.

[whoami]

Als je klant geen behoeft heeft aan een FO, waarom maak je dan een FO voor hem?
Als je het zelf nodig vind om een een te maken, maak je er een.

[THIJZEL]

Nouja hij heeft aangegeven eerst een fo van me te willen zien...

[Markieman]

In het kort:

Het FO zal om je class draaien. Een typisch FO beschrijft, zoals eerder gezegt, WAT er gebeurt en niet HOE het gebeurt. Ofwel je beschrijft de in- en uitvoer stromen van deze class. Tevens kan je nog beschrijven waar die stromen heen gaan.

Verder is deze reply best wel nuttig

Ook al is hij een techneut, een FO is niet technisch. Dan had hij maar om een Technisch Ontwerp moeten vragen...

[ Voor 15% gewijzigd door Markieman op 28-04-2004 11:58 ]