[ALG] Aandachtspunten Functioneel Ontwerp

[Verwijderd]

Wie heeft enkele aandachtspunten voor een FO voor mij ?
Moet er nl. een maken voor een webbased supportsysteem.

Een voorbeeld is ook van harte welkom.

Thanx alvast!

[Verwijderd]

*kick*

[Greyfox]

Een aandachtspuntje is zeker dat het een goed FO moet zijn.

[Verwijderd]

welke systeemontwikkelingsmethode hanteer je?

[Verwijderd]

Op dinsdag 13 november 2001 09:04 schreef Dianne het volgende:
welke systeemontwikkelingsmethode hanteer je?

zit te denken aan IDO.
Reden ? Weet ik niet....lijkt mij het eenvoudigst...zeker bij een vrij simpel ondersteuningspakketje voor functionele zaken....waar vooral logging(voortgang e.d.) een belangrijke zaak is.

[Verwijderd]

Zal je ff een checklist voor SDM sturen, misschien is dat ook nog een optie?

[Verwijderd]

Op dinsdag 13 november 2001 10:45 schreef Dianne het volgende:
Zal je ff een checklist voor SDM sturen, misschien is dat ook nog een optie?

ow...dat zou heel fijn zijn. Moet ik alleen ff kijken wat het voordeel van (D)SDM tov IDO is...maar ja..neem me morgen wel ff ook het DSDM boek mee naar het werk..

Dank je alvast...

edit:

Ontvangen !
Thanx.....Dianne zonder achternaam

[Verwijderd]

Dianne,

heb ik je email-adres goed gegokt ?

[DarkTide]

In plaats van hier weer een topic over te openen, schop ik dit oude topic naar boven met de vraag:

Weet iemand waar ik aandachtspunten en voorbeelden van een FO kan vinden?

[Verwijderd]

*kick*
Zie boven, hetzelfde geld voor mij.

[DarkTide]

Hmmm nog steeds niks gevonden...

Heb het functioneel ontwerp nu wel al af

Als iemand het wil zien zeg het maar!

[Verwijderd]

Op vrijdag 22 februari 2002 14:28 schreef BlackTide het volgende:
Heb het functioneel ontwerp nu wel al af

Als iemand het wil zien zeg het maar!

Een overzicht van de (jouw ) inhoudsopgave van een Functioneel Ontwerp zou volgens mij al helpen en kan als leidraad dienen voor anderen die een FO moeten maken.
Maar het maakt ook nog wel uit welke methode en technieken je gebruikt...

De topic van dit bericht is 'Aandachtspunten Functioneel Ontwerp', maar die aand8spunten staan (stonden...) hier helaas niet en hier: [topic=470676] wel ... Daar wordt echter vooral ingegaan op de aand8spunten volgens SDM/Yourdon.

Een methode als bijvoorbeeld Unified Process (van Rational) maakt niet eens (meer) onderscheid tussen een FO en een TO.

De belangrijkste aand8spunten van een FO lijken mij:
• Organisatorische aanpassingen / impact voor de organisatie
• Functionele specificaties
• Functioneel gegevensmodel (geen datamodel, want dat is al technisch)
• Interface-beschrijving / systeemgrenzen
• GUI design (stylesheet, bedrijfsstandaarden etc.)

Technieken die je in een FO kunt gebruiken zijn bijv.:
• Businesscase
• Use cases, UCD (Use Case Diagram, voor de functionele specificaties)
• ERD (Entity Relation Diagram, voor het gegevensmodel)
• Contextdiagram (voor de systeemgrenzen)
• DFD (Data Flow Diagram, voor het interne systeem)

[Nielsz]

(offtopic: beetje oud topic )

[TheDane]

ik hou het meestal op ERD's en DFD's, en waar nodig in laymen's terms uitgelegd.

het lijkt me een beetje van de organisatie af te hangen hoever je wil gaan, die post hierboven bijvoorbeeld is in mijn situatie ZWARE overkill (maar wel zeer puik )

Zolang je zorgt dat je specificaties compleet en eenduidig (niet dubbelzinnig te interpreteren) zijn, ben je volgens mij al een heel eind

[ook offtopic] verrek, da zie'k nu pas
maargoed, functionele en technische specificaties zijn altijd actueel

[xos]

Om school hebben we zo'n rapport ook dit blok gedaan alleen van een project dat zo kleinschalig was dat het totaal overbodig was maar ja. Wij hebben daar een dun boekje voor moeten aanschaffen: SDM TIS (System Development Methodology for Technical Information Systems) uitgegeven door GAP GEMINI PUBLISHING. Misschien dat je daar eens naar kan kijken wordt stap voor stap uitgelegd wat voor punten er komen kijken bij het maken van een systeem.

[Verwijderd]

maargoed, functionele en technische specificaties zijn altijd actueel

ja dat d8 ik ook...

het lijkt me een beetje van de organisatie af te hangen hoever je wil gaan, die post hierboven bijvoorbeeld is in mijn situatie ZWARE overkill

oh, absoluut! je moet natuurlijk geen dingen doen (documenten opleveren) waar je nix aan hebt (nix mee doet)
In eerder genoemde topic wordt ook al een uitgebreide discussie gevoerd over wat wel en wat niet in een FO 'hoort', maar ik ben van mening dat het van de situatie afhangt.
En sja... op school krijg je misschien een klein projectje in 7 weken (omdat er gewoon niet meer tijd is), maar dan gaat het er niet om dat je een groot project doet, maar dat je leert hoe je een (goed) FO maakt.

Zolang je zorgt dat je specificaties compleet en eenduidig (niet dubbelzinnig te interpreteren) zijn, ben je volgens mij al een heel eind

Ja, precies!
En in die andere topic werd ook nog ingegaan op het feit dat je een klant als n00b moet beschouwen, maar dat ligt natuurlijk ook helemaal aan de (soort) klant...
Volgens mij is er ook niets op tegen om een uitgebreid FO te maken voor de ontwikkelaars en een samenvatting (of soort van managementrapportage) voor de klant.

Ik wil hier niet de discussie voeren of je nog wel een FO wilt maken, want het ging hier juist om de aand8spunten van een FO, dus dan ga ik er van uit dat je besloten hebt dat voor jouw situatie een FO een geschikte oplossing is. Want zoals ik al aangaf, maakt Unified Process al helemaal geen onderscheid meer tussen FO en TO.

Als je een OO (object oriented) FO wilt maken, zul je bijvoorbeeld ook geen ERD willen gebruiken, maar een Class Diagram. Zo'n functioneel Class Diagram zal in de loop van het project "vanzelf" migreren naar een technisch Class Diagram. Ik kan me ook voorstellen dat je (achteraf/tijdens het project) alleen het TO bijwerkt met de veranderingen die je tijdens implementatie realiseert en het FO weggooit.

Het doel van het FO is naar mijn idee tweeledig:
• informeren van de klant (duidelijkheid krijgen van de precieze klantwensen)
• basis voor het TO voor de ontwikkelaars (duidelijkheid krijgen van de (rand)voorwaarden, zoals systeemgrenzen, interfaces (met externe systemen), gegevens(model), GUI etc.)

[Verwijderd]

Op maandag 12 november 2001 16:43 schreef pret het volgende:
Wie heeft enkele aandachtspunten voor een FO voor mij ?
Moet er nl. een maken voor een webbased supportsysteem.

Een voorbeeld is ook van harte welkom.

Thanx alvast!

Nou, als je de belangrijkste fout vermijdt, dan ben je al een heel eind.

Een FO moet functionaliteit omschrijven, en mag geen technische ontwerpbeslissingen bevatten of beslissingen die gebaseerd zijn op technische aspecten. M.a.w.: je omschrijft puur ALLE functionaliteit die je denkt te moeten realiseren, daar baseer je je analyse ook op. Wanneer je dat nl. doet, kun je daarna, dus wanneer het FO af is, er een subset uit halen en die implementeren aan de hand van een TO dat je schrijft aan de hand van de functionaliteit beschreven in het FO.

Veel FO's staan vol met technische troep en snijden bij voorbaat al functionaliteit af die 'vanwege technische aspecten' niet kan worden geimplementeerd. Dit is onzin en zorgt ervoor dat het FO waardeloos wordt en je project waarschijnlijk crap op zal leveren. Het opnemen van schermvoorbeelden is al not-done.

Omdat het voor een website is, zou ik in mn analyses de volgende zaken aflopen:
- omschrijf de doelgroepen. (meervoud dus!)
- per doelgroep omschrijf de benefits sought. (dus wat willen ZIJ zien op de website!)
- per benefits sought omschrijf je hoe de website houder daar aan zal voldoen
- stel logische navigatiepaden op voor elke doelgroep om de gewenste functionaliteit te bereiken. (dit zijn dus geen pagina navigaties maar informatie navigaties!)

Als je dit doet, heb je alle mogelijke functionaliteit omschreven. Daarna kun je samen met de opdrachtgever gaan snijden in deze functionaliteit en deze in een technisch ontwerp omschrijven en daarna bouwen. Het voordeel hiervan is, is dat wanneer je de site wilt uitbreiden, je de functionele analyses al gedaan hebt en als je je TO goed opstelt, al rekening mee hebt gehouden.

zie ook: www.sd.nl/internetmarketing
(en dan bv: http://www.sd.nl/internetmarketing/archief/9803.html)

[Verwijderd]

Essentieel bij het maken van het FO lijkt me dat je goed op de hoogte bent van de praktijk van de klant. Zorg dus dat je klant (eindgebruiker) een manier heeft om zijn functionele wensen en eisen in te brengen (op een gestructureerde en beargumenteerde manier).

Het ergste wat mij kan overkomen is een FO wat geschreven is uit het oogpunt van wat technisch mogelijk is, maar wat uiteindelijk niet meer correspondeert met de oorspronkelijk gewenste functie.

Belangrijk is ook dat je een goede afbakening maakt van wat er nog wel bij hoort en wat er niet meer bij hoort. Een te ruim FO geeft anderen de ruimte allerlei zaken in jouw project te stoppen die er niet in thuishoren en die uiteindelijk ook de continuiteit in gevaar brengen of die op z'n minst je ontwikkeltijd ernstig verlengen.

[TheDane]

Op woensdag 19 juni 2002 11:31 schreef Puckly het volgende:

[..]

Ik kan me ook voorstellen dat je (achteraf/tijdens het project) alleen het TO bijwerkt met de veranderingen die je tijdens implementatie realiseert en het FO weggooit.

Het doel van het FO is naar mijn idee tweeledig:
• informeren van de klant (duidelijkheid krijgen van de precieze klantwensen)
• basis voor het TO voor de ontwikkelaars (duidelijkheid krijgen van de (rand)voorwaarden, zoals systeemgrenzen, interfaces (met externe systemen), gegevens(model), GUI etc.)

dat is imho NOT DONE. een FO is imo niet alleen een leidraad aan de hand waarvan ontwikkelaars hun technische specificaties schrijven, het is ook een soort van contract tussen ontwikkelaar en klant/opdrachtgever (zowel intern als extern) over de te ontwikkelen produkten. Daarom is het zo belangrijk dat die specificaties zo volledig en eenduidig zijn, zodat er achteraf geen misverstanden over kunnen ontstaan, bijvoorbeeld als de ontwikkelaar bijvoorbeeld 'eigen initiatief' in het produkt stopt. De klant kan dan zeggen: jamaarrrr zo was het niet gespecificeerd

en de ontwikkelaar kan hetzelfde zeggen als de opdrachtgever halverwege de realisatiefase nog met 'additionele eisen' (zoals ze dat zo mooi zeggen bij ons op kantoor ) aan komt zetten

Ik vind "Plan van Aanpak" in deze context ook wel een handige term btw

oh btw: een technisch ontwerp is na oplevering van de definitieve versie (voor aanvang van de realisatiefase) OOK niet meer te veranderen. TO's moeten door andere ontwikkelaars -correct- geinterpreteerd kunnen worden, zodat no matter what (andere codeerstijl/taal/resources etc) het eindprodukt identiek zou zijn aan wat ontwikkelaar #1 gemaakt zou hebben. (qua functionele specificaties)

[Verwijderd]

http://systeemontwikkeling.checklist.sdm.activiteiten.kennisbank.nu/

Is misschien een leuke pagina om eens op te kijken

[TheDane]

Op woensdag 19 juni 2002 12:54 schreef dj_delta het volgende:
http://systeemontwikkeling.checklist.sdm.activiteiten.kennisbank.nu/

Is misschien een leuke pagina om eens op te kijken

thanks, die heb ik ooit eens gebookmarked gehad,. was 'm kwijt

[Bobco]

Op woensdag 19 juni 2002 12:43 schreef TheDane het volgende:
[..] oh btw: een technisch ontwerp is na oplevering van de definitieve versie (voor aanvang van de realisatiefase) OOK niet meer te veranderen. TO's moeten door andere ontwikkelaars -correct- geinterpreteerd kunnen worden, zodat no matter what (andere codeerstijl/taal/resources etc) het eindprodukt identiek zou zijn aan wat ontwikkelaar #1 gemaakt zou hebben. (qua functionele specificaties)

Hmm, dat niet meer veranderen van ontwerpen is uiteraard een ideale situatie. Je gaat er dan van uit dat de ontwerpen niet alleen foutloos, maar ook volledig zijn. Dat lijkt me een mooi streven, maar in de praktijk is dit over het algemeen niet zo.

De meeste opgeleverde systemen werken 'as coded'. Uiteraard lijkt de werking heel erg veel op de functionele specs, maar bij elk systeem van niet-triviale omvang zijn er subtiele afwijkingen van de specs, of gedrag dat juist helemaal niet in de specs staat.

De kunst is het natuurlijk om de gulden middenweg te vinden tussen goed ontwerpen/lang nadenken en snel coderen/snel opleveren te vinden. Wat de juiste balans is verschilt uiteraard per opdracht(gever).

[Verwijderd]

[...]zodat no matter what (andere codeerstijl/taal/resources etc) het eindprodukt identiek zou zijn aan wat ontwikkelaar #1 gemaakt zou hebben. (qua functionele specificaties)

Dat is idd natuurlijk zo in de ideale situatie, maar tijdens het realiseren, kunnen er altijd nog wijzigingen komen (van de klant of van de ontwikkelaars). Ik ben het absoluut met je eens dat je dit eigenlijk niet wilt en in het contract afgedicht wilt hebben, maar je voorkomt in de praktijk niet dat er nog zaken veranderen. (Er moet bijvoorbeeld toch nog even een attribuut bij, of een varchar(20) moet ineens varchar(30) worden of een NOT NULL moet ineens wel NULL worden etc...)

Zoals wel blijkt uit de meeste discussies (hier en in die andere thread, maar ook in de praktijk), is dat er verschillende opvatting bestaan over (het doel van) het FO en het TO. Belangrijk lijkt mij dat je in ieder geval (bijvoorbeeld in het PvA) vastlegt wat je wel en niet gaat beschrijven.

Mijn visie is iig dat het FO geen contract is, maar dat het als bijlage van een contract zou kunnen dienen. Ik vind dat je je idd niet teveel (technisch) moet beperken in het FO, maar je wilt wel een duidelijke afbakening van je systeem: wat hoort er nog wel bij (wat gaat er -nu- wel gebouwd worden) en wat absoluut niet meer?

Je wilt ook beschrijven wat de interfaces zijn, bijvoorbeeld met een printer, maar bijvoorbeeld ook met een AS400 oid... In het FO beschrijf je dat die interface er is, in het TO ga je dan nader in op de technische specificaties, zoals de protocollen ed.

Waar laat je de inhoud van het FO van afhangen? persoonlijke visie
• projectgrootte
• complexiteit
• projectteam(grootte) (bijv. ook: is dezelfde groep verantwoordelijk voor het hele project?)
• doel van het document
• (proces)methode

[Verwijderd]

Op woensdag 19 juni 2002 12:54 schreef dj_delta het volgende:
http://systeemontwikkeling.checklist.sdm.activiteiten.kennisbank.nu/

Is misschien een leuke pagina om eens op te kijken

Dit is zeker een zeer nuttige pagina! En bedankt dat je 'm hier gepost hebt! (Eindelijk wordt dit een nuttige thread )
Maar... dit is maar een methode, een manier om een FO tot stand te laten komen...