Afstudeeronderwerpen Lex Wedemeijer Hierbij een aantal onderwerpen die wellicht geschikt zijn als afstudeeronderwerp. Het accent van mijn onderzoek ligt op het (steeds beter) ondersteunen van bedrijfsprocessen, bedrijfsregels en bedrijfsdatamodellen, door middel van het verwerven van inzicht in, en opbouwen en toetsen van modelmatige aanpakken. Denk bijvoorbeeld aan het beoordelen c.q. verhogen van kwaliteit en flexibiliteit, door hiervoor onderzoek in de bedrijfspraktijk te doen, of door een goede methodische aanpak te beschrijven. De preciese afbakening van een onderzoeksopdracht vindt altijd in gezamenlijk overleg plaats; dat is meteen al de eerste fase van het afstudeeronderzoek. Afstudeeronderwerpen Lex Wedemeijer... 1 Abstracte bedrijfsregels concreet formuleren... 1 Tutoring tool voor bedrijfsregels... 2 Bedrijfsregels om het bedrijfsproces resp. datamodel te specificeren... 2 Regels om regels te specificeren... 3 Flexibiliteit van bedrijfsprocessen (met behulp van componenten)... 3 Maturity en metrics... 4 Verdieping van Ampersand en onderliggende technieken... 5 Abstracte bedrijfsregels concreet formuleren Rule elicitation is het vaststellen van regels in de praktijk. Hierbij vertrouwt men op beschrijvingen in natuurlijke of een semi-formele taal. Business rule analisten zetten deze om in abstracte specificaties die (vrijwel) direct executeerbaar zijn in systemen. Maar de abstracte specificaties zijn vaak lastig uit te leggen aan gebruikers in de bedrijfsomgeving. Gewenst is dat de abstracte regels automatisch kunnen worden ge(her)formuleerd in een concrete taal die "normaal" klinkt en begrijpelijk is. * Beschrijf een of meer routines waarmee (bepaalde klassen van) abstracte regels kunnen worden omgezet in een vorm die direct begrepen wordt door gebruikers. Doeltaal kan semi-formeel zijn (RuleSpeak) of natuurlijke taal (Nederlands). Of in andere vormen: grafisch, of realistische voorbeelden. * Valideer dat gebruikers uit de bedrijfsomgeving de regels juist (of tenminste: juister) interpreteren ná de omzetting, dan ervoor. * Bouw een hulpmiddel dat testgevallen genereert vanuit de abstracte regels; enerzijds om de regels in hoofdlijnen te demonstreren, anderzijds om ze in alle detail te testen. * Gegeven de mogelijkheden of beperkingen van de automatische (her)formulering, geef aanbevelingen voor de toepassing ervan, inclusief de aanpak van het (laten) valideren van de bedrijfsregels door praktijkmensen. Toegang tot gebruikers met uiteenlopende achtergronden (kennisniveau's)
Tutoring tool voor bedrijfsregels Rule elicitation is het vaststellen van regels in de praktijk. Hierbij werkt men met beschrijvingen in natuurlijke of een semi-formele taal. Het vak "Ontwerpen met Bedrijfsregels" behandelt het abstract specificeren van bedrijfsregels in binaire Relatie Algebra. Bij de afleiding van abstracte specificaties op basis van requirements in normale taal kunnen analisten allerlei fouten maken. Gewenst is dat de uiteindelijke abstracte specificaties één op één corresponderen met de originele requirements opgesteld door de gebruikers uit de praktijk. * Classificeer de soorten van fouten die kunnen optreden bij het begrijpen en interpreteren van bedrijfsregels als ze abstract zijn geformuleerd, resp. als ze concreet zijn. Stel vast hoe in de praktijk te herkennen valt welke foutsoort aan de orde is. * Bepaal voor elke foutsoort een leertraject, een toepasselijke reeks van oefeningen, bijvoorbeeld in de gedaante van een (automatische) exerciseassistent (tutor tool). * Ontwikkel uiteenlopende representatie-vormen en beoordeel in hoeverre de vorm invloed heeft op het leereffect. Denk aan tekstuele weergave met of zonder kleuren, diagrammen met verschillende betekenissen van pijlen of ordeningen, tabellen etc. * Valideer dat het leertraject ertoe leidt dat analisten de betreffende fouten leren herkennen en vermijden. * Geef aanbevelingen voor rule elicitation en (leertraject van) business rule analisten. Toegang tot analisten met uiteenlopende achtergronden (kennisniveau's) Haskell als engine onder Ampersand: http://haskell.org/haskellwiki/introduction Bedrijfsregels om het bedrijfsproces resp. datamodel te specificeren Voorstanders van de Business Rules Approach claimen dat bedrijfsregels bepalend zijn voor een bedrijfsproces; zowel voor het procesmodel als voor de procesrealisatie. De regels zouden een meer compacte, en eenvoudiger beschrijving bieden. Bovendien claimt men dat regels een hogere flexibiliteit bieden omdat deze declaratief zijn, in tegenstelling tot de traditionele imperatieve beschrijving van de bedrijfsprocessen. Eenzelfde claim wordt ook wel gemaakt t.a.v. het datamodel, d.w.z. de (soorten) van data die relevant zijn in de bedrijfsvoering. * Laat zien hoe een proces rechtstreeks kan worden afgeleid uit een set regels * Ontwerp een tool dat alle plausibele herstel-acties bepaalt voor regel-inbreuk * Stel vast aan welke voorwaarden de set regels moet voldoen voor een correcte afleiding.
* Onderbouw de bovenstaande claims richting gebruikers. Middels gestructureerde bewijsvoering enerzijds, anderzijds door een (voldoende groot) aantal voorbeelden uit te werken waarbij mensen uit de gebruikerspraktijk de hogere kwaliteit (eenvoud, flexibiliteit) bevestigen. * Onderzoek of, en zo hoe bedrijfsregels tekortschieten om tot een werkbare procesbeschrijving te komen. Bijv.: kan het proces blokkeren? Is er een "eindeloze lus"? * Dergelijk onderzoek kan ook worden verricht t.a.v. het datamodel: kan een compleet en correct datamodel worden afgeleid uit een set regels, aan welke voorwaarden dient de set regels te voldoen, wanneer zullen bedrijfsregels tekortschieten in het kunnen afleiden van een datamodel etc. Kennis van petrinetten en/of CSP theorie; resp van datamodellering Regels om regels te specificeren Op het gebied van bedrijfsregels zijn er enkele landmark documenten: het Business Rule Manifesto, en beschrijving van de RuleSpeak semi-formele taal. Hierin zijn regels vastgelegd voor het vastleggen van... regels. * Analyseer de regels die zijn vastgelegd in het Business Rules Manifesto resp RuleSpeak en stel er een Ampersand specificatie voor op. * Stel tekortkomingen in deze specificaties vast, en geef verbetervoorstellen. * Ontwerp op basis van de Ampersand specificaties een tool dat analisten ondersteunt bij het schrijven van regels conform de eisen van BRM resp RuleSpeak Ontwerpvaardigheid, goede vaardigheid in Relatie Algebra. Business Rules Group: http://www.businessrulesgroup.org/home-brg.shtml Flexibiliteit van bedrijfsprocessen (met behulp van componenten) Bedrijfsprocessen beogen te beschrijven hoe de bedrijfsactiviteiten worden uitgevoerd voor het behalen van gestelde doelen zoals: vragen van klanten, kritische proces-indicatoren, succesfactoren, wettelijke vereisten etc. Maar die gestelde kaders laten nog veel ruimte om een proces in te richten. Daarnaast zullen de doelen in de loop van de tijd kunnen wijzigen. Voorts is er component-based development, waarbij het idee is om gedetailleerd programmeren te vervangen door de inzet van grote componenten waarvan alleen het algemeen gedrag hoeft te worden gespecificeerd. Ontwikkelingen op dit gebied zijn Webservices en REST-ful services. Maar in hoeverre realiseert de CBD-aanpak de beoogde doelen?
* Als verschillende bedrijven hun IT-architectuur inrichten middels componenten, welke keuzes zijn dan aan de orde? Leveren concepten van webservices en SOA voldoende mogelijkheden om alle keuzes afdoende te beantwoorden? * Met welke gestructureerde aanpak(ken) komt men tot een correcte en complete opzet voor een IT-architectuur gebaseerd op componenten? * Als verschillende bedrijven een proces inrichten om eenzelfde doel te realiseren, welke verschillen zijn dan zichtbaar? Wat voor een gestructureerde aanpak(ken) maakt het mogelijk om tot een correcte en complete verschilanalyse te komen? * Zijn er patronen in de procesverschillen te herkennen. Welke oorzaken en verklaringen zijn hebben die? Als informatiebron kunnen gebruikers uit praktijk worden benaderd, proces-logs, (in)formele requirements documenten, etc. * Welke consequenties heeft het gebruik van componenten als wijziging in de IT-architectuur noodzakelijk blijken? Welke consequenties zijn er als een procesdoel verandert? * Vertaal de inzichten in aanbevelingen voor Component-Based Development. * Vertaal de verworven inzichten naar aanbevelingen voor een (eenmalig) proces- of regelontwerp, en voor (latere) wijzigingen op een ontwerp (beheer). Veel kennis van Petrinetten. Goede vaardigheid in procesontwerp. veel artikelen van prof. van der Aalst http://wwwis.win.tue.nl/~wvdaalst/ Maturity en metrics Zowel voor bedrijfsprocessen als voor bedrijfsregels zijn in de literatuur "maturity modellen" beschreven. Zo'n benadering stelt dat bij sommige bedrijven de processen (resp de bedrijfsregels) zijn ingericht op een "hoger niveau". Maar welke niveau's onderkennen we, en hoe valt het toepasselijke niveau vast te stellen? En hoe waardevol zijn dergelijke modellen? * bepaal welke informatiebron(nen) in welke mate betrouwbaar zijn om een maturity niveau op te baseren. Denk aan interviews met gebruikers uit de praktijk, proces-logs, (in)formele requirements documenten, etc. * Stel vast welke beoordelingscriteria kunnen/moeten worden gehanteerd. Leid er eenduidige, en zo objectief mogelijke metrieken uit af om het niveau vast te stellen. * Onderbouw dat juist deze criteria en metrieken relevant zijn, en geen andere. Dit kan deels (niet volledig) zijn gebaseerd op opinies van praktijkdeskundigen * Formuleer een gestructureerde en objectieve aanpak om een maturity niveau op correcte en controleerbare wijze vast te stellen. * Welke voorspellende waarde hebben deze criteria voor flexibiliteit, als er een proces (of regel) moet worden veranderd? * Vertaal de verworven inzichten naar aanbevelingen voor procesontwerp c.q. rule elicitation en analyse Toegang tot deskundigen met uiteenlopende achtergronden Wil van der Aalst
Verdieping van Ampersand en onderliggende technieken Ampersand is gebaseerd op de Relatie Algebra. Een Ampersand specificatie bevat een abstracte structuur (concepten, relaties, regels), het verband met de bedrijfspraktijk (explanations in semi- of informele taal), en concrete data (testgevallen). In de scripting taal van Ampersand kunnen zaken soms op meerdere manieren worden gespecificeerd. De analist krijgt daardoor keuzevrijheid, maar het kan ook verwarring opleveren. * Welke taalconstructies zijn equivalent/redundant? Welke constructies leveren een restrictie op (of juist: een verruiming) van een verwante? * Leid uit de onderliggende wiskundige theorie een eenduidige ("essential") scripting taal af, en/of ontwerp een eenduidige grafische taal. * Gegeven een set bedrijfsregels, benoem alle mogelijke wijzigingen op die set (altijd de toevoeging, wijziging, en/of verwijdering van onderdelen van een regel). Kunnen we de regels zo noteren dat al dergelijke wijzigingen eenvoudig zijn te signaleren? * Wat is van elk soort van wijziging de te verwachten impact of change? Welke constructies kunnen elkaar worden overgevoerd zonder informatieverlies * Welke wijzigingen komen in de praktijk het meeste voor, eventueel in bepaalde combinaties (change patterns). Goede vaardigheid in zuivere wiskunde, en in Relatie Algebra. Toegang tot analisten met uiteenlopende achtergronden (kennisniveau's) Theorie van parsers