Domeinmodellering-Opdracht/2 Activiteiten/Casus/Deelopdracht 1/2 Opdrachtbeschrijving

Uit Werkplaats
Ga naar: navigatie, zoeken

Domeinmodellering-Opdracht


 © comments



Deelopdracht 1 van de ziekenhuiscasus

Inleiding

In deze casus [voor de casus-beschrijving: zie Blackboard / Course Materials / Casus] krijg je te maken met een mogelijk automatiseringsproject voor een deel van de totale administratie van een 'ietwat achtergebleven' ziekenhuis in een snelgroeiende, middelgrote stad. In zo'n ziekenhuis moet een omvangrijke administratie worden bijgehouden van niet alleen patiënten- en hun behandelingsgegevens, maar bijvoorbeeld ook van personeels- en magazijngegevens.


Deze eerste casus-deelopdracht betreft het uitvoeren van een Organisatie/veranderings-analyse. Uit het [in de Course Materials / Casus-map] apart geplaatste dictaat-hoofdstuk (8) (Organization_Studies.pdf), halen we over “Change-oriented Organization Studies”:

At the highest level, COS is divided into the following:
1. Analysis of problems, current situation and needs
2. Study of change alternatives
3. Choice of change approach


Activiteiten

a) De [deel]opdracht aan je groepje is om allereerst zelfstandig de paragrafen 8.1 en 8.2 van het in de casus-map geplaatste hoofdstuk over ‘Organization Studies’ te bestuderen en om daarna ‘stap-voor-stap’ voor de beschreven casus-stuatie de verschillende vereiste activiteiten uit te voeren. Waar gevraagd wordt: “A crude activity model, consisting of activity graphs, is produced.” ben je vrij om een eigen manier van grafisch weergeven te gebruiken; als je tekeningen maar duidelijk en eenduidig te interpreteren zijn. Hou daarbij voor ogen, dat we een ‘gegevenslandkaart’ van deze organisatie willen samenstellen, waarin beknopt maar duidelijk is aangegeven, wat voor soorten gegevens en activiteiten erbinnen bestaan en welke activiteiten te maken hebben met welke gegevens. Je zou bijvoorbeeld ‘activiteiten’ met een cirkel/ellips kunnen aanduiden en gegevens met een rechthoek en door middel van pijlen aangeven of gegevens invoer of net uitvoer voor activiteiten zijn.

Als je er niet in slaagt om op een vereiste deelactiviteit een zinvol antwoord te geven, raak dan niet in paniek. Het kan zijn dat die gevraagde activiteit voor deze casus-situatie ‘niet van toepassing’ is. Belangrijk zijn natuurlijk vragen over ‘waarom’ je iets doet of er een voorkeur voor aangeeft e.d..


b) Een tweede uit te werken punt is het maken van een overzicht van gewenste functionaliteit van het te bouwen informatiesysteem en de actor[en] die bij elke functie optreedt/optreden. Begin ermee om dit overzicht in een tabelvorm (functonaliteit <--> actor[en] ) te plaatsen. Maak tenslotte een [UML] use case diagram om aan de opdrachtgever/gebruiker duidelijk te kunnen maken wat volgens jullie het te ontwerpen systeem aan functionaliteit moet hebben.
N.B. je hoeft hier dus géén volledige use case-beschrijvingen te gaan opstellen, je hoeft hier alleen een use case diagram te maken. Ook hoef je [nog] geen constructies als <extends> en/of <uses> daarin aan te geven. Later zullen we op deze constructies terugkomen.

Hint: zie b.v. http://en.wikipedia.org/wiki/Use_case_diagram voor een korte beschrijving over use case diagrams.


c) Een derde uit te werken punt is het nu al opstellen van een aantal ‘onderzoeks’-vragen waarop je bij casus-deelopdracht 3 een antwoord hoopt te vinden.

  1. Een eerste vraag daarbij is om uit te zoeken of en zo ja, hoe het mogelijk is om op een flexibele wijze geldende regels voor het informatiesysteem aanpasbaar te maken (zo geldt op dit moment dat een opgenomen patiënt nooit méér dan drie medicijnverstrekkingen nog ‘lopende’ mag hebben. Stel je bijvoorbeeld voor dat men dat aantal over een aantal jaren wil veranderen in vier.). Als zulke waarden ‘hard-coded’ in een programmeertaal worden opgenomen, zijn ze niet flexibel te veranderen.
  2. Bedenk/formuleer daarnaast zelf drie ‘management-vragen’ waar (bij deelopdracht 3) door het informatiesysteem een antwoord zou moeten kunnen worden gegeven.
    Hint: ‘het management’ is meestal niet geïnteresseerd in detailvragen als “Hoelang is vorig jaar patiënt Pietersen opgenomen geweest en op welke afdeling was dat?” maar wel in vragen over afgeleide kennis, zoals opnames per afdeling per maand en of er een verband bestaat tussen aantal medicijnverstrekkingen en leeftijd van de patiënt.


Doe het serieus, maar maak er géén levenswerk van. Een indicatie voor de omvang van het in te leveren totale rapport + use case diagram + ‘onderzoeks’-vragen is 4 à 5 pagina's.


Gebruik voor het werken aan deze [deel]opdracht de elektronische DM-werkplaats.
Maak één ‘uitwerkingsdocument’ en één ‘reflectiedocument’ per groep. Laat degene die voor deze deelopdracht de verslagen van groepsbesprekingen maakt, die documenten aanmaken en laat hem/haar er ook voor zorgen [door het aanpassen van de 2 Access-rechten-regels voor de andere twee groepsleden] dat het uitwerkingsdocument [naast de docenten] door slechts de 3 groepsleden ingezien en bewerkt kan worden.
Het reflectiedocument moet uiteraard weer door iedereen ingezien kunnen worden en gebruikt worden om ook vragen aan anderen te stellen. En uiteraard geef je ook feedback op vragen van andere groepen…


De dead line voor het inleveren van jullie [papieren] COS-rapport is dinsdagmiddag 20 oktober 2009 om 16:00u (op de kamer van Ger Paulussen: HG02.068).


Voor het gemak vermelden we hier nog, dat je op een sheet van de [organisatorische] inleiding op deze cursus [Course Info: “DM Cursus: Opzet, Organisatie en educational approach”] over het onderwerp ‘de casus’ het volgende aantreft:

  • Bij het college hoort een casus, die gedurende het gehele semester doorloopt, en gestructureerd is via deelopdrachten.
  • Aan de casus(deel)opdrachten wordt in groepjes van 3 personen gewerkt.
  • Per deelopdracht verrichten de deelnemers de volgende activiteiten:
    1. Vooraf wordt per deelopdracht een werkplanning gemaakt voor wie wanneer wat gaat doen. Ook wijst de groep roulerend aan iemand de rol van woordvoerder toe, die op plenaire bijeenkomsten het woord zal voeren en de groeps-deelproducten toelicht en verdedigt. In de planning wordt expliciet vermeld, wie voor die deelopdracht de rol van woordvoerder heeft.
    2. Een [roulerend] groepslid maakt verslag van de onderlinge besprekingen, met daarin de werkafspraken.
    3. Uiterlijk de donderdag van de eerste deelopdracht-week wordt de werkplanning aan het begin van het college ingeleverd bij de docent.
    4. De gehele groep werkt aan het uitvoeren van de deelopdracht.
    5. Op het einde wordt [uiteraard vóór het verstrijken van de deadline] het groepsproduct ingeleverd. Daarbij behoort ook een evaluatie te zitten over o.a. naleven van de werkplanning, leermomenten, wat zou je een volgende keer anders doen, e.d.