De wetenschap van ontwerpen bestaat in het voorkomen van de moeilijkheden in de uitvoering. Hoofdstuk 14. Taakgebied Ontwerp

Transcriptie

1 De wetenschap van ontwerpen bestaat in het voorkomen van de moeilijkheden in de uitvoering. Hoofdstuk 14 Taakgebied Ontwerp V1.1 / 01 september 2015

2 Hoofdstuk Plaats in het MCTL-framework Achtergrond Definities Doel van dit taakgebied Hoe weet je dat het doel is bereikt? Input, activiteiten, output Activiteit: Inventariseren relevante randvoorwaarden Activiteit: Bijwerken gegevensmodel Activiteit: Bijwerken constraints Activiteit: Bijwerken sequentie- en communicatiediagrammen Activiteit: Bijwerken toestandsdiagrammen Activiteit: Bijwerken beschrijving interfacing met omgeving Activiteit: Bijwerken niet-functionele systeemeisen Activiteit: Bijwerking beschrijving organisatie inrichting Activiteit: Aanpassen rolbeschrijving(en) Relaties met andere onderdelen van MCTL Opmerkingen Andere ontwerptechnieken Aard van gegevens Hergebruik Modulaire opbouw van systemen Nuttige websites en boeken V Pagina 14-2

3 HOOFDSTUK 14 TAAKGEBIED ONTWERP In dit taakgebied wordt voortgebouwd op de in de vorige taakgebied opgestelde requirements. Deze requirements beschrijven vanuit het bedrijfsproces gezien de behoefte aan wijzigingen. In het taakgebied Ontwerp wordt de vertaling op functioneel niveau gemaakt naar de benodigde computertechnologie: welke functionele aanpassingen aan de software zijn nodig, wat moet er aan het gegevensmodel worden aangepast en verandert het gebruik van hardware zodanig dat hier ook aanpassingen nodig zijn? Er wordt kortom een volledige, eenduidige en specifieke beschrijving van de wijzigingen in de systemen gemaakt. 1. PLAATS IN HET MCTL-FRAMEWORK Het taakgebied Ontwerp maakt onderdeel uit van het taakcluster Change support: 2. ACHTERGROND In requirements management ligt de focus op het bedrijfsproces en de wijzigingen daarin. Bij ontwerp ligt de focus op de onderliggende benodigde systemen. Deze matchen doorgaans niet een-op-een met het bedrijfsproces. Soms kan het handig zijn om één systeem te bouwen dat meerdere V Pagina 14-3

4 bedrijfsprocessen ondersteund (integratie), soms kan het beter zijn één bedrijfsproces te ondersteunen door meerdere, losstaande systemen. Het volgende schema illustreert deze situatie: Gegevens en functionaliteiten kunnen vaak op meerdere plaatsen worden gebruikt. Binnen ontwerp wordt gestreefd naar het meervoudig gebruik van componenten. Hierdoor worden kosten verlaagd, fouten voorkomen (doordat gegevens maar op één plaats worden vastgelegd) en wordt het onderling samenwerken in een organisatie gestimuleerd: er is immers waar mogelijk sprake van één gedeelde omgeving. 3. DEFINITIES Binnen het taakgebied ontwerp worden enige definities gebruikt. Degene die nog niet eerder ter sprake zijn gekomen worden hier genoemd: Definitie entiteit Een entiteit is een op zichzelf staande eenheid, in het algemeen als zelfstandig naamwoord te verwoorden. Voorbeelden: Docent Les Leslokaal Let op! Een entiteit kan een representatie zijn van zowel en feit, een gegeven, informatie als kennis. Ter herhaling daarvan de definities in onderstaand kader: Feiten: werkelijke gebeurtenissen, omstandigheden of eigenschappen. Bijv. de zon schijnt in Amsterdam, het huis is 10 m hoog, mijn banksaldo is 645,90. Gegevens: registraties van feiten. Gegevens kunnen worden (in bit-formaat; de befaamde 0 - en en 1 -en) vastgelegd in databases op computers (en natuurlijk ook op papier of andere V Pagina 14-4

5 gegevensdragers). Met behulp van software kunnen gegevens worden gemanipuleerd: ge- en verplaatst, bewerkt, verwijderd, samengevoegd of gesplitst etc. Omdat in computers altijd alles in bits wordt vastgelegd, kan kort gezegd een computer op dit gebied dus worden gezien als een grote bit-schuif en manipulatiemachine. Informatie: gegevens die betekenis hebben voor de ontvanger van de gegevens. Of iets informatie is hangt dus af van de ontvanger en niet van de zender. Bijv. of een trein op tijd vertrekt van een bepaald station zal voor heel veel mensen geen informatie zijn, maar voor sommigen wel. Of een factuur met specificatie: De specificatie zal voor sommigen relevant zijn (dus informatief) en voor anderen niet. Kennis: ontstaat uit informatie samen met vaardigheden en ervaring. Bijv. kennis over het verhelpen van storingen aan een auto. Er wordt wel onderscheid gemaakt in zwakke en sterke entiteiten: Een sterke entiteit is een entiteit die op zichzelf kan bestaan, bijv. docent of klaslokaal. Een zwakke entiteit bestaat slechts met een referentie; bijv. een les (die refereert aan docent en klaslokaal; immers, zonder docent of klaslokaal geen les). Definitie entiteit-woordenboek De verzameling van alle entiteiten die in de gehele organisatie worden gebruikt inclusief de definitie ervan. Definitie attribuut Een attribuut is een eigenschap van een entiteit. Voorbeelden: Docent: docentnummer, voornaam, achternaam, telefoonnummer, adres, datum-indienst Les: lesnummer, naam, leslokaalnummer, docentnummer, datum, starttijd, eindtijd Leslokaal: leslokaalnummer, locatie Definitie relatie Een relatie geeft een verband tussen entiteiten aan. Voorbeelden: Een docent geeft les Een les vindt plaats in een bepaald leslokaal Definitie constraint Een constraint is een beperking, regel of conditie waaraan voldaan moet worden. In de ontwerpfase worden deze formeel vastgelegd. Bijvoorbeeld: er mag niet meer dan één les op hetzelfde moment in hetzelfde leslokaal worden gepland. Of een docent mag maar op één datum / tijdsblok op één les worden ingepland. 4. DOEL VAN DIT TAAKGEBIED Het doel van het taakgebied Ontwerp is het creëren van een samenhangend ontwerp van het complete conceptuele en logische gegevensmodel, het functioneel beschrijven van alle bijbehorende functionaliteiten (logica en bijbehorende interfaces) en het beschrijven van de niet functionele aspecten als benodigde performance en capaciteit. V Pagina 14-5

6 5. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: Het bijgewerkte ontwerp blijkt, gerelateerd aan de doelstellingen, in het verdere verloop van de aanpassingen voor minstens 95% volledig (dekkend) en juist. Met andere woorden: er zijn minder dan 5% verdere aanpassingen nodig om de achterliggende doelstelling(en) van de wijziging te behalen De realisatie kan op basis van het ontwerp zonder verdere informatie worden uitgevoerd Naast de binnen ontwerp aangepaste elementen blijken geen andere elementen gewijzigd te moeten worden Nadat de wijzigingen in productie zijn genomen blijken de wijzigingen ten opzichte van het ontwerp voor minimaal 90% volledig juist (dus behoeven geen verdere aanpassing) (Genoemde percentages zijn uiteraard indicatief) 6. INPUT, ACTIVITEITEN, OUTPUT De activiteiten in dit taakgebied zijn als volgt schematisch weer te geven: Niet altijd zal elke activiteit nodig zijn, er moet met dit schema dus met het nodige gezond verstand om worden gegaan. Het is wel aanbevelenswaardig alle activiteiten elke keer na te lopen en als default geldt dat elke activiteit wordt uitgevoerd. Met andere woorden: u moet dus een reden hebben om hier iets niet te doen en niet andersom. Ook het detailleringsniveau kan een punt van discussie zijn. De stelregel is dat, omdat het hier doorgaans gaat om aanpassingen / uitbreidingen op bestaande systemen, het oorspronkelijk (bij de nieuwbouw) gekozen detailleringsniveau hier de richtlijn is. 1. ACTIVITEIT: INVENTARISEREN RELEVANTE RANDVOORWAARDEN In deze activiteit worden de relevante randvoorwaarden geïnventariseerd. Deze randvoorwaarden kunnen afkomstig zijn vanuit infrasupport of applicatie support en leveranciers, bijvoorbeeld vanwege V Pagina 14-6

7 een bepaalde architectuur op basis waarvan wordt gewerkt. Randvoorwaarden kunnen echter ook uit de gebruikersorganisatie afkomstig zijn. Voorbeelden hiervan zijn bijvoorbeeld randvoorwaarden in verband met juridische aspecten, vanuit ergonomisch oogpunt, vanuit beveiliging (functiescheiding) of bedrijfsstandaarden. 2. ACTIVITEIT: BIJWERKEN GEGEVENSMODEL Het bijwerken van het gegevensmodel bestaat schematisch weergeven uit de volgende stappen: Hierna worden de activiteiten op functioneel terrein verder uitgewerkt. 1. Bijwerken conceptueel gegevensmodel Als eerste dient de betekenis van alle entiteiten die in de requirements worden genoemd eenduidig vast te staan. Dat lijkt een vanzelfsprekendheid, maar het voorbeeld in onderstaand kader geeft de problematiek goed weer: Voorbeeld: entiteit klant Het lijkt zo eenvoudig: vrijwel elk bedrijf heeft wel klanten. En dus een klantenbestand. Maar wat is eigenlijk een klant? a) Is een klant een persoon of een bedrijf die een bestelling heeft gedaan? b) Of is een klant een persoon of bedrijf waar werkelijk iets is geleverd? c) En wat dan als de levering is afgeleverd, maar teruggezonden? d) Of als een klant al jaren niets meer heeft besteld? Met andere woorden, wie werkelijk als klant wordt gezien is nog niet meteen een uitgemaakte zaak. Maar, zo zult u zeggen, wat is eigenlijk het probleem? Wel, stel dat afdeling marketing een actie op touw wil zetten richting klanten. Willen ze dan de echte klanten, de potentiele klanten of juist de huidige klanten? U voelt het probleem waarschijnlijk al; als gegevens over klanten niet goed zijn gedefinieerd en vastgelegd, dan zijn ze vervolgens niet goed bruikbaar. Er moet dus een entiteit-woordenboek (ook soms wel data dictionary genoemd) bestaan waarin alle entiteiten die in de gehele organisatie worden gebruikt zijn vastgelegd. Vervolgens worden alle entiteiten die in de requirements worden genoemd hier getoetst aan die bestaande beschrijvingen. De volgende situaties zijn dan te onderscheiden: a) Is er een match (zelfde term + zelfde betekenis), dan is geen verdere actie nodig. V Pagina 14-7

8 b) Indien een term reeds bestaat, maar in een andere betekenis (een homoniem), dan is er over het algemeen een aanzienlijk probleem. Er moet dan eerst worden nagegaan waar de versie die nu in het entiteit-woordenboek is opgenomen wordt gebruikt en waar de afwijking door is ontstaan. De oplossing kan bestaan uit het aanpassen van de entiteit in het entiteitwoordenboek (en dus ook aanpassing op elke plek waar deze entiteit wordt gebruikt), het conformeren van de entiteit uit de requirements aan de beschrijving van deze entiteit in het entiteit-woordenboek, ofwel het anders benoemen van de entiteit zodat een nieuwe ontstaat. Zie voor de laatstgenoemde oplossing verder onder c (hieronder). Bijv. les zou kunnen refereren aan een les in een leslokaal met docent maar les zou ook kunnen refereren aan een informatieblok in een elektronische leeromgeving. Oplossing is dan les te herdefiniëren ofwel een nieuwe term introduceren zoals bijv. e-les. c) Indien een term nog niet bestaat in het woordenboek, dan kan deze worden toegevoegd. De nodige terughoudendheid moet echter worden betracht. Zeker bij systemen die al wat langer bestaan is het zinvol de vraag te stellen: Waarom is deze entiteit niet al eerder opgenomen?. Het gevaar is dat dezelfde entiteiten onder verschillende namen in het entiteiten-woordenboek en daarmee uiteindelijk in het systeem terecht komen. Dat moet vanzelfsprekend worden voorkomen; synoniemen leiden doorgaans tot grote verwarring. Bijv. leraar, terwijl docent al bestaat. Of klaslokaal terwijl leslokaal al bestaat. Samen met de vastlegging in het entiteiten-woordenboek moet ook het type van de entiteit worden vastgesteld en vastgelegd. Het type kan zijn: - Numeriek (alleen cijfers of eventueel met komma s of wetenschappelijke notatie) - Datum - Datum + tijd (timestamp) - Alfabetisch (alleen letters uit alfabet) - Tekst (tekens uit alfabet, speciale tekens en cijfers) - Afbeelding - Video - Geluid - Vector Ten derde dienen de eisen die aan de entiteit worden gesteld te worden vastgelegd. Voorbeelden van dit soort eisen / restricties zijn: - Aantal tekens - Limieten: waarde moet in bepaalde bandbreedte liggen - Bepaalde tekens zijn bij invoer uitgesloten (bijv. bijzondere tekens, of in het geval van alfabetische tekens zijn alleen Europese toegestaan en geen Chinese, Thaise etc.) - Bij invoer zijn geen datums in het verleden of juist geen datums in de toekomst toegestaan - De waarde van de entiteit moet binnen een bepaalde bandbreedte liggen - Vereiste nauwkeurigheid - Atomair ja / nee (met andere woorden, geen samengestelde entiteit zoals naam, maar splitsen in voornaam, tussenvoegsels en achternaam) - Omvang - Kwaliteit (bijv. bij geluid, video, afbeelding) Ten vierde kan worden aangegeven hoe een bepaalde entiteit wordt gebruikt c.q. mag worden gebruikt. Bijvoorbeeld de datum aanschaf apparaat kan eveneens de ingangsdatum van de garantietermijn zijn. V Pagina 14-8

9 Oppassen met meervoudig gebruik van entiteiten In het algemeen moet overigens erg worden opgepast met het meervoudig gebruik van een entiteit. Bijvoorbeeld de datum registratie van een voertuig koppelen aan betaaltermijnen (bij de belastingdienst of een autoleasebedrijf). Dit kan allerlei perikelen geven indien het beleid rondom betaaltermijnen wijzigt, bijvoorbeeld indien betaaltermijnen opeens altijd per 1 e van de maand of per jaar moeten ingaan. De totale beschrijving van alle wijzigingen in het entiteiten-woordenboek op conceptueel niveau geeft een goede basis voor het bijwerken van het logisch gegevensmodel. Beschrijving entiteit voorzien van voorbeeld Het is aanbevelenswaardig om elke entiteit te voorzien van een concreet voorbeeld. Daardoor wordt als het goed is de beschrijving van de entiteit veel helderder. 2. Bijwerken logisch gegevensmodel Het logisch gegevensmodel legt alle attributen bij alle entiteiten en alle relaties tussen de entiteiten vast. Dit leidt uiteindelijk tot een bedrijfsbreed overkoepelend gegevensmodel. Mogelijke relaties zijn: 1. 1:1, waarbij de ene entiteit precies eenmaal verbonden is met een andere entiteit (bijvoorbeeld één persoon heeft één woonadres) 2. 1:n, waarbij een entiteit verbonden kan zijn met 0 tot meerdere andere entiteiten (bijv. een persoon heeft 0 tot meerdere banen) 3. n:m, waarbij meerdere entiteiten verbonden zijn met meerdere andere entiteiten (bijv. een werknemer heeft 0 tot meerdere werkgevers, maar een werkgever heeft ook 0 tot meerdere werknemers) Beschrijven van zwakke en sterke entiteiten. Ter herhaling de definities: Een sterke entiteit is een entiteit die op zichzelf kan bestaan, bijv. docent of klaslokaal. Een zwakke entiteit bestaat slechts met een referentie; bijv. een les (die refereert aan docent en klaslokaal). 3. Bijwerken fysiek gegevensmodel Het bijwerken van het fysiek gegevensmodel is werk van DBA-ers. Vanuit functionele optiek gezien wordt hier alleen de uitvoering daarvan, voor zover mogelijk, gecontroleerd. Indien de mogelijkheid in het systeem bestaat om aan de functionele kant extra velden / tabellen te definiëren, dan is het natuurlijk mogelijk om ook de daadwerkelijke wijzigingen in de database(s) zelf uit te voeren. Andere zaken waar ook vanuit functioneel oogpunt aandacht voor kan zijn is de wijze waarop integriteit technisch wordt gewaarborgd en mogelijkheden tot optimalisatie. Met name bepaalde wijze van gegevensopvragingen (m.n. queries) kan ertoe leiden dat het logisch gegevensmodel in fysieke zin wordt aangepast, bijvoorbeeld door indexering, views of redundancy. Gegevensmodellering en de manier waarop de gegevens functioneel worden gebruikt staan niet geheel los van elkaar en dat komt met name bij het ontwerp van het fysieke gegevensmodel ter sprake. V Pagina 14-9

10 3. ACTIVITEIT: BIJWERKEN CONSTRAINTS Het bijwerken van constraints omvat het formeel vastleggen van de beperkingen, condities en regels. Deze kunnen worden afgeleid uit het onderdeel Regels / restricties in het taakgebied Requirements management. Er zijn verschillende vormen van constraints te onderscheiden: 1. De preconditie: Een constraint waaraan moet zijn voldaan voor een operatie wordt uitgevoerd 2. De postconditie: Een constraint waaraan moet zijn voldaan direct na uitvoering van een operatie 3. Een invariant: Een constraint die altijd waar moet zijn voor alle betreffende entiteiten (instanties van een klasse) 4. Een guard: Een constraint op een toestandsovergang Een uit UML afkomstige wijze om constraints te beschrijven is OCL: Object Constraint Language. Deze geeft de mogelijkheid alle constraints eenduidig vast te leggen. Elke constraint is verbonden met een object. Voorbeeld: klasse bestelling Bij een bestelling willen we vastleggen dat er een tafelnummer moet zijn ingevuld. Dat is dan een invariant, die als volgt kan worden uitgewerkt: Context bestelling inv: tafelnummer > 0 Hierbij is de klasse bestelling de naam van het contextobject, vandaar het woord Context. Op het moment dat de constraints niet (allemaal) op een dergelijke wijze eenduidig zijn vast te leggen, dient er in het taakgebied Requirements management verduidelijking te worden verkregen. Doorgaans is er sprake van een iteratieve werkwijze tussen de taakgebieden Ontwerp en Requirements management. Constraints kunnen betrekking hebben op: - De individuele attributen (eigenschappen) van de klassen: bijv. eisen aan waarden en limieten - Relaties tussen attributen: indien de ene aan een bepaalde eis voldoet, dan geldt ook iets voor het andere attribuut (bijv. wederzijdse uitsluiting, de ene moet een hogere waarde hebben dan de ander) Naast condities zijn er ook andere zaken in OCL vast te leggen, zoals bijvoorbeeld initiële waarden van attributen en afleidingsregels. Een voorbeeld van de laatste is bijv. een vlucht van een vliegtuig: de vluchtduur is af te leiden uit de vertrek- en aankomsttijd. Voor een verdere beschrijving van alle mogelijkheden van OCL wordt verwezen naar de documentatie op dit gebied. 4. ACTIVITEIT: BIJWERKEN SEQUENTIE- EN COMMUNICATIEDIAGRAMMEN V Pagina 14-10

11 De requirements worden hier verder uitgewerkt in met name sequentiediagrammen. Daarin worden gedetailleerd en in de tijd opeenvolgend de interacties tussen de verschillende actoren beschreven. Een voorbeeld hiervan is: Een sequentiediagram geeft een grafische weergave van de volgorde van gebeurtenissen, de tijd loopt in het schema van boven naar beneden. Doorgaans kan een diagram ter verduidelijking van het verloop van de gebeurtenissen als ondersteuning worden gebruikt. Communicatiediagrammen leggen de nadruk op de communicatie tussen de verschillende objecten van een systeem. In communicatiediagrammen is in plaats van de tijdsvolgorde meer te benadrukken welke verbanden er bestaan tussen de verschillende objecten. Communicatie hoeft in de tijd ook niet lineair te verlopen, en dat is in dit soort diagrammen dan wat eenvoudiger vorm te geven. In de praktijk worden sequentiediagrammen veel meer gebruikt dan communicatiediagrammen. Het is over het algemeen een overkill om beide uit te werken, en daarom zijn sequentiediagrammen de meest voorkomende. Controleer tot slot de dekking: zijn alle in de diagrammen genoemde activiteiten terug te vinden in de beschreven requirements? 5. ACTIVITEIT: BIJWERKEN TOESTANDSDIAGRAMMEN Het kan nuttig zijn voor objecten, of voor deelsystemen of zelfs voor een systeem als geheel, toestandsdiagrammen te maken. Zoals de naam al aangeeft, worden in een toestandsdiagram alle mogelijke toestanden van een object, een deelsysteem of systeem beschreven. Het ligt aan de methode op welk niveau toestandsdiagrammen worden beschreven; wordt een methode als RUP gebruikt, met daarbinnen als notatiewijze UML, dan worden alleen toestanden van objecten van één klasse per keer beschreven. Zeker in real-time systemen kan het zinvol zijn ook op deelsysteem- en systeemniveau toestandsdiagrammen te maken. Een voorbeeld van een eenvoudig toestandsdiagram van een bestelling op een terras: V Pagina 14-11

12 Behalve de toestanden waarin iets zich kan bevinden moeten hier ook de transities (toestandsovergangen) worden beschreven. Een transitie zorgt voor overgang van de ene naar de andere toestand. Vervolgens zijn de begin- en eindtoestand nog twee bijzondere toestanden die zijn te onderkennen. 6. ACTIVITEIT: BIJWERKEN BESCHRIJVING INTERFACING MET OMGEVING In deze activiteit staat het bijwerken van de beschrijving van de vorm waarop het systeem interacteert met de omgeving centraal. Hierbij kan worden gedacht aan menuschermen, printwerk, koppeling met randapparatuur en aansturing van apparaten. Dit gedeelte omvat dus niet alleen wat wel Human Computer interaction wordt genoemd, dus de interface tussen computertechnologie en de mens. Ook interfaces met andere apparaten worden hier beschreven. Dit laatste wordt overigens steeds interessanter en omvangrijker: computertechnologie wordt steeds meer direct aangesloten op andere apparaten om iets in deze wereld te meten, te besturen, te beïnvloeden en wat al niet meer. Voorbeelden hiervan zijn meet- en regelsystemen en end-to-end geautomatiseerde systemen. Aldus zijn interfaces te verdelen in: 1. mens <> computer <> mens (bij in- en uitvoer is een mens betrokken) 2. mens <> computer <> machine (bij invoer is mens betrokken, bij uitvoer een machine, bijv. een apparaat dat verf mengt) 3. machine <> computer <> machine (bijv. sensor, waarbij metingen in computer worden geregistreerd, waarop een machine anders gaat functioneren. Bijv. luchtbehandeling in gebouw afhankelijk van gebruik van de ruimten) V Pagina 14-12

13 De beschrijving van de interfaces geeft meteen de begrenzing van het systeem ten opzichte van de omgeving aan. Bij een juiste beschrijving van alle interfaces kan de interne werking van het systeem voor die omgeving verder verborgen worden gehouden (black box benadering). Hoewel in de praktijk een echte black box benadering meestal niet voor 100% haalbaar is, is een goede beschrijving van alle interfaces wel een belangrijk ingrediënt. 7. ACTIVITEIT: BIJWERKEN NIET-FUNCTIONELE SYSTEEMEISEN Aan systemen moeten naast functionele, ook niet-functionele eisen worden gesteld. Deze worden hier benoemd. In het algemeen worden op bedrijfsniveau globale eisen vastgesteld en vastgelegd. Indien dat het geval is, hoeven hier alleen maar de systeem-specifieke eisen die afwijken van de globale eisen te worden beschreven. Schematisch weergegeven ziet de opbouw er dan als volgt uit: De niet-functionele systeemeisen vallen uiteen in: 1. Beschikbaarheidseisen Een systeem moet een bepaalde beschikbaarheid binnen bepaalde openingstijden hebben. Steeds vaker zijn de openingstijden 24/7. Echter, vanwege onderhoud en storingen is binnen de openingstijden een beschikbaarheid van 100% onhaalbaar. Het is zeker wel mogelijk de 100% te benaderen. Maar hoe hoger het beschikbaarheidspercentage, hoe hoger de kosten en hoe groter de consequenties. Bijvoorbeeld is een hoog beschikbaarheidspercentage alleen haalbaar als het testen zeer grondig en uitgebreid wordt uitgevoerd en de werkelijke inproductiename zeer zorgvuldig wordt voorbereid. Met andere woorden; een hoog beschikbaarheidspercentage kan ten koste gaan van bijvoorbeeld de snelheid van aanpassing en flexibiliteit van een systeem. Hier dient dus een bedrijfsmatige afweging te worden gemaakt, waarbij vanuit de infrasupport, applicatie support en leveranciers de mogelijkheden, consequenties en kosten op technisch gebied kunnen worden aangereikt. Aan de andere kant zijn in de gebruikersorganisatie de opbrengsten te calculeren in vorm van minder productieverlies, minder kans op klantverlies (denk bijv. aan een webshop), hoger werkgenot en meer vertrouwen in de technologie. 2. Performance eisen Performance ligt in het verlengde van beschikbaarheid, omdat bij een te lage performance het systeem feitelijk niet bruikbaar (beschikbaar) is. Er dient gespecificeerd te zijn welke responsetijden gemiddeld en bij piekbelastingen moeten worden gehaald. Ook moet worden gespecificeerd hoe het systeem is ontworpen om met piekbelastingen om te gaan. Bij piekbelastingen kan bijvoorbeeld worden gekozen voor limitering aantal gebruikers (Boodschap op scherm: Het is erg druk, probeert u het later nog eens ). Dit wordt vooral gedaan in het geval het aantal gebruikers moeilijk voorspelbaar is, bijvoorbeeld op internet. Ook kan een bepaalde traagheid (slechte responsetijden) in bepaalde perioden worden V Pagina 14-13

14 geaccepteerd, maar dan moet dat worden gespecificeerd. 3. Capaciteitseisen De benodigde hoeveelheid (systeem)capaciteit moet worden berekend en hier vanzelfsprekend vanuit gebruikersperspectief. Voorkomen moet worden dat hier gedacht gaat worden in termen als giga- en terabytes. In plaats daarvan is het bedrijfsproces en de wijzigingen daarin, het uitgangspunt. Door te kijken naar het aantal gebruikers, het aantal simultane gebruikers, het aantal transacties per tijdsperiode en de gemiddelde load die een transactie op het systeem veroorzaakt, is aan de infrasupport en applicatiesupport cq. leverancierszijde te berekenen welke technische middelen nodig zijn. Ook moet worden meegerekend dat bepaalde gegevens langere tijd bewaard moeten blijven. Aldus is goed te berekenen hoeveel gegevens initieel in een systeem aanwezig zullen zijn, hoe het verloop is in een opbouwperiode en hoe een en ander zich uiteindelijk stabiliseert. 4. Continuïteitseisen Continuïteit ligt in het verlengde van beschikbaarheid, maar wordt in het algemeen gezien als continuïteit na een grootschalige verstoring. Bij grootschalige verstoringen, waarbij de gehele of een groot deel van de gebruikersorganisatie niet kan werken (met geen enkel systeem of er is een bedrijfskritisch systeem uitgevallen), komen andere aspecten in beeld dan bij het hierboven onder het kopje beschikbaarheid genoemde. Bij continuïteitseisen wordt gedefinieerd wat de maximale downtime is per systeem en / of voor het geheel, wat de onderlinge prioriteiten zijn (welk systeem wordt als eerste weer in de lucht gebracht), de mogelijkheden tot uitwijk op andere locaties, mogelijkheden voor aanpassingen van bedrijfsprocessen (op andere manier het werk voortzetten, minimaliseren tot de kernactiviteiten, beperking aantallen gebruikers etc.) en het maximale dataverlies dat de organisatie zich kan veroorloven. Ook hier wordt een bedrijfsmatige afweging gemaakt; de kosten en gevolgen van technische en organisatorische maatregelen om continuïteit te waarborgen (calamiteiten voorkomen / gevolgen van calamiteiten beperken) moeten opwegen tegen te verwachten opbrengsten. 5. Security eisen Op het gebied van security kunnen eisen bestaan zoals bijvoorbeeld encryptie. Ook kan hier worden nagedacht over de gelaagdheid van security. In het algemeen is het niet verstandig slechts één laag van beveiliging te ontwerpen. Door security in meer lagen onder te brengen wordt het geheel veiliger. Daarnaast is ook een onderwerp in welke onderdelen beveiliging moet worden gerealiseerd. In vroeger tijd werd beveiliging in de hardwarelaag ondergebracht; er waren bijvoorbeeld tussen een intern bedrijfsnetwerk en de buitenwereld geen koppelingen. Doordat steeds meer hardware aan elkaar is verbonden is dat minder en minder een optie. Daardoor is het gros van de beveiliging tegenwoordig in de softwarelaag aangebracht. Het is ook mogelijk de beveiliging op dataniveau te implementeren. Bij het benaderen van data, op welke manier dat dan ook plaatsvindt, wordt dan eerst gecheckt of het wel een geautoriseerde aanvraag is. Security wordt op basis van de requirements en algemene security eisen in het ontwerp meegenomen en uiteindelijk in realisatie verwezenlijkt. Op deze wijze zijn alle niet-functionele systeemeisen benoemd. 8. ACTIVITEIT: BIJWERKING BESCHRIJVING ORGANISATIE INRICHTING V Pagina 14-14

15 Behalve de functionele en niet-functionele aspecten van het systeem moet er ook aandacht zijn voor de benodigde organisatorische aanpassingen. Deze organisatorische aanpassingen vallen uiteen in twee componenten: 1. Aanpassingen in de organisatie van de gebruikersorganisatie Functionele aanpassingen aan systemen, zoals hiervoor beschreven, leiden soms tot aanpassingen in de organisatie. Deze organisatorische aanpassingen worden hier uitgewerkt. Het kan dan gaan om bijvoorbeeld een andere invulling van een taak, verschuiving van taken, maar ook om het samenvoegen van meerdere afdelingen. 2. Aanpassingen in de organisatie van de beheerorganisatie Naast organisatorische consequenties voor de gebruikersorganisatie kunnen er ook consequenties zijn voor de beheerorganisatie, zowel aan de functionele als technische kant. Dat betekent concreet dat bijvoorbeeld Functioneel specialisten hier naar zichzelf en hun eigen werk moeten kijken; gaat daar iets veranderen? Ook de werkverdeling in relatie tot infrasupport en applicatie support of de afspraken en verwachtingen richting leveranciers kunnen veranderen. Het is zelfs mogelijk dat contracten met leveranciers moeten worden aangepast. In dat geval worden hier de inhoudelijke aspecten uitgewerkt en vervolgens in het taakgebied Contractmanagement de benodigde contractaanpassingen uitgevoerd. 9. ACTIVITEIT: AANPASSEN ROLBESCHRIJVING(EN) Uit de functionele en organisatorische aanpassingen is af te leiden of er op het gebied van beveiliging aanpassingen nodig zijn. Met name is dan te denken aan de aanpassing van rollen in de gebruikersorganisatie. Indien taken veranderen, of bijvoorbeeld de workflow veranderd, dan is het zeer wel mogelijk dat de rolbeschrijvingen niet meer voldoen. Het kan voorkomen, hoewel wat uitzonderlijker, dat een nieuwe rolbeschrijving moet worden gemaakt of dat een rol gaat vervallen. Uiteindelijk leiden veranderingen in rollen tot andere menustructuren en autorisaties in het systeem. Soms worden hier wijzigingen aangebracht omdat er nieuwe technologische mogelijkheden zijn ontstaan die in het betreffende bedrijfsproces gebruikt gaan worden. Vastlegging van welke rol mag wat vindt plaats in een autorisatiematrix. Daarin worden op de ene as van de matrix de rollen weergegeven en op de andere as de functionaliteiten en gegevens(groepen). Vervolgens kan worden aangegeven welke rol welke functionaliteiten mag gebruiken. Bij gegevens moet gedetailleerd worden aangegeven of gegevens mogen worden ingezien, gebruikt, gewijzigd en / of verwijderd. Ook het eigenaarschap kan bij zowel gegevens als functionaliteiten worden aangegeven. Het eigenaarschap hangt doorgaans nauw samen met de bevoegdheid functionaliteiten en / of gegevens te (laten) aanpassen. Belangrijk organisatorisch aandachtspunt is functiescheiding. Als het goed is, is functiescheiding op organisatieniveau bepaald en beschreven. Deze gedefinieerde functiescheiding moet bij wijzigingen in rollen en autorisaties uiteraard aantoonbaar in stand blijven. In het kader van functiescheiding is overigens goed om te bedenken dat daar heel verschillende uitgangspunten van zijn te vinden. Het ene bedrijf hanteert als uitgangspunt Iemand mag alleen zien / gebruiken wat nodig is voor de juiste uitvoering van het werk, terwijl andere bedrijven een tegenovergesteld uitgangspunt hanteren alles is voor iedereen beschikbaar tenzij uitdrukkelijk niet toegestaan. Bij de uitvoering van deze activiteit sluit vaak degene aan die overall verantwoordelijk is voor de gehele beveiliging van alle gebruikte systemen: de Security Officer. V Pagina 14-15

16 7. RELATIES MET ANDERE ONDERDELEN VAN MCTL Dit taakgebied kent de volgende belangrijke relaties: De belangrijkste relaties zijn die met taakgebied Requirements management en Realisatie. Eerstgenoemde zal de uitgewerkte requirements aanleveren op basis waarvan het ontwerp kan worden bijgewerkt. Vervolgens zal dit bijgewerkte ontwerp aan Realisatie worden opgeleverd. Een andere duidelijke relatie is die met taakgebied Testen omdat daar (onder andere) zal worden beoordeeld of het gerealiseerde conform ontwerp is. 8. OPMERKINGEN De volgende opmerkingen zijn te maken betreffende dit taakgebied: 1. ANDERE ONTWERPTECHNIEKEN Een voorbeeld van een andere specificatietechniek, veelal afkomstig uit de IT-hoek en daarom functioneel vaak minder bruikbaar, is: 1. SCD (Systeemcontextdiagram) Hierin wordt het systeem in het midden gezet en de systemen of domeinen waarmee directe interactie is, er omheen gepositioneerd: V Pagina 14-16

17 Deze specificatietechniek wordt in MCTL verder niet gebruikt. 2. AARD VAN GEGEVENS Veel gegevens zijn redelijk statisch in de zin dat ze betrekkelijk veel worden gebruikt, maar slechts incidenteel worden ge-update. Indien wordt gezocht naar (verdere) optimalisatie van bedrijfsprocessen en systemen kan dit zeker een rol spelen. Bijvoorbeeld kunnen veel gegevens bedrijfsbreed worden vrijgegeven voor gebruik, maar het muteren worden geconcentreerd op één plaats in één systeem. Aldus ontstaat al snel een eenvoudiger beheer van gegevenssets met tegelijkertijd een zo breed mogelijk gebruik ervan. 3. HERGEBRUIK Een belangrijk thema in het taakgebied Ontwerp is hergebruik. Met hergebruik wordt bedoeld dat de gegevensstructuur, maar ook functionaliteiten en interfaces, zo moeten zijn ontworpen dat deze op zoveel mogelijk plaatsen gebruikt en hergebruikt kunnen worden. Niet alleen zijn daarmee kosten te besparen, maar de eenduidigheid van systemen wordt ook aanmerkelijk verhoogd. Bijvoorbeeld user interfaces gaan er voor gebruikers meer hetzelfde uitzien (bijv. windows look&feel ). Vanuit functionele optiek zijn beide argumenten interessant. Nadeel van ontwerpen met hergebruik in het achterhoofd is vaak wel dat in eerste instantie de kosten hoger kunnen zijn en de complexiteit van systemen hoger wordt. Blijft een feit dat ook vanuit functioneel oogpunt hergebruik een fraai streven is. 4. MODULAIRE OPBOUW VAN SYSTEMEN Naast hergebruik is de modulaire opbouw van systemen een ander belangrijk thema binnen het taakgebied ontwerp. Een modulaire opbouw geeft de mogelijkheid onderdelen van systemen flexibel te combineren. Juist die flexibiliteit is functioneel van belang bij inzet in bedrijfsprocessen die op hun beurt weer flexibel moeten zijn. Hoewel de essentie van een modulaire opbouw vrij eenvoudig is, kan het in het taakgebied Ontwerp nog lastig zijn de juiste opdeling vast te stellen. Vragen die hierbij kunnen worden gesteld zijn: 1. Welke onderdelen hebben onderling de sterkste samenhang en horen dus in één module thuis? V Pagina 14-17

18 2. Op welk niveau willen we modules creëren? Met andere woorden, wat is de gewenste omvang van modules? Vaak wordt gedacht aan modulaire opbouw à la LEGO, maar dat is een wel erg laag niveau. Daardoor ontstaan (te)veel losse modules en uiteindelijk is hierbij het gevaar dat juist daardoor extra complexiteit wordt geïntroduceerd. Werken met iets grotere bouwblokken kan beter hanteerbare modules opleveren. 3. Worden modules samengesteld op technische gronden (platforms, programmeertalen, ) of op functionele gronden (samenhang gerelateerd aan bedrijfsprocessen en -taken)? 9. NUTTIGE WEBSITES EN BOEKEN De volgende websites zijn voor taakgebied Ontwerp (vanuit functioneel oogpunt gezien) interessant: MCTL.nl Website met alle informatie over MCTL; de achtergrond, een beschrijving van het model, video s, artikelen, etc. etc. Alle documenten, waaronder ook dit document, zijn vanaf deze website te downloaden. BiSL.nl Website met alle informatie over BiSL. BiSL is, als voorganger van MCTL, interessant vanwege de verzameling Best Practices, whitepapers en artikelen die op deze website zijn te vinden. FSM Website met alle informatie over FSM. FSM is een compacte out-of-the-box versie van BiSL. De praktische vertaling in dit model is absoluut de moeite waard. De volgende boeken zijn voor taakgebied Ontwerp (vanuit functioneel oogpunt gezien) interessant: Chonoles, M. J. & Schardt, J. A. (2003). UML 2 for dummies. New Jersey: John Wiley & Sons. Hoogendoorn, S. (2004). Pragmatisch modelleren met UML 2.0. Amsterdam: Pearson. Warmer. J. & Kleppe, A. (2011). Praktisch UML. Amsterdam: Pearson. V Pagina 14-18