A | B | C | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Spørgsmål | Bemærkninger | Læs mere | OIO EA trin | Relateret OIO EA dokument | OIO EA område | Styringsgrad | Review-vurdering af relevans for projektet | Review-vurdering af projektets opfyldelse | Projektreviewers kommentarer | |||||||||||
2 | Strategi | - er der styr på strategiunderstøttelsen? | |||||||||||||||||||
3 | Er projektets mål veldefinerede? | Bliv helt skarp på de centrale forretningsmæssige mål og succeskriterier. Prioriter mål og kritiske succesfaktorer. Er der defineret metrikker så i kan måle fremdrift og gevinstrealisering? Husk, at sker der ændringer i målene skal det kunne aflæses i projektets arbejde (sporbarhed). Lav evt. en SWOT analyse. | OIO EA Princip 1: Forretningsbehov bør drive og definere løsningerne. | A1 | A1.1 | Strategi | Anbefalet | ||||||||||||||
4 | Er der foretaget en interessentanalyse? | Som led i projektplanlægning og udarbejdelse af governance-strategi er det vigtigt at få et overblik over interessenterne, deres interesser og deres muligheder for at fremme eller svække projektets fremdrift, løsningsudvikling og gevinstrealisering. | Skabelon fra statens it-projektmodel | A5 | A5.5 | Strategi | Anbefalet | ||||||||||||||
5 | Er der indtænkt inddragelse af brugere fra starten? | Brugerne bør inddrages i forbindelse kravspecifikation og udviklingen af løsningen. Især i idé- og design- og testfaser er det vigtigt med brugerdialog til at definere konkrete behov og sikre brugervenlighed. Fx i forbindelse med funktionelle behov, use cases, brugervenlighedstest o.l.? | OIO EA Princip 2: Borgere og virksomheder bør sættes i centrum. | A2 | A2.1 | Strategi | Anbefalet | ||||||||||||||
6 | Understøtter projektet forretningsstrategien? | Vurdering af om projektet grundlæggende understøtter egne it- og forretningsstrategier samt tværoffentlige og fællesstatslige strategier. | Tværoffentlig digitaliseringsstrategi | A5 | Anbefalet | ||||||||||||||||
7 | Følges fælles overordnede principper og formuleres der specifikke principper for løsningen? | Det er vigtigt at orientere sig i de principper der skal gælde for løsningen. Principper formuleres af forskellige aktører og dækker forskellige kontekster. Start med at tjekke organisationens egne it-principperog de tværoffentlige principper. For kommunerne gælder også rammearkitekturprincipper, for regionerne principper beskrevet i Forretningsmodel for Regionernes Sundheds-it og for staten It-Projektrådets 5 principper for statslige it-projekter. | Fællesoffentlige principper | A6 | A6.1 | Strategi | Anbefalet | ||||||||||||||
8 | Forretning | - er der styr på forretningsprocesserne? | |||||||||||||||||||
9 | Er de vigtigste elementer i forretningsarkitekturen identificeret? | En generel vurdering og helt overordnet kortlægning af de elementer, der er relevante for projekter. Omfatter fx aktører / organisation / lokationer, forretningsservices / tjenester, processer / arbejdsgange samt forretningsobjekter. Alle disse elementer har betydning for it-arkitekturen og for effektiviseringsmulighederne. Det er også starten på arbejdet med informationsarkitektur. Fokusér i første omgang på at få overblik over det vigtige. Lav fx en procesevaluering. | OIO EA trin B. Forretning | B1B2 B3 B4 | B4.2 | Forretning | Anbefalet | ||||||||||||||
10 | Er der arbejdet aktivt med optimering af processer? | I forbindelse med it-anskaffelser bør der også være nye muligheder for at gøre forretningsprocesser mere effektive end før. Det gælder ikke kun omfattende og nye løsninger; detkan også være ændring i en applikation, der indgår i et eksisterende system. Nøglen til optimering og effektivisering er, at der arbejdes aktivt med forenkling af arbejdsgange, forenkling af forretningsregler, genbrug af data, smartere arbejdsdeling, øget selvbetjening og automatisering. Det er vigtigt at have fokus på forankring af ændrede processer, herunder sikring af at tværgående processer spiller sammen. Det fordrer både inddragelse, dialog og dokumentation. Hvis målet er effektivisering skal det også fremgå i målsætningen for projektet - og der bør være en as-is måling, som effektivisering kan tage udgangspunkt i. Ofte ser vi, at der ikke er sammenhæng mellem mål for effektivisering og det er kan måles. | OIO EA Princip 3: Processer bør optimeres i forbindelse med digitalisering. | B4 B6 | B4.1 | Forretning | Anbefalet | ||||||||||||||
11 | Lever processer op til krav ovenfra? | Er ledelsen inddraget ved optimering af forretningsprocesser? Findes der udefra kommende krav som fx lovgivning, der skal overholdes i forbindelse med forretningen? Selvbetjening- og medbetjeningsprocesser bør analyseres med deres samspil til myndighedsprocesser - fordi det er myndighedsprocesserne, der skal aflastes med selvbetjening - ellers giver selvbetjeningen ingen effekt. | OIO EA Princip 3: Processer bør optimeres i forbindelse med digitalisering. | B4 B6 | B4.1 | Forretning | Anbefalet | ||||||||||||||
12 | Er processer beskrevet med BPMN? | To-be arbejdsgangen skal beskrives i samspil med nye applikationer. Det er vigtigt at hele arbejdsgangen beskrives - med alle aktører (borgere og systemer). Beskrivelsesstandarden BPMN – Business Process Modeling Notation – er et ”sprog” eller en standard for at lave procestegninger / arbejdsgangsdiagrammer. BPMN bør i sær anvendes til detaljeret dokumentation på arbejdsgangs- og work flow-niveau. BPMN anvendes fx i KL's arbejdsgangsbank. | Anbefaling 1. Få styr på forretningsprocesserne. | B4 B6 | B4.1, B6.1 | Forretning | Anbefalet | ||||||||||||||
13 | Er FORM anvendt til at strukturere (opmærke) opgaverne i den del af forretningen, der berøres? | FORM giver fælles klassifikation og sprog for forvaltningsopgaver. Brug fx FORM til at opmærke * Processer / arbejdsgange / workflows * Forretningsservices / tjenester * Forretningsobjekter * Lokationer / organisation. Kommuner kan også bruge KLE til opmærkning - og FORM er mappet til KLE. | www.form-online.dk | B3 | B3.1 | Forretning | Anbefalet | ||||||||||||||
14 | Er processer lagret og gjort tilgængelige for andre organisatoriske enheder? | Processer som andre skal anvende, fx som led i tværgående processer, standardiserede processer eller blot til inspiration bør udstilles og deles. Processer kan fx udstilles via digitaliser.dk. Kommunale processer udstilles i arbejdsgangsbanken. | Om hvordan du kan bruge digitaliser.dk | B4 | B4.1, B6.1 | Forretning | Anbefalet | ||||||||||||||
15 | Information | - er der styr på forretningsobjekter, begreber og data? | |||||||||||||||||||
16 | Er de centrale begreber ("forretningsobjekter") identificeret og definerede? | Er de centrale objekter mappet til de forretningstjenester/-services og processer, hvor de anvendes, og evt. til de applikationer hvor de lagres og behandles? Respekteres forretningsobjekter fra fremmede forretningstjenester/services? Er der anvendt UML til modellering? | OIO EA Princip 4: Data og services bør genbruges. | B1 | B1.1 | Information | Anbefalet | ||||||||||||||
17 | Anvendes data optimalt? | Genbruges eksisterende data optimalt? Fx ved at trække data fra andre systemer eller ved at løsningen tilbyder data til andre systemer. Hvis man skal bruge data fra en 'fremmed'' forretningstjeneste er de kun til låns. De må ikke opdateres - men skal opdateres i den pågældende tjeneste. Det er det samme princip, som gælder for grunddata. Er der i planlægningen af løsningen taget hensyn til at løsningens data i et eller andet omfang kan bruges til ledelsesinformation og Business Intelligence. | OIO EA Princip 4: Data og services bør genbruges. | B1 | B1.1 | Information | Anbefalet | ||||||||||||||
18 | Er data der skal udveksles med andre myndigheder i OIOXML format? | Snitflader bør beskrives efter reglerne i OIOXML og registreres i XML-Kataloget på Digitaliser.dk. Hvor det er relevant bør de defineres som standarder i samarbejde med relevante nøgleinteressenter i domænet. Bemærk undtagelsesbestemmelser. | OIO EA Anbefaling 5. Dataudveksling bør anvende fælles datastandarder. | C1 | C1.4 | Information | Obligatorisk (følg eller forklar) jf. aftale mellem staten, KL og Danske Regioner om anvendelse af åbne standarder for software i det offentlige | ||||||||||||||
19 | Stilles offentlige data til rådighed for offentligheden? | Data bør så vidt muligt stilles til rådighed for offentligheden, hvor det ikke strider mod gældende regler eller giver unødige meromkostninger. Tilgængelige bør registreres i Datakataloget på Digitaliser.dk. | Datakataloget på Digitaliser.dk | C1 | Information | Anbefalet | |||||||||||||||
20 | Leveres specialudviklede løsninger med en dokumentation af den underliggende datamodel? | Formålet med en dokumenteret logisk datamodel er, sammen med anden systemdokumentation, at sikre leverandøruafhængighed. | OIO EA Trin C1. Informationsarkitektur | C1 | C1.1 | Information | Anbefalet | ||||||||||||||
21 | Applikation | - er der styr på software, brugergrænsefalde og services? | |||||||||||||||||||
22 | Er der der er overblik over det nuværende applikationslandskab (herunder integrationer og andre afhængigheder)? | Lav fx et applikationskatalog, der giver en oversigt over funktionalitet, teknologi-platform, brugere, integrationer, mv. for de enkelte applikationer. Start med at lave en liste over de vigtigste løsninger og de applikationer/komponenter der indgår heri. | OIO EA Trin C2. Applikationsarkitektur | C2 | C2.1 | Applikation | Anbefalet | ||||||||||||||
23 | Er der der applikationsporteføljen opmærket med FORM og STORM? | Er applikationerne mærket op med den fællesoffentlige klassifikationssystematik for it-løsninger - STORM?. Lav evt. en model-tegning, der giver et visuelt overblik og applikationerne og de overordnede sammenhænge - fx mellem applikationer eller relationer til procesunderstøttelse eller hvilke informationer, der behandles. | Om de fællesoffentlige systematikker FORM og STORM | C2 | C2.1 | Applikation | Anbefalet | ||||||||||||||
24 | Er der defineret eller anvendt en prædefineret referencearkitektur? | Har I fx taget bestik af relevante referencearkitekturer, fx vedr. Sag og Dokument, Stedbestemt Information eller Brugerstyring? Vær også opmærksom på KL's rammearkitektur og referencearkitektur for sundheds-it. | Om danske referencearkitekturer på Arkitekturguiden | C2 | C2.1 | Applikation | Anbefalet | ||||||||||||||
25 | Er der brugt standardprodukter? | Minimer ændringer og tilpas så vidt muligt forretningsbehovene fremfor at lave specialtilpasinger af standardsoftware! | OIO EA princip Princip 8: Udnyt mulighederne ved anskaffelser. | C2 | C2.1 | Applikation | Anbefalet | ||||||||||||||
26 | Genbruges allerede indkøbte eller udviklede løsninger i videst muligt omfang? | Har i undersøgt om eksisterende løsninger/komponenter kan dækkes behovet? Se organisationens eget applikationskatalog | Professionalisering af arbejdet med it-projekter i staten - Afrapportering fra arbejdsgruppen vedrørende bedre statslige it-projekter. | C2 | C2.1 | Applikation | Anbefalet | ||||||||||||||
27 | Findes der en Open Source løsning, helt eller delvist, på dette område? | Tjek også om der er findes komponenter udviklet af andre myndigheder, fx på Softwarekataloget på digitaliser.dk. Arbejder du selv med et open sourceprojekt kan du oprette en gruppe på Softwarebørsen på digitaliser.dk | Softwarekataloget på digitaliser.dk | C2 | C2.1 | Applikation | Frivillig | ||||||||||||||
28 | Anvendes relevante fællesoffentlige løsninger? | Bliver der gjort brug af NemID, NemLogin, NemSMS, Digital post, NemKonto, OPIS, CIDR, Viskort, NemHandel mv., | Fællesoffentlige løsninger og infrastruktur | C3 | C3.1 | Applikation | Anbefalet. En række løsninger er obligatoriske i forskellige kontekster. | ||||||||||||||
29 | Giver løsningen den fornødne fleksibilitet? | Er løsningen fx løst koblet ved hjælp af moduler / komponenter / lagdelt arkitektur og veldefinerede, åbne snitflader? Er services fleksible? Dvs. at brugergrænseflader er udskiftelige, adskilt fra resten af it-løsningen og at services kan afvikles i flere løsninger. Kan løsningen tilpasses og skaleres i forhold til ændrede behov i forrretningen / forvaltningen? | OIO EA Princip 6: Basér løsninger på løst koblede komponenter | C3 | C2.6, C3.1 | Applikation | Anbefalet | ||||||||||||||
30 | Kan løsningen tale med andre relevante interne og eksterne systemer? | Er relevante integrationer kortlagt (listet op)? Er relevante services etableret, dokumenteret, publiceret og kommunikeret eksternt? Services der er relevante for andre myndigheder bør beskrives (herunder med forretningsorienterede SLAer) og gøres tilgængelige. | OIO EA Anbefaling 8. It-systemer bør kunne tale sammen. | C2 | C2.5, C3.1 | Applikation | Anbefalet | ||||||||||||||
31 | Er relevante selvbetjeningsløsninger og indhold gjort tilgængeligt for tværoffentlige portaler? | Her tænkes særligt på borger.dk og virk.dk. Bemærk særlig de obligatoriske selvbetjeningsløsninger i bølge 1 og 2. | OIO EA best practice Anbefaling 6. Lad offentlige portaler genbruge dit indhold. | C3 | C3.1 | Applikation | Anbefalet. Der er dog lavet aftale om obligatoriske områder. | ||||||||||||||
32 | Er der taget højde for relevante krav til funktionalitet og brugervenlighed? | Er der anvendt dialog, værktøjer og tests i relation til brugerne? Det kan fx være use cases, personas, fokusgruppe, interviews, onlinepanel, participatory design, tænk-højt-test, brugsstatistik, eye-tracking, heatmapping. NB. Der vil i løbet af 2012 komme et sæt forpligtende retningslinjer for selvbetjeningsløsninger i regi af initiativ 1.5 i digitaliseringstrategien 2011-2015. | OIO EA Trin B5. Use cases | B5 | B5.1 | Applikation | Anbefalet. Der kommer obligatoriske krav i løbet af 2012. | ||||||||||||||
33 | Er der taget højde for krav til tilgængelighed? | Hjemmesider og selvbetjeningsløsninger skal overholde standaden WCAG 2.0 AA DPF/A-1a | Retningslinjer, standarder, værktøjer og analyser om tilgængelighed | C2 | Applikation | Obligatorisk (følg eller forklar) | |||||||||||||||
34 | Teknologi | - er der styr på infrastruktur og standarder? | |||||||||||||||||||
35 | Er der foretaget en afvejning af valget mellem modne og umodne tekniske løsninger? | Fx skal staten være ambitiøs i forhold til digitalisering af den offentlige sektor, men skal kun gå forrest i anvendelsen af umodne tekniske løsninger, såfremt der er særlige perspektiver ved at foretage en sådan satsning. Jf I rapporten "Professionalisering af arbejdet med it-projekter i staten - Afrapportering fra arbejdsgruppen vedrørende bedre statslige it-projekter". | Professionalisering af arbejdet med it-projekter i staten - Afrapportering fra arbejdsgruppen vedrørende bedre statslige it-projekter | C4 | C4.1 | Teknologi | Anbefalet | ||||||||||||||
36 | Er infrastrukturen baseret på open source? | Findes der en Open Source løsning, helt eller delvist, på dette område? | Om softwarestrategi, Softwarebørsen og open source. | C4 | C4.3 | Teknologi | Frivillig | ||||||||||||||
37 | Stilles der krav om åbne standarder eller åbne API'er? | Åbne standarder fremmer interoperabilitet og konkurrence. Dermed kan myndighedernes bedre sikres leverandøruafhængighed. Anvendelsen af åbne standarder giver bedre og billigere muligheder for udveksling og genbrug af data og for at effektivere arbejdsprocesser og kvalitetsudvikle den offentlige service. Åbne standarder understøtter tillige, at borgere og virksomheder har et friere valg af software og af leverandører. | OIO EA best practice Anbefaling 12. Stil krav om åbne standarder. | C4 | C4.1 | Teknologi | Obligatorisk (følg eller forklar) | ||||||||||||||
38 | Er infrastrukturen fleksibel og skalerbar? | Er der taget højde for skalerbarhed ved et stigende brug og spidsbelastninger? Findes der et alternativt driftsmiljø til den valgte løsning? Kan løsningen fx køre på virtuelle servere / Cloud+ | Princip 7: Løsninger bør være fleksible. | C4 | C4.3 | Teknologi | Anbefalet | ||||||||||||||
39 | Styringsrammer | - er der styr på projektgrundlag, governance og drift? | |||||||||||||||||||
40 | Er de vigtigste EA-udfordringer i relation til projektet identificeret? | Identificer de væsentligste udfordringer som organisationen står overfor, og som er tværgående og dermed omfattet af en enterprise arkitektur. ”En udfordring” kan være et problem der skal løses, eller en mulighed man ønsker at udnytte. Trinet afstikker nogle klare retningslinier for hvad arkitekturen overordnet skal adressere; arkitekturens succeskriterier om man vil. Er det fx interoperabilitet eller konsolidering der er målet, så giver det typisk helt forskellige udfordringer. Tilsvarende er der stor forskel på velafgrænsede interne løsninger vs. løsninger der skal hænge sammen med en større omverden. Er der behov for at definere fælles standarder stiller det krav til proces og governance i forhold til de berørte interessenter. | Om (EA)udfordringer | A1 | A1.1 | Styringsrammer | Anbefalet | ||||||||||||||
41 | Er der formuleret en Business case? | Hvilken forretningsmæssig værdi tilfører projektet med forandringen? Kun projekter med klart beskrevne omkostninger, gevinster og effekter bør gennemføres. En business case bør klart understøtte det konkrete løsningsvalg (sporbarhed). | Skabelon fra statens it-projektmodel | A4 | A4.2 | Styringsrammer | Obligatorisk (følg eller forklar) for statslige og fællesoffentlige projekter over 10 mio. kr. | ||||||||||||||
42 | Er projektet optimeret i størrelse og scope, så risici minimeres? | Store, komplekse projekter bør opdeles i mindre og selvstændige værdiskabende dele, som besluttes og gennemføres uafhængigt af hinanden. Opdelingen bør ske så man optimerer mulighederne for at høste gevinster. Den største udfordring er, at de fleste projekter ønsker kontrol - og derfor udvider de scope. Projektet skal have opbakning til at afgrænse og måles på dette. Dette er typisk årsagen til manglende genbrug. | Professionalisering af arbejdet med it-projekter i staten - Afrapportering fra arbejdsgruppen vedrørende bedre statslige it-projekter | A4 | D1.2 | Styringsrammer | Anbefalet | ||||||||||||||
43 | Er det undersøgt om projektet kan drage erfaringer fra tilsvarende projekter? | Inden i kommer for godt i gang er det en god idé at tjekke om andre projekter har erfaringer og resultater i kan trække på i egen organisation eller en anden organisation. Spørg fx via netværksfora som KL's it-arkitekturnetværk eller via KL/KOMBIT, RSI/NSI eller Ministeriernes ProjektKontor (MPK) og Kontor for Arkitektur og Standardisering (KIS) i Digitaliseringsstyrelsen. Brug eventuelt digitaliser.dk som videndelingsplatform. | OIO EA Anbefaling 15. Del viden og samarbejd på tværs. | A2 | A2.1 | Styringsrammer | Anbefalet | ||||||||||||||
44 | Har projektet taget stilling til dokumentation af den tekniske løsning? | Udover formelle krav til projektdokumentation er det vigtigt at tage stilling til den arkitekturfaglige dokumentation, der er nødvendig for at understøtte formål som effektivisering, sammenhæng og genbrug. Jf OIO EA metoden. I Statens It-projektmodel anbefales der konkrete dokumenter i PID-vejledningen. | OIO EA Trin A3. EA metodegrundlag | A3 | A3.1 | Styringsrammer | Anbefalet | ||||||||||||||
45 | Anvendes fællesoffentlige metoder? | Tag stilling til brug af * Projektmetode (fx Statens projektmodel, Prince2) * Udviklingsmetode (fx vandfald eller agile (SCRUM, DSDM-Atern eller andre) * Rammeværk (fx OIO EA, FORM, STORM) * Dokumentationsmetoder (fx BPMN, UML, Archimate). | OIO EA Trin A3. EA metodegrundlag | A3 | A3.1 | Styringsrammer | Anbefalet Statens projektmodel er obligatorisk for stalsige projekter over 10 mio. kr. FORM er obligatorisk i visse sammenhænge, fx i forbindelse med aflevering til Statens Arkiver. | ||||||||||||||
46 | Er der relevante kompetencer til stede i projektet på tilstrækkeligt niveau | Projekter bør så vidt muligt gennemføres med fælles metoder og kvalificerede ressourcer, således at der i alle projekter er et passende modenhedsniveau. | Professionalisering af arbejdet med it-projekter i staten - Afrapportering fra arbejdsgruppen vedrørende bedre statslige it-projekter | A4 | A4.1 | Styringsrammer | Anbefalet | ||||||||||||||
47 | Er der styr på governance og kvalitetssikring? | Er der udpeget ejerskab, fx forretningstjenesteejer, procesejer, dataejer og systemejer? Er der indgået vedligeholdelsesaftale mht. kode? Er der lavet kodereview med henblik på om koden er nem at vedligeholde - dvs. overskuelig, moduleret og veldokumenteret, så det er nemt at finde fejl, rette og videreudvikle? Hvordan sikrer I, at jeres valg af it-arkitektur, standarder og løsninger er optimeret i forhold til organisationens egne behov og de fælles interesser? Støttes løsningen af et organisatorisk / styringsmæssigt set-up? Har løsningen været behandlet / reviewet i et tværoffentligt forum, i Statens IT-Projektråd eller kommunernes It-arkitekturråd? | OIO EA Princip 1: Forretningsbehov bør drive og definere løsningerne. | Y3 | Y3.1 | Styringsrammer | Anbefalet | ||||||||||||||
48 | Er der styr på sikkerhed, privacy og risici? | Er sikkerheden veldokumenteret? Er der fx lavet risikoanalyse/-vurdering, Privacy Impact Assesment og kodereview med henblik på sikkerhed? Er sikkerhedsstanderne ISO 27001 og DS 484 Standard for informationssikkerhed overholdt? | OIO EA Princip 9: Informationssikkerhed fra start til slut. | D1 /generelt | D1.2 | Styringsrammer | Anbefalet. DS 484 er obligatorisk i staten. | Y | |||||||||||||
49 | Er der styr på drift? | Er krav til driftsmiljøet veldefineret? Er driftsleverandøren, fx Statens-IT, inddraget? Er dokumentation til driftsløsningen på plads? Fx installations og driftvejledning til SIT. | OIO EA Trin Y1. Driftssituation | Y1 | Y1.1 | Styringsrammer | Anbefalet | ||||||||||||||
50 | Er der taget ejerskab til kildekode? | Er der taget ejerskab af kildekode til specialudviklede løsninger? Vælg fx en Creative Commons licensform. Understøtter i aktivt genbrug af (dele af) løsningen? Gøres koden til specialudviklet software tilgængelig som open source og publiceres på Softwarebørsen? Er der sørget for den fornødne dokumentation? | OIO EA best practice Anbefaling 3. Udgiv egenudviklet software under open source-licens. | Y5 | Y5.1 | Styringsrammer | Anbefalet | ||||||||||||||
51 | Deler projektet viden? | Udstilles og deles relevant dokumentation, viden og erfaringer fra projektet via digitaliser.dk? | OIO EA best practice Anbefaling 15. Del viden og samarbejd på tværs. | Y3 | Y3.1 | Styringsrammer | Anbefalet | ||||||||||||||
52 | |||||||||||||||||||||
53 | |||||||||||||||||||||
54 | |||||||||||||||||||||
55 | |||||||||||||||||||||
56 | |||||||||||||||||||||
57 | |||||||||||||||||||||
58 | |||||||||||||||||||||
59 | |||||||||||||||||||||
60 | |||||||||||||||||||||
61 | |||||||||||||||||||||
62 | |||||||||||||||||||||
63 | |||||||||||||||||||||
64 | |||||||||||||||||||||
65 | |||||||||||||||||||||
66 | |||||||||||||||||||||
67 | |||||||||||||||||||||
68 | |||||||||||||||||||||
69 | |||||||||||||||||||||
70 | |||||||||||||||||||||
71 | |||||||||||||||||||||
72 | |||||||||||||||||||||
73 | |||||||||||||||||||||
74 | |||||||||||||||||||||
75 | |||||||||||||||||||||
76 | |||||||||||||||||||||
77 | |||||||||||||||||||||
78 | |||||||||||||||||||||
79 | |||||||||||||||||||||
80 | |||||||||||||||||||||
81 | |||||||||||||||||||||
82 | |||||||||||||||||||||
83 | |||||||||||||||||||||
84 | |||||||||||||||||||||
85 | |||||||||||||||||||||
86 | |||||||||||||||||||||
87 | |||||||||||||||||||||
88 | |||||||||||||||||||||
89 | |||||||||||||||||||||
90 | |||||||||||||||||||||
91 | |||||||||||||||||||||
92 | |||||||||||||||||||||
93 | |||||||||||||||||||||
94 | |||||||||||||||||||||
95 | |||||||||||||||||||||
96 | |||||||||||||||||||||
97 | |||||||||||||||||||||
98 | |||||||||||||||||||||
99 | |||||||||||||||||||||
100 |