Voordelen van het opstellen van een functioneel ontwerp

[Verwijderd]

Ik moet voor een bepaald Content Management Systeem een functioneel ontwerp gaan opstellen.

Ik vraag me af wat nu echt de doorslag geeft om een FO op stellen (voordelen t.o.v. de kosten).

[gorgi_19]

Het lijkt me handig dat je weet (en voor iedereen duidelijk is) wat het CMS moet kunnen? (Vooraf)

[ Voor 7% gewijzigd door gorgi_19 op 29-09-2004 10:05 ]

[André]

De doorslag zal prijs/prestatie geven. Een superdeluxe CMS voor €10 heb ik liever dan een kut CMS voor €100.000.

[BtM909]

André schreef op 29 september 2004 @ 10:02:
De doorslag zal prijs/prestatie geven. Een superdeluxe CMS voor €10 heb ik liever dan een kut CMS voor €100.000.

Lekker voorbeeld (je had de prijzen net zo goed weg kunnen laten)

[Arjan A]

Met een goed functioneel ontwerp kunnen alle partijen uit de voeten en weet iedereen waar ze aan toe zijn.
Het doel van een FO is onder andere om duidelijk te stellen welke functionaliteiten geboden (gaan) worden en welke niet. Aannames dienen te worden uitgesloten.
Het voordeel van een FO is dat dus van tevoren is afgebakend wat wel en wat niet in een applicatie komt eventueel en in welke versie. Het scheelt gezeik over "dit en dat moest er ook in" en dus tijd. Tijd is geld zoals je weet, en informatie is macht. Tel uit je winst.

OVerigens is de bedoeling van een FO niet dat je het achteraf schrijft. Dan kan je net zo goed een handleiding gaan maken .

[Verwijderd]

FO's zijn voor uitgebreide projecten onontbeerlijk.

http://www.joelonsoftware.com/articles/fog0000000036.html

Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.

En daar ben ik het wel mee eens.

[Canaria]

^^^
Als je een systeem ontwikkelt doorloop je altijd een aantal stappen. Ten eerste zoek je uit wat de functionele eisen aan het systeem zijn en hoe het eruit moet zien. Meestal heeft een opdrachtgever daarover wel een idee, soms is dat vaag en soms gedetailleerd. Als je die eisen en wensen gaat vertalen naar de opzet van het systeem moet je wel iets kunnen terugkoppelen. De opdrachtgever weet dan wat hij kan verwachten. En je bakent zoals gezegd af wat er wel en niet in komt, verder kan een FO je aanwijzingen geven voor de hoeveelheid werk en het tijdspad dat daaraan verbonden is. Ook in latere fasen van de ontwikkeling biedt het een houvast en richting, hoewel de systeemontwikkeling een dynamisch proces is, waarbij je soms kunt en moet afwijken van de oorspronkelijke plannen.

Verder is een FO noodzakelijk als je met meerdere mensen aan een project werkt. Het is een concrete uitwerking van de opdracht, met alleen een visie en beoogd doel kan je geen team aan het werk zetten.

hmmz dit lijkt wel een tentamenvraag zoals ik die regelmatig heb beantwoord

[ Voor 11% gewijzigd door Canaria op 29-09-2004 10:18 ]

[André]

De belangrijkste reden is misschien wel dat iedereen weet waar ze aan toe zijn, dus hoe lang bepaalde dingen gaan duren en dus ook hoeveel het gaat kosten. Alle doelen liggen vast dus die hoeven niet on-the-fly gemaakt te worden waardoor het een ongeordend zootje word.

[Verwijderd]

Maken jullie aan de hand van het FO ook de planning?

[gorgi_19]

Verwijderd schreef op 29 september 2004 @ 10:29:
Maken jullie aan de hand van het FO ook de planning?

Gedeeltelijk; als je weet wat je moet maken, kan je ook een specifiekere planning maken. Echter, soms staat er een einddatum vast en kan je alleen wijzigingen aanbrengen in je bezetting.

[ Voor 17% gewijzigd door gorgi_19 op 29-09-2004 10:31 ]

[André]

Verwijderd schreef op 29 september 2004 @ 10:29:
Maken jullie aan de hand van het FO ook de planning?

Dat lijkt me wel, je zou met een goed FO redelijk aan kunnen geven hoe veel tijd in elk onderdeel gaat zitten.

[gorgi_19]

Maar andere vraag aan Koffiemok; wat zijn je eigen ideeen hierover?
Waarom twijfel je of je wel of niet een FO moet maken? Waarom wil je jouw planning baseren op het FO?

[ Voor 44% gewijzigd door gorgi_19 op 29-09-2004 10:33 ]

[Canaria]

Verwijderd schreef op 29 september 2004 @ 10:29:
Maken jullie aan de hand van het FO ook de planning?

Nee, een functioneel ontwerp kan alleen een aanleiding daarvoor zijn, zoals gorgi_19 zegt. Voor een grove planning dus wel.
Maar in een FO ligt de nadruk op het systeem en de functies.
Je moet dat ontleden in de werkzaamheden die nodig zijn om tot dat systeem te komen, aan die werkzaamheden koppel je tijdsduren en daarmee ga je dan binnen de grove planning schuiven met mensen en materialen tot je de optimale verdeling hebt gevonden (in een programma zoals MS Project).

[Verwijderd]

gorgi_19 schreef op 29 september 2004 @ 10:32:
Maar andere vraag aan Koffiemok; wat zijn je eigen ideeen hierover?
Waarom twijfel je of je wel of niet een FO moet maken? Waarom wil je jouw planning baseren op het FO?

Ik ben al bezig met het FO, maar ik moet iemand overtuigen van het nut ervan. Ik weet zelf dat afspraken over het CMS vastgelegd moeten worden en dit kan mooi in het FO. Met behulp van het FO kan een planning met deeltaken worden opgesteld.

Ik vraag me wel af of het FO ook gebruikt kan worden als handleiding (beschrijving functionaliteit), want anders zou je bij een wijziging 2 documenten moeten aanpassen.

[gorgi_19]

Ik vraag me wel af of het FO ook gebruikt kan worden als handleiding (beschrijving functionaliteit), want anders zou je bij een wijziging 2 documenten moeten aanpassen.

Wat iets moet kunnen en hoe iets werkt zijn 2 verschillende dingen

[OzBoz]

Zeker bij grotere klussen heeft volgens mij iedereen gemak van een FO. Het is ook een goed praatstuk en je kunt dingen vooraf beter checken. Daarnaast merk ik dat een FO ook voor klanten vaan wel handig is omdat de gemiddelde klant van ons zich absoluut niets kan voorstellen bij een verhaaltje en sich.

Qua kosten denk ik dat die eigenlijk nihil zijn. Natuurlijk ben je een tijdje zoet met het maken van een FO maar volgens mij verdien je die kosten (ook klant kant) zo weer terug op het moment dat je een bespreking of 1-2 minder nodig hebt omdat er meteen al goed is over nagedacht.

[MrBarBarian]

OzBoz schreef op 29 september 2004 @ 11:46:
Qua kosten denk ik dat die eigenlijk nihil zijn. Natuurlijk ben je een tijdje zoet met het maken van een FO maar volgens mij verdien je die kosten (ook klant kant) zo weer terug op het moment dat je een bespreking of 1-2 minder nodig hebt omdat er meteen al goed is over nagedacht.

Dat is denk ik sterk afhankelijk van de grootte van het project. Een project waar 10 mensen aan meewerken zal zeker gebaat zijn bij een FO...

Maar bij een projectjes met een ontwikkelaar, zijn de kosten voor een FO al snel te hoog. Een mogelijkheid is dan bijv. regelmatig (minstens een maal per week) overleg tussen de ontwikkelaar, klant en projectleider.

Bovendien is het alsnog regelmatig zo dat aan het eind van het project, het FO totaal niet blijkt te kloppen.. gewoon o.a. door onvoorziene omstandigheden en/of aangepaste eisen..

[OzBoz]

MrBarBarian schreef op 29 september 2004 @ 11:51:
[...]
Dat is denk ik sterk afhankelijk van de grootte van het project. Een project waar 10 mensen aan meewerken zal zeker gebaat zijn bij een FO...

Maar bij een projectjes met een ontwikkelaar, zijn de kosten voor een FO al snel te hoog. Een mogelijkheid is dan bijv. regelmatig (minstens een maal per week) overleg tussen de ontwikkelaar, klant en projectleider.

True, ik maak ze ook vrijwel nooit. Maar ligt inderdaad een beetje aan het project. Maar als je continu bij elkaar moet gaan zitten tegen laten we zeggen 80 pppu dan kun je die tijd ook beter besteden.

Bovendien is het alsnog regelmatig zo dat aan het eind van het project, het FO totaal niet blijkt te kloppen.. gewoon o.a. door onvoorziene omstandigheden en/of aangepaste eisen..

Als een FO aan het eind niet klopt dan sla je de plank ermee mis naar mijn idee. FO hoort wat mij betreft het praatstuk te zijn. Door dat intensief met een klant door te nemen zou je in de praktijk juist moeten voorkomen. En onverziene omstandigheden zijn naar mijn idee meestal het gevolg van slechte communicatie of het matige reviewen van een FO met klant. En sja.. dat kan ook heel goed aan de klant liggen, maar die moet zich juist bewust zijn van het feit dat een FO belangrijk is, soort van fundering. En wanneer een klant zich ook bewust is hoeveel aanpassingen achteraf kosten dan denkt een klant in de regel wel goed mee is mijn ervaring.

[MrBarBarian]

OzBoz schreef op 29 september 2004 @ 11:58:
Als een FO aan het eind niet klopt dan sla je de plank ermee mis naar mijn idee. FO hoort wat mij betreft het praatstuk te zijn. Door dat intensief met een klant door te nemen zou je in de praktijk juist moeten voorkomen. En onverziene omstandigheden zijn naar mijn idee meestal het gevolg van slechte communicatie of het matige reviewen van een FO met klant. En sja.. dat kan ook heel goed aan de klant liggen, maar die moet zich juist bewust zijn van het feit dat een FO belangrijk is, soort van fundering. En wanneer een klant zich ook bewust is hoeveel aanpassingen achteraf kosten dan denkt een klant in de regel wel goed mee is mijn ervaring.

Mee eens.. Maar ik denk dat het probleem is dat een klant veelal weet wat hij ongeveer wil, en niet wat hij precies wil. Pas als hij de eerste resultaten gaat zien, wordt de opdracht echt tastbaar voor hem, en zal hij dus snel zijn wensen/eisen willen gaan aanpassen.

Uiteraard is het ook jouw taak (als FO schrijver) om vooraf de klant te adviseren over de mogelijkheden (en uiteraard mogelijke knelpunten).

Mijn mening dus: een FO kan nuttig zijn, maar wees bewust van die beperkingen van een FO

[Verwijderd]

Aan de hand van het FO wordt de applicatie ontwikkelt. Plaatsen jullie daarna screenshots van de werkelijke applicatie in het FO?


Vraag 2...
In het FO komen dus de functionele zaken aan bod. Maken jullie hiervan ook een beperkte grafische voorstelling b.v. in een tabelletje o.i.d. in het FO? (menu links, banner boven e.d.)

[gorgi_19]

Verwijderd schreef op 01 oktober 2004 @ 11:29:
Aan de hand van het FO wordt de applicatie ontwikkelt. Plaatsen jullie daarna screenshots van de werkelijke applicatie in het FO?

Op dat punt is het FO nutteloos; deze wordt vooraf gemaakt en hooguit achteraf op getoetst. Beetje nutteloos om dan het FO nog te gaan opleuken. Daar heb je de documentatie voor.

Vraag 2...
In het FO komen dus de functionele zaken aan bod. Maken jullie hiervan ook een beperkte grafische voorstelling b.v. in een tabelletje o.i.d. in het FO? (menu links, banner boven e.d.)

Imho staat de vormgeving los van het functioneel ontwerp.

[Verwijderd]

gorgi_19 schreef op 01 oktober 2004 @ 11:34:
Imho staat de vormgeving los van het functioneel ontwerp.

Al zegt een plaatje vaak meer dan 1000 woorden

[Verwijderd]

gorgi_19 schreef op 01 oktober 2004 @ 11:34:
Imho staat de vormgeving los van het functioneel ontwerp.

In theorie wel, maar in de praktijk worden FO's waarbij het ontwerp visueel wordt ondersteund sneller en makkelijker geaccepteerd door de klant. Vergeet niet dat er in een bedrijf vaak wordt overruled, en dat Jan je ontwerp ontvangt, dit vervolgens aan Piet moet verantwoorden en Piet weer aan Koos. Tegen de tijd dat het ontwerp bij Koos is aanbeland zijn er al 3 mogelijk opvattingen ontstaan over de functionaliteit ondanks de complete nonense schrijfwijze van een functionaliteit.

Visuele ondersteuning kan daarbij een proces visueel goed uitbeelden. Vooral bij complexe user interfaces kan dit nogal eens veel voordelen brengen.

[ Voor 5% gewijzigd door Verwijderd op 01-10-2004 14:43 ]