Kort geleden sprak ik een consultant van een ander bedrijf. Hij was specialist voor een bepaalde werkwijze voor requirements beheer en het bijbehorende tool. Een verstandige man, wist waarover hij het had.
Hij vertelde dat eigenlijk alleen met een klant aan de gang wilde, als men echt "geloofde"in de aanpak. Ook moest er "totaal commitment" zijn van het management, vooral ook van het topmanagement.
Je hoort dat wel vaker, en eigenlijk is dat nogal vreemd. Het is logisch dat je verwacht dat een bedrijf het noodzakelijke doet om een bepaalde aanpak te laten slagen: tool kopen, cursussen, relevante expertise inhuren, etc. Maar waarom moet je erin geloven? Wat is dat toch met die "totale commitment"?
Het lijkt wel een sekte. En als je nou een heel esoterisch produkt verkoopt, met erg veel verhaal, en erg weinig praktisch nut, ja, dan kan ik me deze Johan-Maasbach-benadering voorstellen.
Maar in dit geval ging het om iets wat duidelijk nut heeft, en bewezen kan werken. Ik zou zeggen: verkoop het, doe het, en laat het zichzelf bewijzen.
Waarom dat toch die nadruk op totale overgave? Zou het komen doordat veel IT-consultants eigenlijk gemankeerde dominees of missionarissen zijn?
donderdag 19 juli 2007
use cases considered harmful (3)
Na wat googlen zie ik dat er eerder al vele anderen op het idee van deze titel zijn gekomen. Onder hen de voortreffelijke Peter Coad.
dinsdag 17 juli 2007
Use cases considered harmful (2)
Gisteren heb ik op deze blog wat negatieve dingen over use cases gezet. Dat heeft elders, op een mailing list, wat discussie gebracht. Daarin werd opgemerkt dat use case eigenlijk een vervolgstap behoeven, namelijk een meer formele specificatie van het gedrag van het systeem. Inderdaad, enn daar zit dus het probleem: die formelere specs komen niet.
In die uitgebreidere specs zijn dan 3 onderdelen:
1. een formeler design voor de interactie met het systeem, maw: een soort
van formeel beschreven proces waaruit dan ook de specs van het syteem
interface voortvloeien.
Dit zou wel kunnen (met activity diagrams, BPMN of zoiets), maar wordt
voorzover ik weet zelden gedaan.
2. een design voor het UI. Soms wordt dit al in de uc's gedaan, soms
helemaal niet, en vaak klooit men men maar iets aan. Het zou ook fijn zijn
als er een formele taal voor beschikbaar was.
3. een echt systeemdesign voor de achterliggende functionaliteit, te
beginnen met een domeinmodel.
Dat kan heel goed, maar wordt, afgezien van een dattamodel, zelden gedaan.
Ik denk dat een probleem daarbij is dat uc's je op het verkeerde spoor
zetten. Bij uc's heb je een functiegerichte invalshoek. Dat is prima voor
een inventarisatie, maar voor de "binnenkant" van een systeme heb je daar
weinig aan. Maar de "draai" naar een coherent model is moeilijk, en wordt
dus zelden gemaakt.
En vooral in dat laatste zit dus de schadelijkheid van uc's: het is een
functionele benadering die haaks staat op meer samenhangende methoden voor
systeemontwerp, en stuurt de ontwikkeling dus precies de verkeerde kant
op.
Ik vind het zelf veel beter om eerst een domeinmodel te maken, en dan pas
te kijken naar wat men daar precies mee wil. Dat laatste kan dan eventueel
in de vorm van uc's.
In die uitgebreidere specs zijn dan 3 onderdelen:
1. een formeler design voor de interactie met het systeem, maw: een soort
van formeel beschreven proces waaruit dan ook de specs van het syteem
interface voortvloeien.
Dit zou wel kunnen (met activity diagrams, BPMN of zoiets), maar wordt
voorzover ik weet zelden gedaan.
2. een design voor het UI. Soms wordt dit al in de uc's gedaan, soms
helemaal niet, en vaak klooit men men maar iets aan. Het zou ook fijn zijn
als er een formele taal voor beschikbaar was.
3. een echt systeemdesign voor de achterliggende functionaliteit, te
beginnen met een domeinmodel.
Dat kan heel goed, maar wordt, afgezien van een dattamodel, zelden gedaan.
Ik denk dat een probleem daarbij is dat uc's je op het verkeerde spoor
zetten. Bij uc's heb je een functiegerichte invalshoek. Dat is prima voor
een inventarisatie, maar voor de "binnenkant" van een systeme heb je daar
weinig aan. Maar de "draai" naar een coherent model is moeilijk, en wordt
dus zelden gemaakt.
En vooral in dat laatste zit dus de schadelijkheid van uc's: het is een
functionele benadering die haaks staat op meer samenhangende methoden voor
systeemontwerp, en stuurt de ontwikkeling dus precies de verkeerde kant
op.
Ik vind het zelf veel beter om eerst een domeinmodel te maken, en dan pas
te kijken naar wat men daar precies mee wil. Dat laatste kan dan eventueel
in de vorm van uc's.
maandag 16 juli 2007
use cases considered harmful
De titel is een grapje. Use cases zijn wel degelijk nuttige instrumenten bij de specificatie van systemen. Tenminste: als ze op de goede manier worden gebruikt. Dus zonder teveel details, zonder beschrijving van het UI, en toegespitst op wat het resultaat van een actie van het systeem moet zijn. En de use case moet vooral niet beschrijven hoe een resultaat bereikt wordt, maw: hoe het systeem moet werken.
In de overgrote meerderheid van de gevallen gaan de use cases ver buiten de grenzen die hierboven zijn beschreven. En dan komen er problemen, want een (gedetailleerde) beschrijving van de werking, de binnenkant, van een systeem vereist een formele taal. Use cases zijn niet formeel. En als UI beschrijvingen worden opgenomen, dan moeten use cases worden gewijzigd als het UI wijzigt. Dat is niet te doen, want UIs zijn zoals bekend erg veranderlijk.
Goed, use cases moeten goed worden gebruikt (ja natuurlijk), en als het toch mis gaat, ligt dat aan degenen die use cases toepassen. Of niet?
Ik denk dat use cases als techniek een paar ingebouwde problemen heeft, en dat die bijdragen aan het wijdverbreide misbruik.
Allereerst: use cases maken deel uit van UML. Dat heeft tot gevolg gehad dat use cases allerwege werden gezien als NIEUW! en MODERN! en vooral ook: OBJECT-GEORIENTEERD! En men verwachtte ook dat de daaraan verbonden (veronderstelde) voordelen zich bij gebruik van use cases als vanzelf zouden manifesteren. Dat is niet gebeurd. Niet alleen omdat die voordelen nooit vanzelf komen, maar ook omdat use cases niets meer zijn dan in een nieuw jasje gestoken functionele ontwerpen. Beter gestrctureerd, enigszins gestandaardiseerd, een leuk diagrammetje waar je niks aan hebt er bij, jazeker, maar eigenlijk gewoon oude wijn in nieuwe zakken. Op zichzelf was er met die oude wijn niet zoveel mis, maar de verwachtingen waren hoger gespannen. En die komen niet uit, want use cases leiden niet tot een betere of een andere wijze van systeemontwikkeling. Dat verklaart waarschijnlijk ook hun populariteit: je hoeft er niks nieuws voor te leren.
Verder: use cases worden gepresenteerd als HET middel voor requirementsanalyse. Dat is onjuist. Voor hoog niveau requirements zijn use cases eigenlijk een niveau "te diep": je kunt pas use cases schrijven als je weet welke processen er zijn, wanneer die processen met het systeem interageren, en wat het resultaat van die interacties moet zijn. En voor het "in kaart brengen" van het business-domein zijn use cases ongeschikt. Daarvoor is een class-model (in UML) een veel beter middel. Maar in de gangbare projectopzet komt een class-model pas na de use cases (als het al komt, want meestal zit het project in de use cse trap, waarover zo dadelijk meer). Use cases worden dus vaak ingezet voor het verkeerde doel.
Tenslotte: use cases komen altijd vergezeld van een preek over hoe ze te gebruiken, en vooral hoe ze niet te gebruiken (zoiets als in de eerste alinea van deze past, maar dan veel langer). En die preken zijn nodig, want het is veel te makkelijk om ze verkeerd toe te passen. Dat komt doordat use cases volledig informeel zijn. Hoe je specificeert, wat de vereiste mate van detail is, het is allemaal open. De hoogste vorm van formalisatie is: een Word-template. Tsja. Fouten maken is dus veel te makkelijk.
Goed, use cases sluiten dus niet goed aan bij (moderne) methoden voor systeemontwikkeling, use cases worden verkeerd ingezet, en use cases zijn veel te informeel. Toch (of juist daardoor) zijn ze populair. De populariteit van use cases heeft ervoor gezorgd dat menig project in de use case trap terecht is gekomen. Hoe werkt de use case trap?
Een voorbeeld. Er moet een nieuw order entry systeem worden gebouwd, en dat moet op een bepaalde datum klaar zijn. Allereerst moet er een inventarisatie van de requirements komen. Daarvoor zetten we use cases in. Die zijn vreselijk onhandig daarvoor, want je moet dan gelijk de interacties van het systeem met de buitenwereld beschrijven, hoewel we nog helemaal weten niet of er wel een systeem moet komen! En veel requirements zullen in verscheidene use cases worden beschreven. Dat is dubbel werk. Maar niet getreurd, we huren een stelletje consultants in.
Bovendien heeft men geen goed zicht op het probleemdomein, dus worden allerlei wetenswaardigheden over het domein in de use cases opgeschreven, bijvoorbeeld dat een order tenmnste een en maximaal tien orderregels bevat. Die zijn daarvoor ongeschikt. En omdat men nu toch zo fijn met de gebruiker aan de gang is, wordt het UI ook gelijk maar even beschreven in de use cases.
Allemaal heel begrijpelijk, maar het gevolg is dat we al heel snel door de bomen het bos niet meer zien, en de tijd die in het projectplan was gereserveerd voor de use cases wordt ruimschoots overschreden. Maar we gaan toch maar door, want je moet toch beschrijven wat je nodig hebt? Maar op een gegeven moment is de einddatum van het hele project nog maar 4 maanden verwijderd. Moet er nou toch niet eens worden gebouwd?
Ja, eigenlijk wel. Gelukkig herinnert een consultant zich dat use cases eigenlijk helemaal niet zo gedetailleerd moeten zijn, dus kunnen we nu best stoppen. (Dat had ie wel eens eerder mogen zeggen.) De bouwers krijgen de stapel met use cases toegeworpen, en mogen op basis daarvan aan de gang gaan. Voor domein analyse is geen tijd meer, voor een goed ontwerp ook niet. Er moet geklopt worden!
Affijn, de bekende ellende dus. En een deel daarvan wordt veroorzaakt door de (verkeerde) toepassing van de use cases. Maar dat ligt niet alleen aan ons, ook wel een beetje aan de use case techniek zelf.
Misschien is die titel toch niet alleen maar een grapje...
In de overgrote meerderheid van de gevallen gaan de use cases ver buiten de grenzen die hierboven zijn beschreven. En dan komen er problemen, want een (gedetailleerde) beschrijving van de werking, de binnenkant, van een systeem vereist een formele taal. Use cases zijn niet formeel. En als UI beschrijvingen worden opgenomen, dan moeten use cases worden gewijzigd als het UI wijzigt. Dat is niet te doen, want UIs zijn zoals bekend erg veranderlijk.
Goed, use cases moeten goed worden gebruikt (ja natuurlijk), en als het toch mis gaat, ligt dat aan degenen die use cases toepassen. Of niet?
Ik denk dat use cases als techniek een paar ingebouwde problemen heeft, en dat die bijdragen aan het wijdverbreide misbruik.
Allereerst: use cases maken deel uit van UML. Dat heeft tot gevolg gehad dat use cases allerwege werden gezien als NIEUW! en MODERN! en vooral ook: OBJECT-GEORIENTEERD! En men verwachtte ook dat de daaraan verbonden (veronderstelde) voordelen zich bij gebruik van use cases als vanzelf zouden manifesteren. Dat is niet gebeurd. Niet alleen omdat die voordelen nooit vanzelf komen, maar ook omdat use cases niets meer zijn dan in een nieuw jasje gestoken functionele ontwerpen. Beter gestrctureerd, enigszins gestandaardiseerd, een leuk diagrammetje waar je niks aan hebt er bij, jazeker, maar eigenlijk gewoon oude wijn in nieuwe zakken. Op zichzelf was er met die oude wijn niet zoveel mis, maar de verwachtingen waren hoger gespannen. En die komen niet uit, want use cases leiden niet tot een betere of een andere wijze van systeemontwikkeling. Dat verklaart waarschijnlijk ook hun populariteit: je hoeft er niks nieuws voor te leren.
Verder: use cases worden gepresenteerd als HET middel voor requirementsanalyse. Dat is onjuist. Voor hoog niveau requirements zijn use cases eigenlijk een niveau "te diep": je kunt pas use cases schrijven als je weet welke processen er zijn, wanneer die processen met het systeem interageren, en wat het resultaat van die interacties moet zijn. En voor het "in kaart brengen" van het business-domein zijn use cases ongeschikt. Daarvoor is een class-model (in UML) een veel beter middel. Maar in de gangbare projectopzet komt een class-model pas na de use cases (als het al komt, want meestal zit het project in de use cse trap, waarover zo dadelijk meer). Use cases worden dus vaak ingezet voor het verkeerde doel.
Tenslotte: use cases komen altijd vergezeld van een preek over hoe ze te gebruiken, en vooral hoe ze niet te gebruiken (zoiets als in de eerste alinea van deze past, maar dan veel langer). En die preken zijn nodig, want het is veel te makkelijk om ze verkeerd toe te passen. Dat komt doordat use cases volledig informeel zijn. Hoe je specificeert, wat de vereiste mate van detail is, het is allemaal open. De hoogste vorm van formalisatie is: een Word-template. Tsja. Fouten maken is dus veel te makkelijk.
Goed, use cases sluiten dus niet goed aan bij (moderne) methoden voor systeemontwikkeling, use cases worden verkeerd ingezet, en use cases zijn veel te informeel. Toch (of juist daardoor) zijn ze populair. De populariteit van use cases heeft ervoor gezorgd dat menig project in de use case trap terecht is gekomen. Hoe werkt de use case trap?
Een voorbeeld. Er moet een nieuw order entry systeem worden gebouwd, en dat moet op een bepaalde datum klaar zijn. Allereerst moet er een inventarisatie van de requirements komen. Daarvoor zetten we use cases in. Die zijn vreselijk onhandig daarvoor, want je moet dan gelijk de interacties van het systeem met de buitenwereld beschrijven, hoewel we nog helemaal weten niet of er wel een systeem moet komen! En veel requirements zullen in verscheidene use cases worden beschreven. Dat is dubbel werk. Maar niet getreurd, we huren een stelletje consultants in.
Bovendien heeft men geen goed zicht op het probleemdomein, dus worden allerlei wetenswaardigheden over het domein in de use cases opgeschreven, bijvoorbeeld dat een order tenmnste een en maximaal tien orderregels bevat. Die zijn daarvoor ongeschikt. En omdat men nu toch zo fijn met de gebruiker aan de gang is, wordt het UI ook gelijk maar even beschreven in de use cases.
Allemaal heel begrijpelijk, maar het gevolg is dat we al heel snel door de bomen het bos niet meer zien, en de tijd die in het projectplan was gereserveerd voor de use cases wordt ruimschoots overschreden. Maar we gaan toch maar door, want je moet toch beschrijven wat je nodig hebt? Maar op een gegeven moment is de einddatum van het hele project nog maar 4 maanden verwijderd. Moet er nou toch niet eens worden gebouwd?
Ja, eigenlijk wel. Gelukkig herinnert een consultant zich dat use cases eigenlijk helemaal niet zo gedetailleerd moeten zijn, dus kunnen we nu best stoppen. (Dat had ie wel eens eerder mogen zeggen.) De bouwers krijgen de stapel met use cases toegeworpen, en mogen op basis daarvan aan de gang gaan. Voor domein analyse is geen tijd meer, voor een goed ontwerp ook niet. Er moet geklopt worden!
Affijn, de bekende ellende dus. En een deel daarvan wordt veroorzaakt door de (verkeerde) toepassing van de use cases. Maar dat ligt niet alleen aan ons, ook wel een beetje aan de use case techniek zelf.
Misschien is die titel toch niet alleen maar een grapje...
URL gewijzigd
Zo, ik heb de URL (sasmde.blogspot.com) gewijzigd naar saasaas.blogspot.com
Want dat is eigenlijk wat ik wil: het beheer van software (bijvoorbeeld Saas) aanbieden als een service.
Want dat is eigenlijk wat ik wil: het beheer van software (bijvoorbeeld Saas) aanbieden als een service.
vrijdag 13 juli 2007
vrijdag 6 juli 2007
donderdag 5 juli 2007
Semantics
David Frankel vindt dat er semantische interoperabiliteit moet komen, om de belofte van SOA's te realiseren.
En gelijk heeft ie. Hij vestigt de aandacht op allerhande initiatieven om te komen tot gedeelde emantische definities. Dat is inderdaad heel waardevol. Daarnaast (voeg ik er aan toe) heeft het ook zin voor een bedrijf om vanuit een abstract business-model te werken. Daarin wordt beschreven wat de semantiek van de gegevens is, en de mapping op feitelijke datastructuren kan dan eenvoudig plaatsvinden. het is niet meer nodig (zoals nu vaak het geval is) om tussen de feitelijke datastructuren mappings te ontwikkelen. Immers, die kunnen worden afgeleid uit de mappings op het abstracte model.
En gelijk heeft ie. Hij vestigt de aandacht op allerhande initiatieven om te komen tot gedeelde emantische definities. Dat is inderdaad heel waardevol. Daarnaast (voeg ik er aan toe) heeft het ook zin voor een bedrijf om vanuit een abstract business-model te werken. Daarin wordt beschreven wat de semantiek van de gegevens is, en de mapping op feitelijke datastructuren kan dan eenvoudig plaatsvinden. het is niet meer nodig (zoals nu vaak het geval is) om tussen de feitelijke datastructuren mappings te ontwikkelen. Immers, die kunnen worden afgeleid uit de mappings op het abstracte model.
Abonneren op:
Posts (Atom)