Notater til Softwaredesign. Vidar Jon Bauge Datamatikeruddannelsen forår/efterår 2006 Side 1 av 73

Størrelse: px
Starte visningen fra side:

Download "Notater til Softwaredesign. Vidar Jon Bauge 2006. Datamatikeruddannelsen forår/efterår 2006 Side 1 av 73"

Transkript

1 Notater til Softwaredesign 2006 Datamatikeruddannelsen forår/efterår 2006 Side 1 av 73

2 Indholdsfortegnelse Testing Måling af kvalitetsattributter ved testning Roller Testaktiviteter Typer af tests Test planlægning og design Implementering af tests Test kørsel Test case Testplan Risiko vurdering... 9 Fejl og evalueringsrapporter Artefakter til vurdering af testaktiviteten Trend rapporter Defect density report Evaluering af testaktivitetene Kategorisering af fejl Hvordan gennemføre en heuristisk evaluering Projekters livscyklus og modeller Vandfaldsmodellen b-modellen V-modellen Den inkrementelle model Spiralmodellen Metodologier Begrundelse for at anvende metodologier Metodesammenligning Attributter ved vurdering af metodologier: Normative Information Model-based Systems Analysis and Design (NIMSAD)...21 Andre metoder til sammenligning Rammeværk til sammeligning af metodologier Agile processer Agile processer Hvad er en agil proces? Debatten om den agile proces Menneskelige faktorer Agile procesmodeller extreme Programming XP Adaptive Software Development (ASD)...27 Dynamisk System Development Method (DSDM)...28 Scrum Crystal Feature Driven Development (FDD)...28 Agile Modeling Hvad er systemudvikling? Computer teknologi i organisationer Datamatikeruddannelsen forår/efterår 2006 Side 2 av 73

3 Ydelse og ledelse Komponenter i systemudviklingsmetoder Performance Principper i performance Management Principper i management Management og performance Beslutningstagning, kommunikation og socialisering Indfaldsvinkler til systemudvikling Teori, metode og praksis Karakteristika ved systemudviklingsmetoder Forholdet mellem metode, funktioner og processen Agil projekt management Agilitet Hvad er agil management? Principper i agil projektmanagement Agil praksis Organiske teams: Opret kontakt og tilpasning gennem tætte forbindelser i små fleksible teams Guidet vision: Sikre at teamets medlemmer alle arbejder imod den samme vision, og ledes af en delt mental model Enkle regler: Definer et sæt enkle generative proces regler for teamet...39 Åbne informationer: Sørg for fri og åben tilgang til informationer...39 Light touch: Anvend intelligent kontrol for at fremme emergent orden og maksimal værdi..39 Adaptiv ledelse: Led projektet gennem konstant monitorering, læring og tilpasning...39 Arkitektonisk design Beslutninger omkring system arkitektur Systemets organisering Repositorie modellen Klient-server modellen Den lagdelte model Opdeling i moduler Objekt orienteret opdeling Funktions orienteret pipelining (dataflow model) Kontrol metoder Centraliseret kontrol Hændelses drevne systemer Reference arkitekturer Distribuerede system arkitekturer Multiprocessor arkitekturer Distribuerede arkitekturer Klient-server arkitektur To-tier klient-server arkitektur Tre-tier klient-server arkitektur Arkitekturer med distribuerede objekter CORBA Distribuerede netværk i organisationer Peer-to-peer netværk Web tjenester Applikations arkitekturer Datamatikeruddannelsen forår/efterår 2006 Side 3 av 73

4 Data behandlingsystemer Transaktions behandlingsystemer Informationsystemer og systemer til ressourcestyring Event behandlingsystemer Sprogbehandlingsystemer Kvalitetstyring Proces og kvalitetstyring Kvalitetsikring og standarder ISO Dokumentationstandarder Kvalitetsplanlægning Kvalitetskontrol Software måling og måleenheder Stadier i produktmåling Målinger Analyse af måleresultater Proces forbedringer Processen og produktkvalitet Klassificering af processer Proces målinger GQM Goals Questions metrics Analyse og modellering af processer Fejltilstande ved processer Proces ændringer CMMI proces framework CMMI modellen med stadier Den kontinuerlige CMMI model Datamatikeruddannelsen forår/efterår 2006 Side 4 av 73

5 Testing Tidlig testing og godt udførte tests reducerer omkostningene ved softwareudvikling. Testing skal udføres i hele systemets levetid. Ved at udvikle software af høj kvalitet, undgår problemer der kan opstå som følge af et produkt af dårlig kvalitet. Problemer som nedsat produktivitet for den enkelte bruger, fejlagtige beregninger, tab af data og uacceptabel meget fejl respons fra systemet. Fejlretning i et defekt produkt er dyrere at udbedre, sent end tidlig i et udviklingsforløb. En anden vigtig funktion ved testning, er at måle hvor langt man er kommet i udviklingsforløbet, f.eks. i en iteration, gennem at verificere om et bestemt krav eller en use case er blevet implementeret. Måling af kvalitetsattributter ved testning Attribut Hvorfor Hvordan teste Funktionalitet Gør applikationen det den skal? Testcases for hvert scenario der implementeres. Pålidelighed Er der f.eks. memory leaks Analyseværktøjer og code instrumentation. Applikationens ydelse Er applikationens responstid acceptabel? Undersøg ydelsen for hvert scenario/use case der implementeres. Systemets ydelse Er systemets ydelse tilfredsstillende under arbejdsbelastning? Roller Rolle Test ydelsen til alle use case under normal og højest tænkelig belastning. Dette kan være meget vanskelig i et system med en kompliceret arkitektur eller et system der skal køre på mange kombinationer af hardware. Tester Teste integrationen af nye moduler Integrationstest. Implementer Designer Dette er roller der bør indrages i testning. Selvom den der har implementeret et modul, ikke bør teste det, kan vedkommende godt være delagtig i planlægningen af tests. For at kunne udøve integrationstests, må testeren have et detaljeret kendskab til systemet, kravene og applikationens domæne. Forskellig personer med forskellig kompetence må derfor samarbejde om udførelsen af integrationstests. For at kunne udøve pakke tests, må testeren have er detaljeret kendskab til algoritmer, klassedefinitioner og data strukturer. Datamatikeruddannelsen forår/efterår 2006 Side 5 av 73

6 Testaktiviteter Testdisciplinen består af mange aktiviteter, og kan løber i hele produktets levetid. Testdisciplinen omfatter både testing, implementering og kørsel af tests, og kan selvfølgelig modificeres for at passe til produktet. Testdisciplinen Typer af tests Debugging Anses ikke som en del af testdisciplinen, men implementeringsdisciplinen. Udføres kontinuerligt under kodning f.eks. ved at kompilere ofte. Unittesting Verificering af de mindste testbare enheder i systemet. Anvendes til at teste om dataflow og kontrol flows der er omfattet af testen fungerer tilfredsstillende. Integrationstesting Kontrollerer at enhedene fungerer samlet, når de kombineres til implementeringen af f.eks. en use case. Systemtesting Starter når hele, eller hele subset af systemet er implementeret. Målet er at teste hele systemet som en helhed. Acceptancetesting Omfatter et sæt af tests både kunde og udviklere er enige om. Acceptance tests er et subsystem til alle test cases. De er et grundlag for at vurdere om systemet er klart til levering. Målet er at teste om systemet lever op til kundens krav, og dermed er klart for levering. Alfa og Beta testing Alfa og beta testing tester om systemet lever op til de forventninger og krav der er stillet til systemet som helhed. De udføres af udviklere i samarbejde med kunden, men Alfa testing udføres i udviklingsmiljøet og beta testing udføres ude hos kunden. Datamatikeruddannelsen forår/efterår 2006 Side 6 av 73

7 Niveau Mål Aktivitet der testes Debugging Kildekode Programmørens håndværk. Unittesting Designet produktenheder. Implementering af enheder. Integrationstesting Arkitektoniske produktenheder. Implementering af produktet. System Produktets miljø. Implementering af produktet. Acceptancetesting Produktets funktionalitet. Opfylder produktet kundens krav. Alfa og Beta testing Produktets anvendelighed. Produktets anvendelighed hos slutbrugeren. Test planlægning og design Formål At identificere de krav der skal testes, indikere omfanget af testingen og fastslå hvor mange ressourcer der er nødvendig til udførelsen af testaktivitetene. Kravene der skal testes hentes fra kravene til systemene, use cases, use case modellen, use case realiseringene supplementerende specifikationer, krav til design, interviews med brugere og evalueringer af eksisterende systemer. De ressourcer der anvendes til testing, må balanceres imod det man kan opnå ved at teste. Her skal man tage i betragtning de risici der er identificeret. De krav der er udgangspunkt for testing, må prioriteres, så man kan maksimere testenes effektivitet med et minimalt ressourceforbrug. Når test strategien er lagt og metoderne er bestemt, må dette kommunikeres ud til alle. Test teknikker Der er 2 hovedtyper: Black-box testing Baseret på en grundlæggende forståelse for den implementerede komponent. Equivalence partitioning, boundary value testing, comparison testing, mutation testing. White-box testing Baseret på en grundlæggende forståelse for kildekoden. Path testing, condition testing, data flow testing, loop testing Testkriterier er objektive værdier der anvendes til at måle om en test er bestået eller ikke. Test Case En test case er en beskrivelse af en test der skal udføres. Den består af en liste af testkriterier, objekter, testdata, den tilstand systemet skal være i når testen begynder og det forventede resultat. Test procedurer kan enten udføres manuelt, eller de kan implementeres til automatisk kørsel. Når en test procedure er automatisk, er det kørbare testprogram et test script. Test cases sammen med test scripts udgør test modellen. Data drevne tests er afhængige af pålidelige dataset der sendes til systemet ved hjælp af test scripts. Dette indbærer at data gemmes i en ekstern fil. Dette er specielt nyttig når man ser behovet for en ny test. Nye data kan let lægges til eksisterende testdata, men i disse tilfælde skal selve testen valideres. Datamatikeruddannelsen forår/efterår 2006 Side 7 av 73

8 Implementering af tests Test implementering består af design af testklasserne og implementering af testkomponentene. Både design modellen og test modellen er nødvendig for dette. Testklasserne er stereotyper af klasser i designmodellen. Der er 3 typer testklasser: Throwaway test component der kun anvendes én gang. Script test komponenten der er automatiseret og beregnet på at blive kørt mange gange. Test kørsel For at køre tests, skal alle nødvendige komponenter være tilstede i testmiljøet. Dette gælder både hardware og software komponenter. Det er selvfølgelig vigtig at evaluere om testene har kørt som forventet og tage de nødvendige skridt hvis dette ikke er tilfældet. Regressionstest Et vigtigt element i selve testkørselen er regressionstest, hvor man kører alle tests, inklusive tidligere tests fra alle tidligere iterationer. Dette vil afsløre eventuele fejl der er opstået ved at nye komponenter er blevet implementeret. Eftersom tidligere tests bliver kørt mange gange i udviklingsforløbet, er det vigtig at testing bliver automatiseret. Regressionstesting omfatter ikke implementering af nye testcases, eftersom dets formål er at afdække fejl der kan opstå ved implementering af nye komponenter. Derfor køres regressionstesten mindst en gang i en iteration. Hver testcase der implementeres skal vurderes for om den skal inkluderes i regressionstesten. Her må man veje ressourceforbruget ved vedligeholdelsen af testcasen op imod fordelen ved at køre den i regressionstester. En testcase der skal inkluderes i regressionstesten, må være sådan designet at den ikke fejlmelder mindre ændringer i f.eks. GUI. Testene skal placeres under configuration management. Efter testkørsel Efter endt testkørsel, er det vigtig at evaluere den, og dokumentere de fejl der findes. Fejl skal evalueres, både i forhold til selve systemet, men også i forhold til selve testen. Elementer der tilhører en testcase Datamatikeruddannelsen forår/efterår 2006 Side 8 av 73

9 Test case Testdisciplinen består af mange artefakts, og testcase er en artefakt der beskriver hvilke informationer der er nødvendig for at teste. Alle de store komponenter i systemet er udgangspunkt for testcases. Dette inkluderer kravene, supplementerende specifikationer, design modellen og use case modellen. De vigtigste testklasser er dem der er baseret på kravene, men testklasser kan f.eks. også fokuseres på arkitekturen, og teste systemets design. Test cases udarbejdes for hver use case, og bør som et minimum dække normal flow og alle alternate flows. Hvis der bliver lavet for mange testcases, må man imidlertid prioritere og vurdere de test cases man har. En test case kan f.eks. simulere et klik på en knap i en GUI. Test cases kan også laves som aggregater af test cases. I denne sammenhæng betyder en variant den samme test case, med med forskellige indog uddata. De funktionelle krav fremgår ikke af use cases. To eksempler på dette er belastningskrav der omhandler systemets evne til at behandle store mængder data, og applikationens platformskrav der omhandler hvilket hardware og softwaremiljø systemet skal køre i. Performance kriterier En anden type ikke-funktionelle krav er er ydelseskrav der specificerer parametre som responstider. Testplan Stress krav Omhandler systemets evne til at fungere under unormale omstændigheder, f.eks med et unormalt højt antal transaktioner, lav diskplads eller lille tilgængelig system RAM. Disse krav omhandler også hvordan systemet opfører sig når det når en nedre grænse. Krav om adgangskontrol for dataacces Omhandler adgang til behandlede data, eller features ved systemet der er kritisk for systemets integritet. Dette bør testes før systemet sættes i drift. I et distribueret system, kan man have noder der er vidt forskellige. I et sådant miljø skal man f.eks teste at alle noder kan anvende den samme printer med det samme resultat. I testplanen samles alle oplysninger om formål og mål med testing. I tillæg til dette beskrives der her en teststrategi hvor der gives retningslinjer for den generelle fremgangsmåde, målene og en tidsplan. Denne kan laves i form af et gant-kort. Risiko vurdering Selvom det var muligt at teste alle aspekter af et software system, ville det ikke være ønskeligt at gøre det pga de omkostninger dette ville medføre. Derfor skal omkostningene ved testingen vejes op i mod fordelene. Prioriteringer ved risikovurdering Krav - Hvilke konsekvenser får det at et af kravene ikke overholdes. Her er det mere kritisk hvis dette korrumperer systemets sikkerhed, end hvis det forhinder udskriften af et dokument i at blive printet ud korrekt. Vurder mulige fejl der kan opstå, og hvilke krav der skal implementeres ukorrekt for at denne fejl skal opstå. Vurder sandsynligheden for at der vil opstå fejl i systemets forskellige komponenter. Datamatikeruddannelsen forår/efterår 2006 Side 9 av 73

10 Dette kan måles ved hjælp af faktorer som komponentens kompleksitet, teamets erfaringsniveau. Indkøbte komponenter kan også udgøre en risiko, f.eks hvis en nyere version ikke har de samme egenskaber eller API'er som den anvendte. Fejl og evalueringsrapporter Defekt artefakten indeholder en nøjagtig beskrivelse af en fejl, og hvordan den kan reproduceres. Den indeholder også oplysninger om grad af alvor, hvor kritisk den er og hvilken prioritet den har. Dette er beskrevet i standarder som IEEE Disse artefakter giver på denne måde en mulighed for at registrere testaktivitetene samtidig med at de dokumenterer og kommunikerer fejl. Hvis den samme fejl beskrives i flere artefakter, skal der være muligheder for at erklære dem som duplikater af tidligere rapportererede fejl. Disse artefakter kan også omhandle andet end fejl, f.eks. forbedringer der ligger udenfor projektets omfang. Et eksempel på dette kan være ønsker om ny funktionalitet. Artefakter til fejlrapportering: Artefakt Funktion Defekt distributionsrapport (DDR) Defekt density rapport (DDR) Defekt trend rapport (DTR) Viser fordeling af fejl på systemets komponenter Viser antal fejl som en funktion af en eller to fejlparametre. Viser antal fejl der har status ny, åben eller lukket Test status rapport, eller Test resultater og fremgangs rapport Viser resultatene af testkørsel over flere iterationer eller test cykler. Hvis man ønsker en detaljeret analyse af både produkt og proces, er det nødvendig at udarbejde flere artefakter. Disse skal vurderes sammen med andre rapporter, f.eks test coverage reports. Test Coverage Report Dette er en rapport der skal besvare følgende spørgsmål: Hvor komplet er testingen? Denne evaluering kan udføres på 2 måder: Hvor komplet testingen er i forhold til kravene For kravene måles der på om alle krav der skal testes er blevet testet og testresultatene er blevet dokumenteret. Måle kodens design/implementerings kriterium altså hvor meget kode er blevet testet. Hvor meget kode er testet og dokumenteret i forhold til systemets samlede mængde af kildekode? Datamatikeruddannelsen forår/efterår 2006 Side 10 av 73

11 Artefakter til vurdering af testaktiviteten Trend rapporter Denne giver et godt indtyk af hvor langt man er kommet i testaktivitetene. Trends i fejl følger et forudsig mønster i en testcyklus. Tidlig i udviklingscyklusen, er der stiger fejlraten hurtig, til den når toppen. Herefter falder fejlraten i et langsommere tempo. Hvis denne rapport sammenholdes med udviklingscyklusens tidsplaner kan man vurdere projektets fremdrift. Hvis f.eks. fejlraten ikke falder når man er kommet langt ind i en iteration, overholder projektet ikke sine tidsfrister. Defekt Trend Rapport Defect density report Når niveauet for testaktiviterne har nået et acceptabelt niveau, kan man vurdere produktets kvalitet. Dette kan udtrykkes i et Fejl Densitetsdiagram. Dette kan f.eks. laves for en use case, hvor man laver en søjle for normalt flow, og alle de alternative flow. Denne søjle kan yderligere deles op så man kan se fordelingen af mere eller mindre alvorlige fejl. Disse modeller er nødvendige for at understøtte fejlanalyser. Sammen med gode værktøjer til softwareudvikling, og ved at sammenholde dette med fejlraten, kan man på denne måden vurdere produktets kvalitet og pålidelighed. Defekt Densitets diagram over en use case med normal og alternate flows Datamatikeruddannelsen forår/efterår 2006 Side 11 av 73

12 Evaluering af testaktivitetene Dette gøres i 3 stadier: 1. Identificer fejl, og afgør om de er signifikante og kategoriseret rigtig. 2. Evaluer selve test processen for at vurdere om de passende testaktiviter er anvendt, og at de er pålidelige. 3. Vurder produktkvaliteten på baggrund af de ovennævnte evalueringer. Kategorisering af fejl Der er 4 vigtige parametre for at vurdere og kategorisere fejl: Parameter Værdier Status Prioritet Åben, Under reparation, Lukket etc Løses straks, Høj, Normal, Lav Alvorlighedsgrad Fatal, Vigtige funktioner ude af funktion, Mindre vigtig Kilde Krav, arkitektur, Modul X, Bibliotek Y Disse parametre kan anvendes på forskellige måder. Man kan f.eks. stille krav ud fra dem, ved at sige at produktet ikke kan leveres før der f.eks ikke er nogle fejl med høj prioritet og maksimalt X antal fejl med normal prioritet. Datamatikeruddannelsen forår/efterår 2006 Side 12 av 73

13 Zombie test komponenten der implementeres for at simulere en virkelig komponent. Denne komponent kan laves i 2 udgaver: Driver Simulerer en komponent der sender data ind til systemet, og starter derved testkørselen. Der er 2 typer drivere, en der kan simulere og kontrollere al ekstern interaktion med det testede system og drivere der simulerer em GUI der endnu ikke er implementeret. Stub Simulerer en komponent systemet sender data til. Dette kan være nødvendig hvis det ikke er praktisk muligt at sende data ud til et andet system, eller den modtagende komponent ikke er implementeret endnu. Stubs og drivere En stub kan enten være simpel, der returnerer en forudbestemt værdi, eller kompleks der udfører beregninger og kan simulere en mere avanceret komponent end den simple stub. Datamatikeruddannelsen forår/efterår 2006 Side 13 av 73

14 Hvordan gennemføre en heuristisk evaluering En heuristisk evaluering er en evaluering af en brugergrænseflade, med henblik på dens funktionalitet, brugervenlighed og opbygning. Baggrunden for denne undersøgelsen er en liste på 10 generiske kriterier, der omfatter mange aspekter ved en brugergrænseflade. Roller: Rolle 1. Synligheden til systemets status Systemet skal altid oplyse brugeren om hvad der sker, gennem relevante tilbagemeldinger. 2. Sammenhængen mellem systemet og verden omkring Systemet bør kommunikere i brugerens sprog i stedet for systemorienterede terminologier. 3. Brugerens kontrolmuligheder og frihed Hvis brugeren vælger en forkert funktion, skal der altid være en nødudgang. Understøt Fortryd og Genopret 4. Sammenhæng og standarder Brugeren skal aldrig være i tvivl om betydningen af et ord eller en handling. Anvend platformens konventioner. 5. Forebyggelse af fejl Et godt design kan forbygge fejlsituationer. 6. Genkendelse heller end hukommelse Brugeren skal ikke måtte huske informationer fra en del af dialogen til en anden. Instruktioner til anvendelse af systemet skal være tilgængelige på et hvert tidspunkt. 7. Fleksibilitet og effektivitet i brug Acceleratorer, som f.eks genveje fra tastaturet, skal være tilgængelige. Tillad brugeren at konfigurere disse. 8. Æstetisk og minimalistisk design Dialoger skal ikke indeholde mere information end nødvendig, da disse konkurrerer med med de relevante informationer. 9. Hjælp til brugeren i at fastslå, diagnosticere og genoprette fejl Fejlmeldinger i et tydeligt normalt sprog, med forslag til hvordan brugeren kan komme ud af fejlsituationen. 10. Hjælp og dokumentation Bør være let tilgængelig og have muligheder for søgninger. Børe rettes imod brugerens opgaver. Funktion Evaluator Observatør Eksperimenter Den der undersøger brugergrænsefladen Observerer og noterer evaluatorens interaktion med systemet Heuristiske undersøgelser gennemføres ved at man lader hver enkel evaluator undersøge brugergrænsefladen alene. Efter dette kan evaluatorene diskutere sine resultater med hinanden. Resultatene kan dokumenteres ved at evaluatorene noterer til en skriftlig rapport, eller ved at en observatør følger evaluatoren og noterer dennes mundtlige kommentarer. På denne måden får man et hurtigere resultat fordi hver observatør kun skal gennemgå en rapport, i stedet for at alle rapporter fra en enkelte evaluator skal gennemgås efter undersøgelsen. Datamatikeruddannelsen forår/efterår 2006 Side 14 av 73

15 Forskelle mellem en heuristisk evaluering og en traditionel brugerundersøgelse Heuristisk evaluering Evaluatoren er ansvarlig for at analysere brugergrænsefladen. Observatøren skal udelukkende notere evaluatorens kommentarer, og skal ikke selv fortolke noget. Ved en undersøgelse af en domæne specifik applikation, vil man gerne besvare evaluatorens spørgsmål. Specielt hvis evaluatoren er ukendt med domænet. Det at besvare evaluatorens spørgsmål, understøtter dennes vurdering af brugergrænsefladen med henblik på applikationens domæne. Traditionel bruger undersøgelse Observatørens er ansvarlig for at fortolke brugerens handlinger, og beskrive hvordan disse kan henføres til problemer i designet af brugergrænsefladen. Man vil gerne observere de fejl brugeren gør, og man er derfor tilbageholdende med at besvare brugerens spørgsmål, idet dette dette vil forstyrre brugeren i at lave fejl. De fejl brugeren gør anvendes til analysen af brugergrænsefladen. Hvis evaluatoren får åbenbare problemer med at anvende brugergrænsefladen, kan denne få små hint til at komme videre. Dette skal dog noteres i forbindelse med det aktuelle problem. På denne måde kan man reducere den tid testen tager. Under undersøgelse gennemgår evaluatoren en liste over kriterier. Denne liste er en generisk liste der dækker de generelle aspekter ved en brugergrænseflade, og kan udvides med kriterier der er specielle for en kategori af applikationer. Denne liste gennemgås for alle applikationens dialoger. Evaluatoren står også frit til at tilføje andre principper for brugbarhed som denne mener er relevant for den aktuelle dialog. Evaluatoren bestemmer som udgangspunkt selv hvordan evaluering skal gennemføres, men det anbefales at brugergrænsefladen gennemgås mindst 2 gange. Første gang giver et generelt overblik, og et overblik over interaktionenes flow. Anden gang kan evaluatoren fokusere på de forskellige dialoger ud fra kundskaber om hvordan de passer ind i systemet som helhed. Eftersom evaluatoren ikke anvender systemet til at løse en konkret opgave, kan heuristiske evalueringer anvendes på brugergrænseflader der kun eksisterer på papir. Dette gør der muligt at anvende denne metode tidlig i systemets design. Output Output fra en heuristisk analyse, er en liste over problemer i brugergrænsefladen, hvor en af de 10 kriterier ikke overholdes. For at undgå overlap og subjektive vurderinger, skal disse problemer listes sammen med det kriteriet de ikke overholder og en begrundelse herfor. Denne metoden giver ikke retningslinjer for hvordan de konstaterede problemer kan løses. Bestemmelse af antal evaluatorer I princippet kan en enkelt evaluator gennemføre en heuristisk evaluering af en brugergrænseflade. Det viser sig imidlertid at forskellige evaluatorer finder forskellig problemer. Hvor en evaluator finder 25-30% af fejlene i en brugergrænseflade, finder 16 evaluatorer 75-80%. I dette tilfældet, bliver dog den samme fejl slevfølgelig fundet af flere. Økonomiske beregner af denne metode, har vist at det økonomisk optimale antal af evaluatorer er 5-6, Datamatikeruddannelsen forår/efterår 2006 Side 15 av 73

16 da dette giver den bedste balance mellem økonomisk gevinst ved at afdække og rette problemer brugergrænseflade i forhold til udgiftene ved at have flere evaluatorer. Kilde: Datamatikeruddannelsen forår/efterår 2006 Side 16 av 73

17 Projekters livscyklus og modeller Et projekts livscyklus kan følge forskellige modeller. Der findes flere modeller, hvor mange af disse er baseret på tidligere modeller. Et projekt kan defineres som et kontrolleret miljø, der er sat op for at sikre produktionen af et produkt der dækker et forretningsbehov. For et software udviklingsprojekt taler man her om at producere et softwaresystem indenfor en bestemt tidsfrist, og indenfor et bestemt budget. Eftersom et projekt er defineret som noget der afsluttes, er det usandsynligt, men muligt at systemets vedligeholdelse indgår i projektet. Et projekt kan også være begrænset til f.eks en definition af krav et projekts livscyklus dækker altså leverancen af det der blev defineret som projektets produkt. Der er en anden forskel: Et systems udviklings livscyklus dækker ofte kun de tekniske leverancer, hvor projektet også dækker aspekter som ledelse og kvalitetsikring, der også er nødvendig for at levere et vellykket produkt. Typer af livscykler: 1. Specialiserede produkter Omfatter de konkrete leverancer i et softwareprojekt, software, manualer etc. 2. Kvalitetsprodukter Anvendes til at definere de ønskede kvalitetskriterier og kontroller der skal anvendes på projektet og produktet. 3. Ledelsesprodukter Anvendes til selve projektledelsen, organisering, planlægning rapporter etc. Valg af den rigtige udviklings livscyklus er vigtig for projektet, eftersom dette giver en ide om hele projektets forløb. Der findes kun 2 grundlæggende modeller: Vandfaldsmodellen og spiralmodellen. Alle andre modeller er varianter af disse 2. Vandfaldsmodellen Denne model blev udviklet i 70'erne, da det blev klart at softwareprojekter havde behov for en mere formaliseret proces. Selve udviklingsprocessen deles op i et antal sekventielle stadier der repræsenteres i bokse. Hvert stadie afsluttes inden den næste påbegyndes, og output fra det ene stadium er input for det næste. Hvert stadium er delt op i en fase med det faktiske arbejde og en verificering og validering af dette arbejdet. Verificering betyder at kontrollere sammenhængen mellem produkt og specifikationer, altså om man laver produktet rigtig. Validering fokuserer på om produktet kan anvendes i produktion, altså om man laver produktet rigtig. Vandfaldsmodellen fungerer bedst når kravene er veldefinerede, og forretningsområdet er statisk. Nogle metoder, f.eks. SSADM (Structured Systems Analysis & Design Model) er baseret på vandfaldsmodellen, men imødegår nogle af dennes svagheder. Datamatikeruddannelsen forår/efterår 2006 Side 17 av 73

18 b-modellen En af vandfaldsmodellens svagheder er at vedligeholdelsesfasen ikke er dækket godt nok. Operation og vedligeholdelse er 2 separate stadier. Man opfatter ikke vedligeholdelse som forskellig fra de andre stadier, i det at de er pågående og ikke afsluttes. Hver ændring i systemet, vil gennemgå faser med analyse af levedygtighed, analyse, design, produktion, acceptance og til sidst operation. V-modellen V-modellen er en anden variant af vandfaldsmodellen. Stadierne er vist i en V-formation. Det venstre, nedadgående ben viser fremgangen fra analyse, design og programmering, og repræsenterer en opdeling af systemet. Det højre, opadgående ben, viser den følgende samling, testing og implementering af produktet. Det vigtige med denne model, er at der er sammenhæng mellem stadierne i venstre og højre ben. Dette vil sige at de enkelte programmer, eller moduler testes imod det enkelte modul design, den integrerede software testes imod systemets design etc. Datamatikeruddannelsen forår/efterår 2006 Side 18 av 73

19 Den inkrementelle model Dette er en anden variant af vandfaldsmodellen, der udelukkende anvendes når systemets totale funktionalitet skal leveres i faser. Dette gør levering og testing lettere at styre fordi systemet implementeres i faser. Denne model er uegnet når projektets omfang er dårlig defineret, eller hvis der er uklarhed i kravene. Spiralmodellen Spiralmodellen er forskellig fra vandfaldsmodellen, ved at der introduceres en evolutionær eller iterativ metode til systemudvikling. Dette er specielt nyttig hvis kravene ikke er klart defineret eller der er usikkerhed omkring kravene hos brugeren. I denne model udføres de samme aktiviteter over et antal cykler. På denne måden kan man klargøre kravene, løse problemer og forbedre. Dette tilsvarer at udviklings livscyklusen gentages flere gange. Spiralen er inddelt i 4 sektorer: 1. Venstre, Øverst Målene bestemmes, alternativer og begrænsninger findes. 2. Højre, Øverst Alternativer vurderes, risici identificeres og løses. 3. Højre, Nederst Udvikling og verificering. 4. Venstre, Nederst Næste fase eller iteration planlægges. Denne spiral introducerer vigtige koncepter som målsætning, risikohåndtering og planlægning. Dette er en fordel i forhold til projektstyring, fordi de har en direkte indflydelse på faktorer som overholdelse af tidsfrister. Spiralmodellen. Kilde: rocess3_htsu1.html Datamatikeruddannelsen forår/efterår 2006 Side 19 av 73

20 Metodologier Generel definition på metodologi: En anbefalet serie af anbefalede handlinger og procedurer der skal følges for at udvikle et informationsystem. Dette rejser nogle grundlæggende problemstillinger, som f.eks hvad forskellen er på en metode og en metodologi eller om en metodologi indeholder en specificering af de metoder og værktøjer der skal bruger, eller om en samling af metoder og værktøjer udgør en metodologi. Begrundelse for at anvende metodologier Et bedre produkt Forbedre produktet, dvs det system der bliver udviklet. Det er imidlertid vanskeligt at vurdere kvaliteten til et software system, da der lægges vægt på forskellig, og af og til modstridende egenskaber ved et system. De kvalitetattributter man kan lægge vægt på ved et system, omfatter alt fra om brugerne er tilfreds med systemet, dets tilgængelighed, grad af binding, kompabilitet, dokumentation, driftsomkostninger, effektivitet, vedligeholdelsesfaktor, sikkerhed, robusthed, funktionalitet osv. Man kan ikke optimere et system for alle disse attributter. En bedre udviklingsproces Dette omfatter bla de fordele man kan opnå ved at kontrollere udviklingsprocessen og dens resultater for hvert stadium. For andre kan udviklingsprocessen forbedres ved at indføre kvalitetstandarder, der forbedrer produktet gennem en forbedret proces. En standardiseret proces Fordele ved at have fælles procedurer og fremgangsmåder i en organisation omfatter bla at man let kan flytte personalet fra et projekt til et andet. Desuden kan man ved en standardardisering af processen og dokumenter, oprette en kundskabsbase i organisationen. Datamatikeruddannelsen forår/efterår 2006 Side 20 av 73

21 Metodesammenligning Der er 2 hovedårsager til at man ønsker at foretage en metodesammenligning: Akademiske årsager Man søger en dybere forståelse for metodologier, deres egenskaber, metoder, filosofi osv, for at klassificere dem og forbedre senere systemudviklingsprojekter. Praktiske årsager Man skal vælge en metode, eller dele af den, til brug i en organisation. De grundene kan godt overlappe hinanden, idet akademiske studier forhåbentligvis kan understøtte den praktiske vurdering. Attributter ved vurdering af metodologier: Regler, omfang, forståelse af informations ressourcer, dokumentationstandarder, opdeling af logisk og fysisk design, validering af design, tidlige ændringer, kommunikation mellem processens stadier, effektiv problemanalyse, planlægning og kontrol, kvalitetsforbedring, produktets synlighed, sværhed at lære, tilpasning af design, effektiv kommunikation, enkelhed, relevance, understøttelse af automatiske værktøjer, betragtning af brugerens mål, deltagelse, opdeling af analyse og design osv. Man kan ikke finde alle disse attributter i en enkelt metode. Derfor kan listen kun anvendes som en huskeliste når metoder skal sammenlignes. Checkliste over kriterier ved vurdering af metodologier: Hvilke research paradigme/perspektiv er metodologien baseret på? Hvad er den grundlæggende værdier? I hvilke grad er det muligt at modificere metodologien, kan det overhovedet lade sig gøre? Findes transferablity? Omfatter den det sociale miljø, inklusive mulige konflikter? Er der opfordret eller understøttelse for brugerdeltagelse? Denne liste omfatter en del attributter der ofte overses. Normative Information Model-based Systems Analysis and Design (NIMSAD) Dette er baseret på modeller og epistemologien til systemer, og er baseret evalueringen på en sammenligning imod disse kriterier: 1. Element Problemsituationen (Metodologiens sammenhæng) inden metodologien tages i brug. Klientens forståelse, erfaringer og Problem ejerens problemer Brugeren af metodens situation: Dennes diagnose; struktureret eller ustruktureret Hvordan metoden kan afhjælpe situationen. Situationens politik eller kultur, og hvilke risici anvendelsen af metoden indebærer Den overvejende opfattelse af situationen, er den teknisk, politisk, social osv? Datamatikeruddannelsen forår/efterår 2006 Side 21 av 73

22 2. Element Den ønskede problemløser (Metodologiens bruger) brugen af metodologien Hvilken holdninger og værdier har metodens brugere? Disses sammenhæng, som den er antaget i metoden Hvordan misforhold mellem disse håndteres Metodens filosof, f.eks om den har et naturvidenskabelig eller systembaseret paradigme. Metodens bruger erfaringer, evner og motiver sammenlignet med det der er behov for i forhold til metoden. 3. Element Problemløsningsprocessen (Metodologien) Evaluering af brugen af metodologien Forståelsen for situationen, dens problemer og afgrænsning. Definition af prognoser, f.eks ønskede tilstande, legitime tilstande, konfliktløsning. Definition af problemer. Dannelsen af idesystemer, bliver de dannet og hvordan blev de defineret? Udarbejdelsen af begrebsmæssig/logisk og fysisk design, hvem gjorde det, og førte det til forbedringer eller nytænkning? Implementering af design, hvordan håndteres alternativer, og hvordan sikres succes? Evalueringen udføres i 3 stadier, før under og efter anvendelsen af metodologien. Andre metoder til sammenligning Fastslå usikkerhedsmomenter i systemet Der er beskrevet en del andre metoder til sammeligning af metodologier. Disse er mere pragmatiske til en generel vurdering af metodologiens generelle egenskaber. Man kan ikke finde den bedste metodologi, fordi de ikke nødvendigvis ekskluderer hinanden. Derfor skal metoden søges i de foreligende problemer, applikationen, organisationen og dens kultur. En fremgangsmåde er at vurdere usikkerhedmomentene i et system: Systemets kompleksitet. Systemets tilstand eller flyd. Brugersiden, f.eks antal brugere og deres erfaringsniveau. Analysens grundighed. Når dette er fastslået, kan bestemme hvordan kravene skal identificeres. Ved lav usikkerhed, kan man nøjes med interviews. Ved høj usikkerhed skal man anvende en prototype eller evolutionær tilnærmelse. 5 typer af situationer og deres løsninger 1. Veldefineret problem og klare krav. Traditionelle løsninger 2. Veldefineret problem og uklare krav. Data eller procesmodellering eler prototyper anbefales. 3. Ustruktureret problemstilling med uklare mål. Datamatikeruddannelsen forår/efterår 2006 Side 22 av 73

23 4. Et system med høj bruger interaktion. En løsning der fokuserer på mennesker. 5. Uklar situation. Rammeværk til sammeligning af metodologier 7 punkts sammenlignigsmetoden er et framework til sammenligning af metoder. Ideen med dette framework, er at sætte op en liste med kriterier til vurderingen. Ved at sammenholde beskrivelser af metoder i henhold til disse kriterier, får man beskrivelser af metoderne der er egnet til sammenligning, fordi at man får beskrevet de samme egenskaber ved de metoder man ønsker at sammenligne. Når systemudviklingsmetoder skal vurderes, er der en lang række attributter der kan vurderes. Dette omfatter metodernes håndtering af dokumentstandarder, procedurer for analyse og design, artefakter, understøttelse af automatiske udviklingsværktøjer, egnethed i bestemte sammenhænge eller til bestemte systemer osv. 7 punkts sammenligningsmetoden prøver at omfatte alle disse forskellige egenskaber, men er ikke helt komplet. Andre elementer der kan vurderes er hastigheden for udviklingen af systemet, antal af specifikationer og dokumentation og potentiale for tilpasning til det miljø metoden skal anvendes i. Punkter: Filosofi Hvilke filosofiske betragtninger bygger metoden på? a) Paradigme F.eks det videnskabelige eller systemorienterede paradigme. a) Målsætning Er metodologiens formål f.eks at udvikle et system? a) Domæne Hvilke domæne af problemer adresseres af metodologien? a) Metodologiens anvendelse Generel metode, eller henvender den sig til specielle situationer, f.eks. små eller store organisationer? Model Verbal Analytisk eller matematisk Ikonisk eller skematisk Simulering. De aller fleste metodologier er baseret på en skematisk model. Teknikker og værktøjer Hvilke teknikker og værktøjer anvendes af metoden? Omfang Metodens omfang i forhold til systemets livscyklus. Output i form af leverancer, og ikke mindst det endelige produkt, der kan omfatte et totalt system eller kun en analyse. Praksis a) Baggrund Kommerciel eller akademisk? a) Bruger base Hvem skal anvende metoden? Dette er et vigtigt punkt! a) Deltagere Kan man anvende metoden selv, eller er der behov for professionelle analytikere? Produktet Hvad får man for pengene ved at købe denne metode?? Datamatikeruddannelsen forår/efterår 2006 Side 23 av 73

24 Agile processer Agile processer Det Agile Manifest Individer og Interaktioner heller end processer og værktøjer Arbejde med software heller end udtømmende dokumentation Samarbejde med kunden heller end kontraktforhandlinger Respondere på forandring heller end følge en plan Agile metoder I en moderne økonomi, er det ikke muligt at forudsige hvordan et system vil udvikles som tiden går. Markedet er i konstant forandring, brugernes behov ændres og nye konkurrencemæssige trusler dukker op. Dette medfører at man ikke kan planlægge et helt system inden det påbegyndes. Et agilt team er et team der reagerer hurtig på ændringer, i softwaren der udvikles, i teamet, ny teknologi. Et agilt team anerkender at software udvikling udføres af mennesker der arbejder sammen, og har forskellige evner. Evnen til samarbejde er det vigtigste for at projektet skal blive vellykket. 12 principper for agilitet 1) Det højeste mål er at tilfredsstille kunden, gennem tidlig og hyppige leverancer af værdifuld software. 2) Ændringer er altid velkomne, selv sent i forløbet. Agile processer billiger forandringer der giver kunden konkurrencefordele. 3) Leverancer af funktionel software ofte, med perioder fra et par uger til et par måneder. Kortest mulige perioder. 4) Forretningsmænd og udviklere må arbejde sammen daglig gennem hele projektet. 5) Byg software omkring motiverede mennesker. Giv dem de nødvendige ressourcer, og stol på at de får det gjort. 6) Den mest effektive måde at kommunikere på er direkte samtale. 7) Funktionel software er det vigtigste mål på fremgang. 8) Agile processer understøtter vedvarende udvikling. Sponsorer, udviklere og kunder skal holde et tempo de kan overholde i det uendelige. 9) Vedvarende opmærksomhed på teknisk perfektion og godt design fremmer agilitet. 10) Enkelhed kunsten at reducere ikke udført arbejde er essentiel. 11) De bedste arkitekturer, krav og design kommer fra selv-organiserede grupper. 12) Med jævnlige intervaller, skal teamet overveje hvordan det kan blive mere effektivt, og implementere ændringer som følge af dette. Agilitet kan tilpasses enhver software proces, men for at opnå dette, er det vigtigt at processen er sådan designet at teamet kan tage til sig opgaver og strømlinje dem. Hvad er en agil proces? En agil proces er karakteriseret ved at den imødegår 3 grundlæggende antagelser: 1. Det er vanskeligt at antage på forhånd hvilke software krav der vil bestå, og hvilke der vil ændres. Det er tilsvarende vanskeligt at forudsige kundens prioriteringer når projektet skrider frem. 2. For mange typer software er design og implementering sammenflettede aktiviteter. Det er vanskeligt at forudsige hvor meget design der skal til før konstruktion bruges til verificering. Datamatikeruddannelsen forår/efterår 2006 Side 24 av 73

25 3. Analyse, design, konstruktion og testing er ikke så forudsigeligt som vi antager. Ud fra disse antagelser, må man finde frem til en proces der kan håndtere uforudsigelighed, dvs at processen må være tilpasningsdygtig. Fortløbende tilpasning i sig selv opnår ikke meget. Derfor må processen også være inkrementel. For at opnå fortløbende feedback, må processen tidligt resultere i en prototype eller tidlig version af produktet, og fortsætte og levere mere og mere færdige versioner af produktet med kortest mulige mellemrum. Dette sikrer hyppig feedback fra kunden. Man må anvende en inkrementel udviklingstrategi. Debatten om den agile proces Der er en aktiv debat om de agile metoders fordele og anvendelighed, hvor modstanderne påpeger faren i at analyse og design ikke bliver godt nok når det nedprioriteres. Fortalerne for agile metoder kritiserer de gamle metoder for at fokusere mere på produktionen af artefakts, som dokumentation, end selve produktionen af software. Ingen er modstandere af agilitet. Spørgsmålet er heller hvordan det bedst kan opnås, og hvordan man producerer software af høj kvalitet der overholder kundens ønsker og mål. Der er ingen absolutte svar på dette spørgsmål, og indenfor den agile metode, har dette ført til debat og udviklingen af flere agile metoder. Mange af disse er adaptioner af gode og anerkendte softwareudviklingsmetoder. Derfor kan der vindes meget ved at overveje det bedste fra de to skoler. Menneskelige faktorer Fortalere for de agile metoder bruger mange kræfter på at understrege vigtigheden af de menneskelige faktorer. Agil udvikling fokuserer på de menneskelige færdigheder, og tilpasser processen efter medarbejderne og teamet. Det der er vigtig her, er at processen tilpasses mennesker og ikke omvendt. Hvis teamets medlemmer skal styre processen der anvendes til udvikling af software, må der findes følgende egenskaber hos medlemmene i teamet: Kompetence Agile, såvel som konventionelle udviklere må have talent, erfaring med den specielle software, og generelle kundskaber om den processen der anvendes. Fælles fokus Alle medlemmer i et agilt team må arbejde imod det samme mål at levere et funktionsdygtig software inkrement til tiden. Kundskaber om udviklingen, produktet og processen må gives til nye medarbejdere. Samarbejde Software udvikling handler om at analysere, bedømme og bruge informationer, og anvende information der kommunikeres i teamet. Der må være et godt samarbejde i teamet, og med kunden og ledelsen. Myndighed til at tage afgørelser Ethvert godt software team, må gives myndighed til at bestemme sin egen skæbne. Dette implicerer at teamet gøres selvstyrende. Evne til løsning af uklare problemstillinger Man må anerkende at udviklerne altid vil stå over for ambivalente problemstillinger. Derfor må udviklerne kunne tage afgørelser både om tekniske og projektmæssige problemstillinger. Gensidig respekt og tillid Et godt medlem har respekt overfor sine kolleger, og vilje til at holde den. Datamatikeruddannelsen forår/efterår 2006 Side 25 av 73

26 Selv organisering I et agilt team indebærer dette 3 ting: 1. Teamet organiserer selv sit arbejde. 2. Teamet organiserer processen, så den passer til miljøet. 3. Teamet sætter selv sine tidsplaner, så man opnår de optimale release cykluser. Dette hare en række fordele, bl.a. at det er godt form moralen, og opfodrer teamet til at overholde sine egne tidsfrister. Ingenting er så demoraliserende som at andre indgår forpligtelser på ens vegne. Agile procesmodeller extreme Programming XP XP anvender en objektorienteret tilnærmelse, og indeholder et sæt med regler og fremgangsmåder (practises) i en sammenhæng med 4 aktiviteter: Planlægning, design, kodning og testing. XP kan opsummeres på følgende måde: Planlægning Planlægningsaktiviteten begynder med et sæt brugerhistorier der beskriver ønskede features og funktionaliteter for produktet. Hver historie skrives af kunden og gives en værdi baseret på sin prioritet. Udviklerne vurderer historierne, og deres omkostninger i udviklings tid i uger. Hvis det tager mere end 3 uger at implementere historien, bliver kunden bedt om at dele den op. Nye historier kan skrives på et hvilket som helst tidspunkt. Udviklere og kunden samarbejder om at bestemme hvilke historier for den næste release. Så en grundlæggende forpligtelse (commitment) om hvilke historier der skal implementeres og levereringsdato, begynder udviklerne at implementere brugerhistorierne. Dette kan ske på 3 måder: 1) Alle historierne implementeres inden 2-3 uger 2) De historierne med højest prioritet placeres øverst på arbejdsplanen og bliver implementeret først, eller 3) De mest risikofyldte historierne placeres øverst på arbejdsplanen og bliver implementeret først. Efter 1. release er afleveret, beregner teamet projektets hastighed (velocity). Enkelt sagt er dette det antal historier der blev implementeret i den forrige release. Projektets hastighed anvendes i den videre planlægningen til at bestemme leverancedato og arbejdsplan for den næste iteration, og til at beslutte om arbejdet blev overestimeret i den forrige iteration. Under hele udviklingsforløbet kan kunden ændre i brugerhistorierne eller deres prioritering. Brugerne kan også slette brugerhistorier. Teamet må så lægge sine planer om efter dette. Design XP følger princippet Keep it Simple (KIS). Et simpelt design er altid foretrukket frem for er komplekst. Designet giver retningslinjer for en brugerhistorie som den er skrevet Hverken Datamatikeruddannelsen forår/efterår 2006 Side 26 av 73

27 mere eller mindre. Design af ekstra funktionalitet, fordi udvikleren synes det er en god ide, er ikke ønsket. XP understøtter brugen af CRC-kort (Class Responsibility Collaborator), som en metode til at tænke i en objekt-orienteret sammenhæng. CRC-kortene identificer de klasser, og afhængigheder mellem klasser der er nødvendige for at implementere de aktuelle brugerhistorier. Hvis noget, i design, er uklart i en brugerhistorie, anbefaler XP en umiddelbar udarbejdelse af en prototype, eller spike solution. Denne prototype implementeres og vurderes. Formålet er at reducere risici når selve implementeringen udføres. XP anbefaler refaktorering en konstruktionsteknik og en designteknik hvor man skriver koden om, uden at ændre dens funktionalitet, for at forbedre eller forenkle dens struktur. Eftersom XP ikke producerer nogle artefakts udover CRC-kort og spike solutions, anses design for en forgængelig disciplin det kan ændres under hele implementeringen. Formålet med refaktorering er at implementere disse ændringene i designet. En central ide i XP er at design pågår før, under og efter kodning, refaktorering er et værktøj til dette, og ideen er at selve konstruktionen af software giver retningslinjer til designet. Kodning XP anbefaler at man inden implementering, men efter at brugehistorierne er skrevet og det indledende design er gjort, skriver unittests der skal køres på al kode inden den integreres i den aktuelle release. Når unittesten er skrevet, kan udvikleren fokusere på det der skal implementeres for at bestå unittesten, og intet andet (KIS). Så snart koden er skrevet, kan unittesten anvendes til at give hurtig og kontinuerlig feedback. Et andet nøgleprincip i XP, er parprogrammering. XP anbefaler at udviklerne arbejder sammen i par under kodning. Dette understøtter hurtig problemløsning, ved at to koncentrerer sig om det samme problem. Dette understøtter også kvalitetsikring af koden. Under parprogrammeringen sidder den ene foran tastaturet og koder, mens den anden sidder ved siden af og ser lidt længere frem, kontrollerer at kodestandarden overholdes osv. Adaptive Software Development (ASD) Det filosofiske grundlag for denne metode, er samarbejde mellem teamets medlemmer og selvorganiserede grupper. Selv-organisering er en egenskab ved komplekse adaptive systemer der ligner et kollektivt 'aha' i det øjeblik løsningen på et nagende problem dukker op. Selv-organisering opstår når individuelle, uafhængige agenter (celler i en krop, arter i et økosystem, udviklere i et team) samarbejder for at opnå nye egenskaber. Disse egenskaber går ud over egenskaberne til den enkelte agent. Man anser vanligvis disse egenskaber for at være tilfældige, men studiet af selv-organisering viser at denne antagelse er forkert. ASD er opdelt i livscykluser der består af 3 faser: Spekulation (Speculation) Projektet startes op og en adaptiv planlægning af cykluser udføres. Til dette bruges den indledende information, projektets mission statement, begrænsninger som f.eks leveringsdatorer, bruger beskrivelser etc. Der planlægges et set af release cykluser. Samarbejde (Collaboration) Motiverede mennesker arbejder sammen på en sådan måde at deres samlede talent overstiger deres antal. Samarbejde er dog ikke let. Det er ikke bare kommunikation og samarbejde. Man må også stole på hinanden så man kan (1) Har mod til at kritisere hinanden (2) Assistere Datamatikeruddannelsen forår/efterår 2006 Side 27 av 73

28 hinanden uden forbehold (3) Arbejde lige så hårdt eller hårdere end de andre (4) Have evner og kundskaber så man kan bidrage til det foreliggende arbejde (5) Kommunikere problemer så de fører til den rigtige handling. Læring (Learning) Når udviklerne begynder at udvikle systemet, er fokus lige meget på læring som fremgangen imod en afsluttet cyklus. Softwareudviklere overestimerer ofte deres forståelse, og læring vil bidrage til at bedre deres reelle indsigt. Læring foregår på 3 måder: 1. Fokus grupper Kunden og/eller slutbrugere giver feedback på de software inkrementer der er leveret. 2. Formel teknisk gennemgang Teamet gennemgår de komponenter der er udviklet, for at forbedre dem, og lærer af dette. 3. Obduktioner (Postmortems) - ASD teamet kigger tilbage på sin egen ydelse og proces med tanke på forbedring og læring. ASD kan anvendes på alle processer, eftersom metoden fokuserer på dynamikken i en selvorganiseret gruppe. Mellem-menneskeligt samarbejde og individuel læring giver software projekter der har en bedre chance for at lykkes. Dynamisk System Development Method (DSDM) Fokuserer på et rammeværk for udvikling og vedligeholdelse af software systemer der overholder tidsfrister. Dette opnås ved regelen der siger at 80% af systemer tager de første 20% af udviklingstiden. DSDM livscyklus består af 5 faser: (1) Feasibility study, (2) Business study, (3) Functional model iterations, (4) Design and build iterations, (5) Implementation. Scrum En metode der er opkaldt efter en manøver i rugby. Srcums principper er i overenstemmelse med det agile manifest. Små teams, Adaptiv proces, Hyppige software inkrements, Arbejdet deles op i små enheder, Konstant testning. Et produkt kan erklæres færdig hvis omstændighederne kræver dette, f.eks hvis et konkurrende produkt kom på markedet, brugeren skal have det etc. Crystal Fokuserer på manøvrerbarhed i et ressource begrænset spil med fokus på samarbejde med opfindelse og kommunikation, der fører til leverance af nyttig og anvendelig software. Mål nr. 2 er at sætte op det næste spil. Feature Driven Development (FDD) En agil proces der fokuserer på features, hvor features er en funktionalitet der er vigtig for kunden, og som kan implementeres på mindre end 2 uger. Dette giver en fordelagtig opdeling af udviklingsarbejdet Datamatikeruddannelsen forår/efterår 2006 Side 28 av 73

29 Agile Modeling Store og komplekse systemer kræver modellering. For at opnå dette i en agil metode, uden store og komplicerede modeller, har man en regel der siger Modeller med et formål, og Anvend flere modeller. Enkelhed er et mål og et bærende princip er at indhold er vigtigere end repræsentation, hvilket vil sige at modeller skal laves efter sit publikum. Datamatikeruddannelsen forår/efterår 2006 Side 29 av 73

30 Hvad er systemudvikling? Erfaring spiller en stor rolle i systemudvikling. Nogle systemudviklere anvender imidlertid kun sine egne erfaringer. På denne måden gør man fejl der kan undgås, og ser ikke nye muligheder. Metoder kan ikke erstatte erfaring, men kan inspirere praktikere. Teori kan give praktikere forståelse og hjælp til at bearbejde egne erfaringer. Computer teknologi i organisationer Både applikationer og hardware udvikler sig. Applikationer anvendes i dag på alle områder og i alle brancher. Prisene på hardware har gjort dette muligt. Dette har ført til nye krav til softwaresystemer, og moderne softwareprojekter handler både om udbygning af eksisterende systemer, såvel som udvikling af nye systemer. Systemudvikling er en del af organisationens udvikling, og er i større grad end tidligere blevet en politisk proces der kan involvere omfattende organisatoriske spørgsmål. Ydelse og ledelse Hvilke komponenter er en systemudviklingsmetode bygget op af, og hvilke type arbejde indebærer den? For at forstå dette, må man finde frem til en forståelse for systemudviklingsmetoder, der er uafhængig af dem. Der er flere måder at beskrive komponenterne i en systemudviklingsmetode: Beskrivelse af arbejdet, eller tjenester eller produkter der er resultatet af arbejdet. Beskrivelse af hvad der rent faktisk sker, eller hvad man ønsker skal ske. Proces og aktivitet En proces beskriver hvad der rent faktisk sker. En proces er håndgribelig og finder sted i tid og rum. En aktivitet beskriver deler af en proces der hører sammen. Funktion Funktioner er den mest abstrakte måder at betragte systemudvikling på. I modsætning til processer og aktiviteter, beskriver funktioner hvad man ønsker skal ske, En funktion udføres gennem en aktivitet. Analyse, design og planlægning er funktioner der tilsvarer aktiviteter. Opgave (Task) En opgave er en konkret beskrivelse af et forsæt. Datamatikeruddannelsen forår/efterår 2006 Side 30 av 73

31 Komponenter i systemudviklingsmetoder Disse kan beskrives ud fra 3 grundlæggende forskelle: Produktorienteret versus projekt orienteret. Refleksion versus aktion. Nutiden versus visioner. Komponenter i systemudvikling Systemudviklere udfører almindeligvis to aktiviteter. De udvikler software systemer, og ændringer i organisationen. Der er to elementer i systemudviklingen, et produktorienteret element, ydelse og et procesorienteret element, ledelse. Udover denne forskel, skelner man mellem refleksive aktiviteter og handlinger (actions). Refleksive aktiviteter kan igen deles op i aktiviteter rettet imod dagens virkelighed og refleksive aktiviteter rettet imod en vision. Fordelen med denne måde at betragte systemudvikling på, er at det ikke er bundet op imod en speciel metode. Performance Systemudviklingens faktiske ydelse består af de refleksive funktioner analyse og design, og den innovative funktion realisering. Analyse Fører til forståelse af den nutidige virkelighed. Design Fører til visioner om fremtiden. Realisering Fører til konkrete ændringer. Datamatikeruddannelsen forår/efterår 2006 Side 31 av 73

32 Principper i performance Der er en række grundlæggende principper knyttet til analyse, design og realisering, der kan udtrykkes i en række principper: 1. Analyse og design er gensidig afhængige, og bør derfor udføres samtidigt. 2. Produktorienteret refleksion (analyse og design) og realisering påvirker hinanden, og bør derfor udføres samtidigt. Den logiske rækkefølge, analyse, design realisering er den mest naturlige rækkefølge i systemudviklingsprojekter. Dette indebærer at projekter har størst vægt på analyse i starten, derefter flyttes vægten over til design, og til sidst realisering. Når et projekt planlægges, bør der sættes af tid til aktiviteter der ikke fører fremover. Det er f.eks ikke meget ved at planlægge testing, hvis der ikke er tid til at håndtere fundne fejl. 3. Det er ikke muligt at udføre analyse og design strengt efter retningslinjer. Aktivitetene kræver erfaring, intuition, fantasi og eftertanke. 4. Projektgruppens forhold til kunden er af afgørende betydning for analysens kvalitet. 5. Godt design er et spørgsmål om at flyve højt, med begge ben på jorden. Nye visioner og ukonventionelle løsninger må skabes. Det må også være muligt at introducere dem i organisationen. 6. Teknisk orienterede analyser og design kan føre til løsninger på de forkerte problemstillinger. Kvalificerede analyser kræver teknisk ekspertise og social kompetence. 7. Kvalificererede analyser kræver at forskellige perspektiver indrages. Valg af værktøjer, teknikker og organisering er afhængig af situationen. 8. Hverken analyse eller design aktiviteter kan gå i en retning fra helhed til detaljer. 9. Test løser ingen problemer. Planlæg tid til udbedringer. 10. Kvalificererede realiseringer kræver grundig planlægning. Management Management af den refleksive del: Evaluering og planlægning. Management af de innovative funktioner: Regulering. Evaluering Evaluering er rettet direkte imod processen, og på de aktuelle planer. Evaluering består typisk af aktiviteter som (1) Vurdering af status, (2) Evaluering af planer, (3) Evaluering af møder, (4) Evaluering af fremgang og (5) Rapportering til udvikler og brugerorganisationen. Planlægning Denne aktivitet resulterer i planer på forskellige niveauer, og en beskrivelse af det der skal til for at realisere en plan. Planlægning består typisk af aktiviteter som (1) Projektetablering, (2) Generel planlægning, (3) Detaljeret planlægning. Regulering Regulering er rette imod processen i bred forstand, imod medarbejderne, arbejdsmetoder og forhold generelt. Regulering består typisk af aktiviteter som (1) Projektetablering, (2) Projektgruppemøder, (3) Forhandlinger med udvikler og brugerorganisationen, (4) Evaluering af aktiviteter og (5) Kurser Datamatikeruddannelsen forår/efterår 2006 Side 32 av 73

33 og videreuddannelse. Principper i management En del grundlæggende principper er knytte til management af systemudviklingsprojekter. 1. Evaluering og planlægning er gensidigt afhængig af hinanden, og bør derfor udføres samtidig. 2. Procesorienteret refleksion (planlægning og evaluering) og regulering påvirker hinanden, og bør derfor udføres samtidigt. 3. Systemudvikling bærer præg af høj usikkerhed. Den bedste forudsætning for management er derfor gennemsigtighed i både processer og produkt. 4. Det kan betale sig at grundlægge projektet systematisk. 5. Grundlinjer og checkpoints er bedre end traditionelle faser. Traditionel faseindeling forvirrer og vanskeliggør dynamisk regulering af projektet. 6. Projektplanen må understøtte evaluering. De må være skriftlige og understøtte procedurer og kriterier for evaluering. 7. Kun systemudviklerne ved nok til at lægge realistiske planer og evaluere projektets status. 8. Det er vigtig at alle i projektet forstår og accepterer planen. 9. Det er nødvendigt at anvende flere teknikker til estimering. Planen bør baseres på et sandsynligt estimat og bør udtrykke graden af usikkerhed i estimatet. 10. Man skal planlægge med managementaktiviteter. Disse udgør normalt 15-20% af projektet. Management og performance Den sidste, men måske vigtigste komponent i systemudvikling er forholdet mellem management og performance. Systemudviklingsprojekter er ofte karakteriseret ved en høj grad af usikkerhed. Dette er udtrykt i de følgende fundamentale principper: 1. Et systemudviklingsprojekt bør organiseres så der er direkte og tæt kontakt mellem performance og managementaktiviteter. 2. De vigtigste midtvejs produkter er planen og det overordnede design. Der er en stærk sammenhæng mellem performance og management. Planen er et nøgleelement i management, og design er et nøgleelementet i performance. Dårlig management er karaktereriseret ved dårlig planlægning og dårlig evaluering. Dette fører til tilfældighed og forvirring. Datamatikeruddannelsen forår/efterår 2006 Side 33 av 73

34 Beslutningstagning, kommunikation og socialisering I tillæg til komponentene ovenfor, er der en række mere generelle funktioner, som beslutningstagning, kommunikation og socialisering. Beslutningstagning Der tages mange beslutninger i et systemudviklingsprojekt, der berører både processen og produktet. Nogle beslutninger tages internt i projektgruppen. Andre involverer eksterne personer og grupper. Nogle beslutninger er tidkrævende, og en god projektplan tager højde for dette. Kommunikation Dette er grundlæggende og nødvendigt, om ikke andet, så fordi mange mennesker samarbejder i et softwareprojekt. Kommunikation er afhængig af sender og modtager, f.eks om de kommunikerende er systemudviklere. Kommunikation er afhængig af det anvendte sprog, og kræver ofte i denne type projekter et formaliserede beskrivelser etc. Socialisering Socialisering er også en vigtig funktion, blot fordi mange mennesker samarbejder i et projekt. Socialisering er i første række rettet imod det interne samarbejde. Det er en almindelig fejl at give socialisering for lav prioritet. Indfaldsvinkler til systemudvikling Proces hvor man skaber Formålet er at skabe et computersystem, og integrere dette i organisationen. Systemudvikling er en organisatorisk udvikling. Denne udvikling giver processen sine egenskaber: De formaliserede beskrivelser af systemet må leve op til strenge krav. Indsigt i det anvendte tekniske udstyr er en forhåndsbetingelse. Kompleksiteten er ofte så stor at udviklerne ikke bare må have teknisk indsigt, men også gode evner til abstraktion og systematisering. En proces med tekniske og organisatoriske ændringer. Den grundlæggende formål med systemudvikling er at ændre de teknologiske, formelle og sociale strukturer i brugernes organisation. Selve processen kræver også at at der oprettes strukturer, eller rammer, hvor udviklingen kan foregå. Sociale og skabende processer er i første række rettet imod mennesker og menneskelige forhold. Tekniske hjælpemidler er bare midler til at opnå dette. Kvalificeret innovativt arbejde kræver menneskelig og organisatorisk indsigt. En kognitiv proces Subfunktioner i systemudvikling Brugerne lære om tekniske og organisatoriske muligheder. Noget skal læres om hvad der skal til for at teamet kan designe systemet. Kognitive processer må ikke blive reduceret til rutine, da de kræver eksperimentering, åbne sind og inspiration. Derfor må systemudviklingsprojekter organiseres så man sikrer tæt samarbejde mellem aktivitetene der tilhører performance og management. Datamatikeruddannelsen forår/efterår 2006 Side 34 av 73

35 Politisk proces De forskellige grupper og personer deler kun til en vis grad et fælles mål. Systemudviklingsprojektet betragtes som en mulighed til at fremme sine egne mål, også på andres bekostning. Konflikter kommer til syne, og den politiske proces forgår i en atmosfære af konflikter. Den professionelle systemudvikler prøver ikke at skjule den politiske proces, men prøver at flytte den til det rigtige forum. Teori, metode og praksis Ideelt set, bør teorier gøre en i stand til at forstå nogle af de love og mekanismer der styrer design og udviklingen i et softwareudviklingsprojekt. En metode er, i modsætning til en teori, direkte rettet imod handling. En metode er instruerende, og giver få eller ingen forklaringer. Man kan vælge at karakterisere en systemudviklingsmetode ud fra dens anvendelse, det underliggende perspektiv eller dens retningslinjer for processen. Man kan yderligere skelne mellem forskellige typer retningslinjer: Teknikker, valg af værktøjer eller organisationsprincipper. Karakteristika ved systemudviklingsmetoder Anvendelsesområder Der er forskel på at udvikle et offline lønsystem for 25 ansatte, og et online system med 500 terminaler i 200 afdelingskontorer. Forskellige systemudviklingsmetoder har ting til fælles, men det er vigtigt at kende metodernes anvendelsesområde. Perspektiv Alle metoder giver brugerne et perspektiv der giver forskellige måder at betragte tingene på. Metoderne beskriver ikke altid dette, men kan altid ses ud fra dens retningslinjer, f.eks i de koncepter der anvendes i analyse og design. Retningslinjer De forskellige metoder har forskellige retningslinjer. Disse kan også være prioriteret forskelligt fra den ene metode til den næste. Teknikker Hvordan forskellige arbejdsopgaver kan løses, eller hvordan en aktivitet skal udføres. Værktøjer En teknik anvender et eller flere værktøjer, f.eks et programmeringsprog. På den ene side, kræver udarbejdelsen af et nyt værktøj en vision om en aktivitet. På den anden side giver anvendelsen af et nyt værktøj ny erfaring. Udviklingen af teknikker og værktøjer går hånd i hånd og udtrykker en professionel indsigt i en aktivitet. Organisationsprincipper Organisationspricipperne beskriver hvordan grupper og individer skal samarbejde, og hvordan ressourcer skal fordeles og anvendes. Disse principper er sjældent knyttet til specielle aktiviteter, men indikerer sammenhængen mellem performance og management. Eksempler: Indeling af projektgruppe og styregruppe, brugerdeltagelse i analyse. Datamatikeruddannelsen forår/efterår 2006 Side 35 av 73

36 Forholdet mellem metode, funktioner og processen Funktioner Funktioner er en abstrakt beskrivelse af systemudviklingsprocessen. Den udtrykker hensigten med nogle af de aktiviteter der finder sted i en proces. En funktion omhandler ting der skal ske. Metoder En metode beskriver hvordan en aktivitet skal udføres. Metoden giver retningslinjer for systemudviklingsprocessen, og indikerer hvilke aktiviteter der kan udføres samtidigt. En metode udtrykker også de nødvendige kundskaber og værktøjer der er nødvendige for at aktiviteten skal lykkes. Hvad der rent faktisk skete, er nedfældet på et konkret niveau i konceptet: systemudviklingsprocessen. Den kan beskrives gennem de faktiske arbejdsgange og de faktiske forhold man arbejdede under. Opmærksomheden kan rettes imod helheden eller på del-processer. Teori er en ting, praksis en anden. Det der tæller ved systemudvikling er praksis. Datamatikeruddannelsen forår/efterår 2006 Side 36 av 73

37 Agil projekt management Mange softwareprojekter er løbet ind i problemer som små budgetter, korte leveringsfrister, komplekse forløb med meget dokumentation etc. Dette har ført til at nogle projektmedlemmer har brugt op til 50% af tiden på ikke produktivt arbejde. Agile metoder prøver at imødekomme disse problemer og fokuserer på værdi for kunden. Kundeværdi kan opsummeres i det rigtige produkt til den rigtige tid for den rigtige pris. Agilitet er evnen til at levere kundeværdi selvom man skal håndtere uforudsigelige projekter med sin egen dynamik gennem at acceptere og tilpasse sig forandring. Det er evnen til at balancere mellem stabilitet og fleksibilitet, orden og kaos, planlægning med udførelse, optimering og udforskning. Ikke mindst kontrol med hastigheden så man kan levere reel kundeværdi til trods for ændringer og ustabile processer. Grundlæggende elementer Små releases Arbejdet deles op i små enheder der er mere overskuelige. Barely sufficient tilnærmelse. Iterativ og inkrementel udvikling Planlægning, krav, design, kodning og tests udvikles trinvis i iterationer, heller end gennem tunge vandfaldsfaser. Samlet placering Hele teamet, inklusive en repræsentant for kunden samles i en åben arbejdscelle der understøtter direkte kommunikation og gode interaktioner. Specielle værelser indrettes til formålet. Release plan/feature backlog Ønskede features defineres på højt niveau og prioriteres af kunden og udviklerne i fællesskab og der udarbejdes en en relase plan i release planning game. Iterationsplan/Task backlog Høj niveau features fra release planen bearbejdes og prioriteres i form af udviklingsopgaver i en iterationsplan. Prioriteringen foretages som et samarbejde hvor udviklerne prioriterer ud fra estimeringer og udviklerne ud fra prioriterede features. Selv-organiserende grupper Teamets medlemmer organiserer sig selv, ved vedholdene opgaveløsning i samarbejde. Arbejde i par Specifikt for XP. Alt arbejde foregår i grupper på 2, så man kan samarbejde om opgaven og dele kundskaber. Test-drevet udvikling Specifikt for XP. Udviklerne udvikler tests inden de skriver kode, og udvikler kode så den overholder testene. Test specificerer og validerer kode. Tracking Egenskaber og opgaver spores i hver iteration. Dette danner grundlag for estimering og planlægning af næste iteration. Opgaver er kun færdige når de er 100% løst. Enkel, oversigtlig og tilpasningsdygtig Alle aspekter af arbejdet, inklusive processer, holdes så enkle og overskuelige som mulig, for at optimere kundeværdi og tilpasningsdygtighed. Agile metoder udvikledes stille og rolig, indtil en gruppe af deres fortalere mødtes og udgav det agile manifest. Datamatikeruddannelsen forår/efterår 2006 Side 37 av 73

38 Hvad er agil management? Agil projektmanagement er at motivere og opfordre projektgrupper til at hurtigt og pålideligt levere kundeværdi, gennem engagement af kunden, og uophørligt lære og tilpasse sig foranderlige behov og miljøer. Agile metoder adskiller sig fra traditionelle metoder både kvantitativt og kvalitativt. Man anvender en lige tilstrækkelig tilnærmelse til planlægning, processer og kontrol, og fokuserer heller på skabelsen og levering af kundeværdi. Agile projekter er baseret på princippet om komplekse adaptive systemer. Komplekse adaptive systemer Levende systemer, som projekter, er komplekse ved at de består af mange autonome agenter, der interagerer på mange forskellige måder. Denne interaktion styres af enkle lokaliserede regler og er karakteriseret ved en konstant feedback. Kollektiv opførsel er karakteriseret ved en overliggende orden, selv-organisering, og der opstår en kollektiv intelligens der gør at gruppen ikke bare kan beskrives som summen af sine medlemmer. Kompleks orden optræder fra gruppen, eller systemet selv, heller end fra en ekstern styrende kraft. Disse selv-organiserede komplekse Adaptive Systemer (CAS) er tilpasningsdygtige ved at de reagerer forskelligt i forskellige omstændigheder, og udvikles sammen med sit miljø. Projektmanagent efter disse princippet, kræver en lige tilstrækkelig tilnærmelse. Principper i agil projektmanagement For at kunne stå imod ændringer, må alle metodologier være baseret på to grundelementer: Dens grundlag må bestå af et enkelt, men uforanderlig sæt af principper og værdier. I anvendelse må den tillade fleksible arbejdsgange der kan tilpasses forandring i miljøet og omstændighederne. Med denne forståelse, bygger agile projektmanagement på CAS' principper: Understøt koordinering af mål og samarbejde Mennesker regnes som den vigtigste ressource i alt udviklingsarbejde. Mennesker samarbejder bedre, hvis alle arbejder imod den samme målsætning og deler de samme visioner. Fremskynd selv-organisering Processer og arbejdsgange holdes så enkle som mulige. Mennesker organiserer sig selv, og fællesskabet yder så mere end summen af den enkeltes evner. Instituer læring og tilpasning Feedback anvendes til kontinuerlig læring, tilpasning og forbedring. Projekter arbejder på grensen af kaos, hvor der er akkurat nok ledelse og kontrol. Her får den enkelte den størst mulige frihed til at skabe, uden at blive forhindret af kontrolforanstaltninger. Datamatikeruddannelsen forår/efterår 2006 Side 38 av 73

39 Agil praksis Disse er i første række rettet imod at levere kundeværdi,, og mindre imod at sikre kontrol og reducerede udgifter. De er baseret på CAS metaforen, og vægtlægger en fleksibel ledelsesform. Organiske teams: Opret kontakt og tilpasning gennem tætte forbindelser i små fleksible teams Selv-organisering og resultater der går ud over gruppens samlede evner, frembringes af gode interaktioner, eller flow, mellem mennesker. Små grupper bedrer interaktion, og udløser denne gode interaktion. I stedet for at udvide gruppen ved behov for flere funktioner, skal gruppens medlemmer tage til sig flere funktioner. Hvis man skal organisere mange mennesker, skal de deles ind i mange små teams. Guidet vision: Sikre at teamets medlemmer alle arbejder imod den samme vision, og ledes af en delt mental model Mentale modeller er udgangspunkt for den enkeltes forventninger og tilpasning. Når en vision nedfældes i et projektgrundlag, må dette kommunikeres ud til alle i teamet. Et eksempel på dette princip er militærets officerens intetion. Officeren kan ikke altid være alle vegne. Derfor må intentionen i en ordre kommunikeres til alle, så den kan være en guide for alle. Alle kan derfor udføre opgaven, selvom ledelsen er fraværende. Enkle regler: Definer et sæt enkle generative proces regler for teamet. Mange metodologier har et udtømmende sæt med processer, skabeloner, leveringsfrister og regler. Dette repræsenterer ofte en byrde på teamet, og følges derfor ikke. Standard i XP er derfor en enkelt sæt med enkle regler. Gennem hele udviklingsforløbet kontrollerer ledelsen om arbejdsgange bliver udført, og fjerner forhindringer hvor disse findes. Reglerne må ikke forhindre kreativitet og selvstyret. Åbne informationer: Sørg for fri og åben tilgang til informationer I agile projekter er informationer katalysatoren til fremgang og tilpasning. Interaktioner mellem mennesker skaber en åben strøm af informationer. Ved at sørge for at informationer flyder frit i organisationen og teamet, skabes en uhindret udveksling af information der påvirker alle. Light touch: Anvend intelligent kontrol for at fremme emergent orden og maksimal værdi. Traditionelle metoders stræben efter stabilitet og kontrol har ofte ført til metoder og værktøjer med det formål at kontrollere en verden i konstant forandring. Dette fokus på kontrol har ofte ført til at det faktum at verden er foranderlig, er blevet ignoreret. Med light touch, anerkender man at øget kontrol ikke nødvendigvis nedsætter usikkerhed og øger orden og værdi. Light touch anvender ledelse med mod til at acceptere at man ikke ved alt på forhånd, og afgiver kontrol for at opnå større orden og værdi. Adaptiv ledelse: Led projektet gennem konstant monitorering, læring og tilpasning Det mest kreative og agile arbejde gøres på kanten af kaos. Uforudsigelig nok til at være interessant, men ordnet nok til at undgå fiasko. Datamatikeruddannelsen forår/efterår 2006 Side 39 av 73

40 Ledelse af et team gøres ved at etablere en guidet vision, organisere små veltilpassede grupper og lede dem ved hjælp af light touch og åbne informationstrømme. Adaptiv ledelse betyder kontinuerlig observation og vurdering af arbejdsgange, og tilpasningen af dem ved behov. Disse skal så implementeres med fuld kraft. Den agile manager forstår effekten af gensidig kommunikation og interaktioner mellem gruppens medlemmer, og styrer projektet gennem konstant monitorering og læring, og gennem tilpasning af sin tilnærmelse. Datamatikeruddannelsen forår/efterår 2006 Side 40 av 73

41 Arkitektonisk design Store systemer deles altid op i subsystemer, der giver relaterede tjenester. Den indledende proces hvor man identificerer subsystemerne og deres relationer, og placerer dem i et rammeværk, er det arkitektoniske design. Resultatet er en beskrivelse af software arkitekturen. Udarbejdelsen af en beskrivelse af systemets arkitektur har 3 fordele: 1. Kommunikation til stakeholders Arkitekturen giver en beskrivelse på et højt niveau, og kan være et udgangspunkt for diskussion med stakeholders. 2. Analyse af systemet Udviklingen af system arkitekturen, indebærer en tidlig analyse af systemet. Beslutninger omkring arkitekturen har stor betydning for om systemet lever op til de krav der stilles. 3. Genbrug på højt niveau System arkitekturen kan genbruges i andre systemer. Udarbejdelsen af en system arkitektur, indebærer at der tidligt træffes vigtige beslutninger om systemet, og kan give udgangspunkt for diskussioner omkring kravene til systemet. Arkitekturen påvirker en række ikke-funktionelle krav: Prioriteret krav Performance Sikkerhed Sikring Tilgængelighed Vedligeholdelse Konsekvens for arkitekturen Kritiske operationer placeres i et lille antal subsystemet med mindst mulig intern kommunikation. Dette indebærer store komponenter for at reducere kommunikationen. Kræver en lagdelt struktur, hvor de mest beskyttede dele er indkapslet i de inderste lag, med de strengeste krav til sikkerheds validering. Arkitekturen bør designes så de metoder der må være sikre placeres i et eller få sub systemer. Dette reducerer omkostningene, og gør det muligt at anvende relaterede systemer til beskyttelse Her bør arkitekturen udformes, så man kan have redundante komponenter, så disse komponenter kan udskiftes uden at standse systemet. Et system der er let at vedligeholde, består af mange detaljerede og uafhængige komponenter, der let kan udskiftes. Producenter af data bør adskilles fra konsumenter. Eftersom disse krav er i konflikt med hinanden, kan det være nødvendigt at indgå kompromisser hvis man prioriterer flere af disse krav, eller ved at have et system med forskellige arkitekturer i forskellige subsystemer. Opdeling i subsystemer, er en abstrakt opdeling af systemet i store komponenter. Dette repræsenteres i blok diagrammer. Flere blokker i en boks, indikerer at et subsystem er delt op i flere subsystemer. Pile angiver subsystemernes indbyrdes forhold. Dette giver en oversigt over systemet, der ikke er detaljeret nok for software designere, men giver god kommunikation til stakeholders, uden for mange forstyrrende informationer. Repræsentation af subsystemer Opdeling i subsystemer kræver nogle vanskelige beslutninger, men det vigtigste udgangspunkt er kravene til systemet. Datamatikeruddannelsen forår/efterår 2006 Side 41 av 73

42 Beslutninger omkring system arkitektur. Udviklingen af systemets arkitektur, skal betragtes som en række grundlæggende beslutninger omkring systemets design. I denne proces skal en række spørgsmål besvares: 1. Kan man anvende en generisk arkitektur som skabelon? 2. Hvordan vil systemet blive distribueret over flere processorer? 3. Hvilken arkitektonisk stil er passende? 4. Hvad vil være den fundamentale tilnærmelse til systemets strukturering? 5. Hvordan vil systemet strukturelle enheder blive delt op i moduler? 6. Hvordan skal systemets enheder kontrolleres? 7. Hvordan vil det arkitektoniske design blive evalueret? 8. Hvordan skal system arkitekturen dokumenteres? Udarbejdelsen af system arkitekturen Selv om hver software system er unikt, har systemer indenfor det samme domæne en lignende arkitektur. Arkitekturen kan baseres på en speciel arkitektonisk model eller stil. Forskellige subsystemer behøver ikke at have den samme arkitektur. 1. Først vælges systemets struktur, f.eks. klient-server, eller lagdelt struktur, ud fra kravene. 2. For at dele strukturene op i moduler, bestemmes hvordan subsystemene deles op i komponenter eller moduler. Dette kan gøres forskelligt i de forskellige subsystemer. 3. Dernæst laves en kontrol model, hvor der tages stilling til hvordan de forskellige subsystemer køres og kontrolleres 4. Der udarbejdes en generel model, hvor man viser kontrollen mellem modulsene i form af forhold mellem dem. Evaluering af arkitekturen er vanskelig, fordi den eneste ægte test af en arkitektur, er kørselen af systemet. Repræsentationen af systemarkitekturen. Systemarkitekturen kan fremstilles på flere måde, afhængig af hvad der fokuseres på. Grafisk fremstilling: Fokuserer på: Statisk strukturel model Dynamisk proces model Interface model Forholds model Distribution model Viser subsystemer eller komponenter der skal udvikles som uafhængige enheder. Viser hvordan systemet er organiseret i processer ved run-time. Viser hvilke tjenester det enkelte subsystem tilbyder over en public interface. Viser forhold, som f.eks. dataflow, mellem subsystemene. Viser hvordan systemet er fordelt over forskellige computere. Datamatikeruddannelsen forår/efterår 2006 Side 42 av 73

43 Der er udviklet specielle sprog, architectural language descriptors (ADL), kan anvendes til at vise arkitekturen, men uformelle modeller og notationer som UML er det mest almindelige. Systemets organisering Systemets organisering reflekterer den grundlæggende strategi ved struktureringen af et system. Systemets organisering bør afspejles direkte i strukturen til subsystemene. Modelleringen af subsystemene er imidlertid ofte meget mere detaljeret, og en mapning fra systemets organisering til systemets opbygning i subsystemer kan derfor være vanskelig at gøre direkte. Der er 3 modeller til organisering af systemet: Repositorie modellen Subsystemene i et system har behov for at udveksle information, så de kan samarbejde mere effektivt. Der er 2 fundamentale løsninger på dette: 1. Alle fælles data er gemt i en central database, der kan tilgås af alle subsystemer. 2. Hvert subsystem vedligeholder sin egen database. Data udveksles mellem subsystemene ved hjælp af meldinger. Repositorie modellen De fleste systemer der håndterer store mængder data anvender denne model. Dette omfatter bl.a. informationsystemer, CAD-systemer og CASE værktøjer. Fordele og ulemper: En effektiv måde at dele store mængder data. Subsystemer der producerer data, behøver ikke bekymre sig for om modtageren kan forstå dem. Backup, sikkerhed, adgangskontrol og fejlrettelser kan håndteres af repositoriets kontroller. Subsystemene må alle enes om denne model. Dette kan gå ud over behovet til det enkelte modul. Derfor må kompromisser indgås der kan reducere modulets ydelse. Udvikling kan vanskeliggøres hvis store mængder data produceres efter et forhåndsbestemt format. Konvertering til et andet format kan være dyrt og vanskeligt. Subsystemene kan have forskellige krav til dette. Politiken bliver imidlertid ens for alle subsystemer. Adgangen til data er synlig i hele systemet. Det er nemt at integrere nye værktøjer, så længe de er kompatible med repositoriets dataformat. Det kan være vanskeligt at distribuere repositoriet over flere maskiner, da dette kan give problemer med redundans og inkonsistens i dataene. I de ovennævnte modeller, er repositoriet passivt, og kontrollen er lagt i det subsystem der anvender det. Der er udviklet modeller hvor repositoriet trigger subsystemer når bestemte data bliver tilgængelige. Beslutninger om hvilke subsystem der skal aktiveres, kan først tages når dataene er analyseret. Datamatikeruddannelsen forår/efterår 2006 Side 43 av 73

44 Klient-server modellen Klient-server arkitekturen er organiseret i tjenester, med associerede servere og klienter der anvender disse tjenestene. Systemet består af Et antal servere der yder tjenester til andre subsystemer. Dette kan være printeller filservere, eller kompileringservere der kompilerer et bestemt programmeringsprog. Et antal klienter, der kan benytte de tjenester serverne tilbyder. Disse er Klient-server modellen. normalt egne subsystemer. Flere instanser af et klientprogram kan køre samtidigt. Et netværk der tillader kommunikation mellem klienter og servere. Dette er ikke strengt nødvendig, da klient og server kan køre på den samme maskine. I praksis implementeres klient-server systemer som distribuerede systemer. Klienten må kende til de servere den skal benytte tjenester fra, men serveren behøver ikke at kende klientene, eller antal klienter. Der benyttes en bestemt protokol, og klienten anmoder serveren om en tjeneste, hvorefter den venter på svar. Den største fordel med denne model er at det er en distribueret arkitektur. Dermed kan man effektivt udnytte udnytte netværksystemer med mange distribuerede processorer. Det er let at opgradere eller tilføje nye servere uden at det påvirker andre komponenter i systemet. Ændringer i eksisterende klienter og servere kan imidlertid blive påkrævet ved udskiftning eller tilføjelse af nye servere. Der kan ikke være noget fælles data i systemet, og subsystemer kan organisere sine data på hver sin måde. Den lagdelte model Den lagdelte, eller den abstrakte maskinemodel, organiserer systemet i lag. Hvert lag sørger for bestemte tjenester. Hvert lag kan betragtes som en abstrakt maskine, hvis sprog er defineret ved de tjenester det yder. Dette sprog anvendes til implementeringen af det næste lag. Eksempler på dette kan være OSI's netværkslag, eller en 3-lags model for et system. Den lagdelte model understøtter inkrementel udvikling af et system. Efterhånden som et lag bliver udviklet, bliver flere tjenester tilgængelige for de overliggende lag. Eftersom de inderste lag er maskine specifikke, er det lettere at overføre et lagdelt system til flere systemarkitekturer. Ulemper: Lagdelt design Det kan være vanskeligt at strukturere et lagdelt system, og bestemme hvad der skal i hvilke lag. De mest maskine specifikke komponenter lægges i de nederste lag, men af og til er det mest praktisk med kommunikation direkte fra de øverste til de nederste lag. Performance kan også blive et problem, fordi meldinger skal sendes i gennem mange lag. Dette kan dog omgås ved at sende meldinger gennem flere lag. Datamatikeruddannelsen forår/efterår 2006 Side 44 av 73

45 Opdeling i moduler. Der er ikke en klar distinktion mellem subsystemer og moduler, men man kan anvende følgende definitioner: Subsystem Modul Er et system i sig selv. Er ikke afhængig af andre subsystemer. Subsystemer deles yderligere op i moduler, og har definerede API'er til kommunikation med andre subsystemer En systemkomponent der yder en eller flere tjenester til andre moduler, og anvender tjenester fra andre moduler. Kan ikke betragtes som et system. Der er 2 måder at dele systemer op i moduler på: Objekt orienteret opdeling Modulene er objekter, med forskellige tilstande og definerede operationer Funktions orienteret pipelining Modulene er funktionelle transformationer. I begge tilfælde kan modulene implementeres som sekventielle komponenter eller processer. Man bør undgå for tidlige beslutninger om samtidighed i et system, fordi det er meget vanskeligt at teste sådanne systemer. Derfor bør man begynde med at dele systemet op i moduler, og beslutte, under implementeringen, om modulene skal køre samtidigt eller sekventielt. Objekt orienteret opdeling Består af objekter, hvilket er moduler der er løst koblet og har et veldefineret sæt af funktioner. Objekter kalder andre objekters funktioner, og modulenes definitioner er fokuseret på klasser, deres variabler og funktioner. Fordele: Eftersom objekter er løst koblet, kan man let ændre i et objekt uden at dette går ud over andre objekter. Objekter har som regel sin baggrund i objekter i problemområdet, og dermed bliver systemet let at overskue fordi man har denne reference fra objekt til problemområdet. Eftersom de afspejler virkelige objekter, kan de genbruges i andre systemer. Er understøttet i objekt orienterede programmeringsprog. Ulemper: For at anvende en tjeneste, skal man angive objektets nøjagtige navn og metode. Derfor kan det være vanskeligt at ændre en tjenestes interface. Det kan være vanskeligt at repræsentere et komplekst problemområde i objekter Datamatikeruddannelsen forår/efterår 2006 Side 45 av 73

46 Funktions orienteret pipelining (dataflow model) Viser funktionelle transformationer, og deres input og output. Data flyttes, omformes og flyttes videre i en sekvens. Disse transformationene kan køre samtidigt eller sekventielt, og data kan behandles enkeltvis eller i batches. Denne måde at modulere på, kaldes også pipe og filtre efter Unix terminologi, og er anvendt helt tilbage til de første computere der blev anvendt til databehandling. Fordele: Understøtter genbrug af transformationene. Intuitivt i den forstand at man kan afspejle en arbejdsproces. Systemet kan udvides ved at man tilføjer flere transformationer. Det er nemt at implementere enten som sekventielle eller samtidige operationer. Ulemper: Der kræves et fælles format for dataoverførsler til de forskellige transformationer. Det er vanskeligt at lave interaktive systemer ved hjælp af pipelining, fordi der kræves strømme af data. GUI's har mere avancerede I/O formater og kontroller, der er vanskelige at styre i en enkel datastrøm der anvendes til en transformation. Kontrol metoder Modeller for strukturering af systemer, fokuserer på hvordan et system deles op i subsystemer. For at systemet skal fremstå som et system, er det nødvendigt at subsystemene kontrolleres sådan at de rigtige tjenester startes på de rigtige tidspunkter. Kontrol modeller på arkitektur niveau, er optaget af flow af kontrol mellem subsystemer. Der er 2 modeller for hvordan et system kontrolleres: 1. Centraliseret kontrol. Et subsystem har det overordnede ansvar for kontrollen af systemet, og starter og stopper andre subsystemer. Det kan også overlade kontrollen til andre subsystemer, men forventer at få kontrollen tilbage. 2. Hændelses baseret kontrol. Hvert subsystem kan reagere på udefra kommende handlinger. Disse hændelser kommer enten fra andre subsystemer, eller fra det miljø systemet opererer i. Alle de forskellige strukturer kan anvende både centraliseret eller hændelses baseret kontrol metoder. Datamatikeruddannelsen forår/efterår 2006 Side 46 av 73

47 Centraliseret kontrol. Med denne kontrol metode, har et bestemt subsystem opgaven som systemkontroller, og sørger for at starte og stoppe systemets øvrige subsystemer efter behov. Dette kan gøres på 2 måder, afhængigt af om subsystemene kører sekventielt eller parallelt. Kald-retur metoden. Den traditionelle styring ovenfra ned, hvor kontrollen starter i toppen, hvorfra subrutiner kaldes nedover i hierarkiet. Denne model kan kun anvendes til sekventielle systemer. Anvendelse: Kan anvendes på modul niveau til kontrol af funktioner eller objekter. Fordele: Det er relativt enkelt at analysere kontrol strømmen og beregne hvordan systemet vil reagere på specielle inputs. Ulemper: Den strikte kommandovej er besværlig fordi det er vanskeligt at implementere undtagelser til de normale handlinger i systemet. Den styrte model. Kald-retur kontrol model Kan anvendes i systemer der anvender samtidighed. Én systemkomponent udpeget som kontrol modul, og er ansvarlig for at starte, stoppe og koordinere de forskellige system tjenester. Subsystemer kan anmode om specielle typer hændelser, så kontrollen bliver overført til det anmodende subsystem ved disse hændelser. En proces er et subsystem eller modul der kan køre parallelt med en anden system proces. Denne kontrol metode kan også anvendes til sekventiel kontrol, hvor processer standses og startes efter værdier i systemets tilstandsvariabler. Centraliseret, styret med samtidighed Anvendelse: Kontrolleren kører som en uendelig løkke, der poller for eksterne hændelser der skal føre til at tjenester startes eller standses. Derfor kaldes denne model også for event-loop modellen. Datamatikeruddannelsen forår/efterår 2006 Side 47 av 73

48 Hændelses drevne systemer I et hændelses baseret kontrol system, bliver tjenester startet og stoppet ud fra eksterne hændelser, der kommer udefra, eller fra et subsystem til et andet. En hændelse er karakteriseret ved at det subsystem der skal håndtere hændelsen ikke har nogen indflydelse på hvornår de indtræffer. Der findes mange typer hændelses drevne kontrolsystemer, bl.a Broadcast systemer Hændelser sendes til alle subsystemer, men bliver kun håndteret af de subsystemer der er ansvarlig for hændelser af den type der er indtruffet. Anvendelse: Integrering af subsystemer der er fordelt over flere computere i et netværk. Fordele: Er effektiv ved integrering af subsystemer der er fordelt over forskellige computere i et netværk- subsystemene kan implementeres på distribuerede maskiner. Let at tilføje nye subsystemer til systemet. Kun nødvendig at ændre hændelsehåndtereren. Ulemper: Eftersom alle hændelser sendes til alle moduler, skabes der et processerings overhead Interrupt drevne systemer Eksterne hændelser (interrupts) håndteres af en interrupt handler, der sender hændelsen videre til det subsystem der er ansvarlig for den indtrufne hændelse Anvendelse: Real-time systemer med strenge krav til hurtighed. Kan anvendes sammen med et subsystem der har den centrale kontrol. Fordele: Tillader meget hurtig respons på hændelser. Systemkontrol baseret på selektiv broadcast Ulemper: Kompliceret at programmere og validere. Kræver hardware understøttelse. Interrupt drevet kontrol metode Der kan være begrænsninger i antal interrupt hånderere. Dette kan omgås ved at lade en håndterer modtage flere interrupts, men dette vil nedsætte responstiden. Datamatikeruddannelsen forår/efterår 2006 Side 48 av 73

49 Reference arkitekturer Ovennævnte modeller for arkitektur er generelle modeller, der kan anvendes på mange typer forskellige typer applikationer. Nogle af disse modellene er specifikke for et specielt domæne af applikationer. Selvom applikationene ikke er helt nøjagtig ens, kan den arkitektoniske struktur genbruges til helt nye applikationer. Dvs de er domæne specifikke arkitektur modeller. Der findes 2 typer af disse: Generiske modeller. Abstraktioner fra mange virkelige systemer, der gør at modellen fanger principperne i den type applikation der beskrives. Kan anvendes direkte til design af et system. Reference modeller. Mere abstrakt, og beskriver klasser af systemer. Dette er en måde at beskrive de generelle strukturer til en type af applikationer. Referencemodeller har sin baggrund i en studie af et domæne af applikationer. Anvendes som en base systemer kan sammenlignes imod. Eksempler: OSI's lagdelte model til implementering af netværks stakken, eller TCP/IP stakken. Referencemodel for CASE værktøjer, der består af et data repositorie, data integrerings tjenester, opgavestyring, meldings tjenester og bruger interface. Applikationslaget Transportlaget Netværkslaget Linklaget Fysisk lag OSI lagdelte netværksarkitektur Reference arkitektur for CASE tools Datamatikeruddannelsen forår/efterår 2006 Side 49 av 73

50 Distribuerede system arkitekturer. Næsten alle store computer-baserede systemer er i dag distribuerede systemer. Et distribueret system, er et system hvor behandling af information er fordelt over flere maskiner. Der er mange fordele ved distribuerede systemer. Ulemper: Deling af ressourcer Tillader deling af hardware og softwareressourcer, som printere, diske, databaser, kompilere, filer osv. Åbenhed Åbne systemer, der er designet omkring åbne standarder, som f.eks. netværkprotokoller, der tillader anvendelsen af forskellige typer hardware i det samme system. Samtidighed Processer kan køre samtidig på forskellige computere i netværket. Disse processer kan kommunikere med hinanden. Skalerbarhed Der er i princippet let at skalere distribuerede systemer, både med flere noder og tjenester. Dette kan imidlertid begrænses af netværkets kapacitet. Fejltolerance Hvis en node går ned, går ikke nødvendigvis hele systemet ned. Totalt nedbrud sker kun ved nedbrud af netværket. Høj kompleksitet Distribuerede systemer er generelt mere komplicerede end centraliserede. Ydelsen er f.eks. afhængig af netværkets båndbredde og hastigheden til de processorer der er på netværket. Flytning af ressourcer på netværket kan have store konsekvenser for systemets ydelse. Sikkerhed Der er adgang til systemet fra flere computere, og trafikken kan blive aflyttet, eller blive udsat for denial-of-service angreb. Kontrolerbarhed (Manageability) Computere i systemet kan være forskellige, og køre forskellige operativsystemer. Fejl i en node kan føre til fejl andre steder på netværket, og derfor være vanskelige at spore. Uforudsigelighed Systemets respons er afhængig af belastningen på netværket, dets organisering og belastningen på selve systemet. Alt dette kan ændres på kort tid, og give store forskelle i responstid. Der er 4 grundlæggende arkitekturer til design af distribuerede systemer: Klient-Server og arkitekturer baseret på distribuerede objekter, peer-to-peer og service-orienterede arkitekturer. Komponentene i en distribueret system kan implementeres i forskellige programmeringsprog, og køre på forskellige typer hardware. Middleware er en betegnelse på den software der sidder i mellem de forskellige komponenter i systemet og sørger for at de kan kommunikere og udveksle data. Distribuerede systemer udvikles som regel ved hjælp af objekt-orienterede værktøjer, og er bygget på af løst koblede komponenter, der er uafhængige, men som kan interagere direkte med andre komponenter eller brugere af systemet. Dele af systemet kan stå for at håndtere hændelser udefra. Software objekter kan reflektere disse egenskaber, og er derfor abstraktioner af komponenter i det distribuerede system. Datamatikeruddannelsen forår/efterår 2006 Side 50 av 73

51 Multiprocessor arkitekturer Den enkleste model af distribuerede systemer, består af mange processer der kører på separate processorer. Denne model er ofte brugt i store realtids systemer. Disse systemer anvender nogle processer til at indsamle informationer, og sende dem til andre processer (actuators) der ændrer systemets miljø. Sådanne Multiprocessor trafikkontrol system systemer kan få højere ydelse ved at køre dem på flere processorer, hvor den enkelte proces kan køre på en forudbestemt processor. Software systemer med flere processer, er ikke nødvendigvis distribuerede systemer. Hvis der er mere end en processor til rådighed, kan distribution implementeres, men dette er ikke altid nødvendigt at tage stilling til under design af systemet. Distribuerede arkitekturer Klient-server arkitektur Klient-server arkitekturer er består af en række tjenester der udbydes af en eller flere servere og klienter der benytter disse tjenester. Klientene må kende tjenestene, men behøver ikke nødvendigvis at kende de andre klienter. Klienter og servere er separate processer. Designet af klient-server systemer, bør reflektere den logiske struktur til den applikation der udvikles. Man kan f.eks benytte den lagdelte arkitektur med et Præsentationslag, applikationslag og et data behandlings lag, der står for tilgangen til databasen. Når man designer en klient-server arkitektur, skal man bare have en klar afgrænsning mellem dem fordi de forskellige lag kan ligge på forskellige maskiner på netværket. To-tier klient-server arkitektur. To-tier klient server arkitekturer kan have 2 former: 1. Tynde klienter Klient-server netværk Lagdelt applikation Al databehandling, og applikationslogik ligger på serveren. Klienten er udelukkende ansvarlig for præsentationslogik. Fordele: Nemt at vedligeholde når applikationslogik og data er samlet på serveren Ulemper: Stor belastning på serveren og netværket. Dette kan give problemer med skalerbarhed og systemets ydelse. Datamatikeruddannelsen forår/efterår 2006 Side 51 av 73

52 2. Tykke klienter Serveren er udelukkende ansvarlig for databehandling og databaseacces. Softwaren på klienten står for applikationslogik og præsentation. Fordele: Mindre belastning på serveren og netværket. Ulemper: Større ressourceforbrug til systemadministration. Hvis software skal opgraderes på klienten, skal hver eneste klient på netværket opgraderes. En ulempe med 2-tier klient-server systemer, er at de 3 logiske lag, præsentationslaget, applikationslaget og databehandlingslaget er placeret på 2 computer systemer, klienten og serveren. Tre-tier klient-server arkitektur. Her er præsentationslaget, applikationslaget og databehandlingslaget tre logisk separate processer der kan køre på hver sine processorer. Denne opdeling gør systemet lettere at vedligeholde og udvide, fordi man kan tilføje processorer i takt med øget behov for ydelse og fordi det er lettere at udskifte komponenter i systemet. I nogle tilfælde er det hensigtsmæssigt at Tre tier systemer. opdele systemet i flere lag end tre, multi-tier arkitektur. Dette kan være hvis systemet skal hente data fra flere databaser, hvor man har en integrationserver, der henter data fra databaseserverne, og får dem til at fremstå som én server. Tre-tier og multi-tier systemer der distribuerer applikationslogikken over flere processorer, er lettere at vedligeholde end to-tier systemer. Applikationslogikken bliver let at opgradere, fordi den er centralt placeret. Arkitektur Applikationer To-tier klient-server med tynde klienter Gamle systemer hvor det er upraktisk at adskille applikationslaget og databehandlingslaget. Beregningstunge applikationer. f.eks. kompilere, med få eller ingen databasetransaktioner. Dataintensive applikationer, browsing og forespørgsler, med lille eller ingen applikationslogik. To-tier klient-server med tykke klienter Applikationer hvor applikationslogikken udføres af tredjeparts software, f.eks regneark, på klienten. Tynde og tykke klienter Applikationer hvor beregningstung behandling af data (Visualisering) anvendes. Datamatikeruddannelsen forår/efterår 2006 Side 52 av 73

53 Applikationer med stabile faciliteter for brugeren, i et miljø med godt fungerende vedligeholdelse af systemet. Tre-tier eller multi-tier Store applikationer med flere hundrede eller tusinde klienter. Arkitekturer med distribuerede objekter I en klient-server arkitektur, skiller man mellem klienter og servere. Klienter benytter sig af tjenester på en server, og servere kan optræde som klienter, når de benytter tjenester på andre servere. Denne model kan imidlertid være en begrænsning, når man skal bestemme hvor en tjeneste skal placeres. Klient-server modellen kræver desuden planlægning, når systemet skal udvides. Applikationer hvor både data og applikationen let kan udskiftes. Applikationer der anvender data og applikationslogik fra flere kilder I en arkitektur med distribuerede objekter, er objekter den grundlæggende enhed, sammen med de tjenestene objektene tilbyder. Objekter kan placeres på en hvilken som helst maskine i netværket, og stilles til rådighed for andre objekter via en middleware i form af en object-request-broker (orb). Dennes rolle er at tilvejebringe en generel grænseflade for adgang til alle systemets objekter. Orb tilbyder også tjenester der gør det muligt at tilføje og fjerne objekter fra systemet. Fordele ved denne model: 1. Systemudviklerne kan udsætte beslutninger om hvilke tjenester der skal implementeres og hvordan de kan tilgås. Objekter der tilbyder tjenester kan placeres hvor som helst i systemet. Derfor gøres begreberne tynde og tykke klienter irrelevante. 2. Åben systemarkitektur, der gør det muligt at tilføje og fjerne tjenester efter behov. 3. Systemet bliver fleksibelt og skalerbart. Flere instanser af en tjeneste kan placeres på flere maskiner, for at fordele belastningen. Nye objekter kan tilføjes for at håndtere større belastning. 4. Det er muligt at rekonfigurere systemet dynamisk, mens systemet kører, og objekter kan flyttes over netværket mens systemet kører. Dette kan være nyttigt hvis der er fluktuerende krav til systemets tjenester. Anvendelse: Distribuerede objekter Logisk model til at strukturere og organisere systemet. Funktionalitet betragtes som tjenester, og kombinationer af tjenester. Disse tjenestene beskrives som grovkornede forretningsobjekter, der tilbyder domænespecifikke tjenester, f.eks lagerstyring, kundekommunikation, varebestilling etc. Denne modellen kan realiseres som en implementeringsmodel. Kan anvendes til at implementere klient-server systemer. Den logiske model af systemet, Datamatikeruddannelsen forår/efterår 2006 Side 53 av 73

54 er en klient-server model, hvor både klient og server realiseres som objekter der kommunikerer over en bus. Dette gør det let at ændre systemets konfiguration, f.eks. fra en 2- tier til 3-tier system. I dette tilfælde vil serveren blive delt op i flere objekter. Eksempler på systemer: Data mining system, der leder efter sammenhænge i kundernes indkøb. Om f.eks købere af baby mad også køber et specielt tapet. I dette eksempelet, kan hver database blive indkapslet i et objekt, med en interface der giver læseadgang til sine data. Integrator objekter oprettes for hver sammenhæng man vil undersøge Data mining system med distribuerede objekter Visualiseringsobjekter anvender data fra integratorobjektene og præsenterer dataene i rapporter. Fordele ved denne arkitektur til dette system: Ulemper: CORBA Lettere at modellere et system der ikke består af konkrete tjenester. Databaser kan let tilføjes til systemet. Nye sammenhænge kan let tilføjes ved at tilføje integratorobjekter. Systemer der anvender distribuerede objekter er vanskelige at designe. Hvor det er let at se for sig forholdet mellem klient og server, kan det være vanskeligt at tænke sig tjenester i form af fleksible objekter. Manglende erfaringer med denne arkitektur. CORBA er en standard for middleware, der er udviklet af Object Management Group (OMG). Denne model for distribution af objekter består af: 1. Applikationsobjekter der er designet og implementeret i applikationen. Interface Definition Language anvendes til at indkapsle disse objekter. 2. Standard objekter der er defineret af OMG for specielle domæner, som finans, forsikring, e- handel osv. Object Request Broker (ORB), CORBA, kommunikation mellem objekter håndterer anmodninger om tjenester. ORB lokaliserer det objekt der tilbyder tjenesten, sender anmodningen og returnererresultatet. 3. Grundlæggende CORBA tjenester der står for kommunikation mellem objekter. Der tilbydes en række generelle tjenester, såsom mappehåndtering, transaktions tjenester og databaseacces. Datamatikeruddannelsen forår/efterår 2006 Side 54 av 73

55 4. Horisontale CORBA faciliteter, som systemadministration etc. Horisontal anvendes i den betydning at disse faciliteter kan anvendes på tværs af domænerne, og derfor kan anvendes i andre applikationer. CORBA definerer ca 15 tjenester, der er nødvendige i distribuerede systemer. Dette omfatter navneog udvekslingstjenester, underrettelse om hændelser og transaktionstjenester. Distribuerede netværk i organisationer Peer-to-peer netværk Peer-to-peer netværk er enten decentraliserede, eller semicentraliserede. I en decentralt netværk er noderne delt ind i grupper, eller lokaliteter, hvor den ene node i gruppen håndterer de andres kommunikation ud på netværket. Fordele ved dette systemet er at det er robust, fordi der er så mange redundante kommunikationsveje. Det semicentraliserede p2p netværk har en server der overvåger netværket. Når en node sender en forespørgsel ud på netværket, formidler serveren kontakt mellem noderne, hvorefter kommunikation er direkte mellem de 2 noder. Decentraliseret p2p netværk Web tjenester 1. Tjenester kan udbydes af en hvilke som helst udbyder. Hvis disse lever op til bestemte standarder, kan de anvendes i applikationer der integrerer ydelser fra en lang række tjenester. 2. Udbyderen publicerer informationer om tjenesten, så alle autoriserede brugere kan tilgå dem. 3. Applikationer kan udsætte binding til tjenester til de udbydes. Derfor kan en applikation ændre service udbyder mens applikationen kører. 4. Brugeren betaler efter forbrug. Dermed kan dyre moduler eller subsystemer erstattes med en webtjeneste. 5. Applikationer kan gøres mindre, hvilket specielt er vigtig for indebygde systemer. 6. Applikationer kan gøres fleksible, fordi de kan bindes til tjenester efter behov. Semi centraliseret p2p netværk Arkitektur til web tjeneste Der er tre grundlæggende standarder, der gør det muligt at kommunikeremed web-tjenester: 1. SOAP Simple Object Access Protocol, der definerer organiseringen af struktureret dataudveksling mellem web-tjenester. 2. WSDL Web Services Definition Language, Protokol der definerer hvordan interfaces skal repræsenteres. 3. UDDI Universal Descriptive, Discovery and Integration. Standard der definerer hvordan information om tjenester skal formatteres. Datamatikeruddannelsen forår/efterår 2006 Side 55 av 73

56 Applikations arkitekturer Applikationer har til formål at opfylde et firma eller en organisations forretningsbehov. Nogle behov er fælles for alle, såsom personale- og lønssystemer. Der er også fælles behov og problemstillinger for firmaer og organisationer indenfor det samme domæne. Der er lavet 4 generiske arkitekturer, der omfatter de fleste forrebehov der stilles til applikationer. Disse kan anvendes som et udgangspunkt for design af egne systemer, huskeliste, udgangspunkt for at organisere arbejdet i udviklerteamet eller simpelthen som et udgangspunkt for diskussioner i teamet. Data behandlingsystemer Dette er applikationer der er data-drevet. De behandler data i batches, uden eksplicit indblanding fra brugerne. De anvendes hvor nogle simple beregninger skal udføres på store mængder data, som f.eks. lønsystemer eller faktureringssystemer. De er bygget op af 3 hovedkomponenter: Input komponent Denne kan yderligere deles op i en input komponent, validering af input data og en komponent der placeres data i en kø til processering. Processeringkomponent Denne henter data fra input komponenten, eller køen behandler dem og sender resultatene videre, enten til systemet i form af nye data records eller de kan blive lagt i en kø til systemets printer. Dette gøres af og til i systemets database, og af og til i et separat program/subsystem. Output komponent Output komponenten læser data records fra en kø, formatterer dem og sender dem videre, f.eks til printerkøen eller til databasen i form af nye database-records. Et sådant system, kan præsenteres i et procesdiagram, hvor inddata er vist som rektangler og processer er vist som rektangler med runde hjørner. Diagrammet viser datastrømmen, og skal læses fra venstre til højre. Lønsystem baseret på proces behandling Datamatikeruddannelsen forår/efterår 2006 Side 56 av 73

57 Transaktions behandlingsystemer Transaktions behandlingsystemer er designet til at håndtere forespørgsler efter data i en database. Et eksempel kan være et pengeautomatsystem, hvor kunden kan hæve penge og spørge efter oplysninger om sin konto, som f.eks. saldo. Transaktionssystemer er vanligvis interaktive systemer, der behandler asynkrone anmodningen om transaktioner. Den input-processering-output struktur man ser i data behandlingsystemer, ser man også i transaktions behandlingsystemer. I et system med pengeautomater, er subsystemene for input og output placeret i pengeautomaten, og subsystemer for processering og databaseacces placeret i bankens server. Informationsystemer og systemer til ressourcestyring Alle systemer der interagerer med en delt database, kan kaldes transaktions behandlingsystemer. Informationsystemer Informationsystemer tillader kontrolleret adgang til en database. Dette kan være biblioteksystemer, et system der viser afgangstider, eller et hospitalsystem med patientdata. Et informationsystem kan repræsenteres i en lagdelt arkitektur. Alle informationssystemer har tre hovedkomponenter: 1. Logind komponenten, der identificerer og godkender brugeren. Rettighedskontrol. 2. Søgningsbehandler, der giver faciliteter til søgning i databasen. 3. Udskriftsbehandler, der formatterer data for udskrift, og sender dem til udskriftskøen. Komponenter til at hente og ændre i data: Transaktions behandlingsystem i lagdelt arkitektur 1. Distribuerede søgninger, der søger gennem systemets databaser i henhold til søgekriterierne. En liste over systemets databaser vedligeholdes i en index komponent. 2. Hent dokumenter. Denne komponent henter de dokumenter der blev fundet 3. Rettighedstyring er en komponent der håndterer rettigheder til de fundne data, f.eks copyright. Denne kan f.eks. forbyde mere end en udskrift pr. bruger. 4. Kontering er en komponent der håndterer evt kontering af betaling for de returnede data, eller i et biblioteksystem at udlån bliver registreret på låners konto. Datamatikeruddannelsen forår/efterår 2006 Side 57 av 73

58 Ressource allokeringssystemer Et ressource allokeringsystem er et informationsystem, der også styrer tildelingen af begrænsede ressourcer til brugerne. Dette kan være et biblioteksystem, hvor der kun er et bestemt antal bøger. Når disse er udlånt, må lånere vente til en af bøgerne returneres til biblioteket. Ressource allokeringsystemer, omfatter også tids planlægningsystemer eller luft-trafik styresystemer. Udover de komponenter man finder i et informationssystem, har ressource allokeringsystemer følgende komponenter: 1. En ressource database, der har oversigt over tildelte ressourcer. Ressource allokeringssystem i lagdelt arkitektur 2. Et regelsæt, der bestemmer hvordan ressourcer skal fordeles. I et biblioteksystem, kan dette være maksimal lånetid eller antal bøger pr. låner. 3. En ressource styringskomponent, der gør det muligt at tilføje eller fjerne ressourcer. 4. Et ressource tildelingssystem, som f.eks. kan være en bekræftelse eller underrettelse via e- mail. Et ressource allokeringssystem kan implementeres som et web baseret system, hvor bruger grænsefladen genereres af en web server. Dette gælder f.eks. e-handels applikationer, hvor brugeren har adgang til systemet via internettet. Event behandlingsystemer Dette er systemer der responderer på hændelser i systemets miljø eller i brugergrænsefladen. En vigtig egenskab ved et event behandlingsystem er at hændelser ikke kan forudsiges. Dette skal systemet kunne håndtere. Event håndteringssystemer, anvendes daglig i tekstbehandlere, præsentationsprogrammer eller billed editorer. Systemet fanger og fortolker hændelser, omsætter disse til kommandoer, der bliver udført af systemet. Et eksempel kan være at markere et ord med musen, højreklikke og vælge Kopier. Events behøver dog ikke at komme fra brugergrænsefladen, men kan også komme fra f.eks. følere der er koblet til systemet. Disse kan udløse en event hvis måleniveauet kommer over eller under en bestemt værdi. Eftersom sådanne real-tids systemer, skal respondere på events der ikke kan forudses, og indenfor et kort tidsinterval, er de ofte implementeret som mange samtidige processer. Editeringsystemer er real-tids event baserede systemer, der alle har nogle fælles egenskaber: 1. En bruger systemer 2. Skal respondere hurtig på hændelser som f.eks slet eller vælg. Derfor placeres data i systemets RAM. Dette fører til tab af data hvis systemet går ned. Derfor må disse systemer kunne håndtere fejlsituationer, så systemet ikke går ned. 3. Editeringsessioner varer normalt længer end sessioner med transaktioner. Dette indebærer en højere risiko for tab af data pga. system nedbrud. Derfor har disse systemer ofte faciliteter til at gemme data automatisk. Datamatikeruddannelsen forår/efterår 2006 Side 58 av 73

59 Komponenter 1. Skærm Overvåger skærmen, og opdager hændelser her. Disse hændelser sendes til modulet til hændelseshåndtering, sammen med koordinatene på skærmen. 2. Hændelseshåndtering Dette objekt startes af at det modtager en hændelse fra skærm objektet. Hændelsen fortolkes, og omdannes til en kommando der sendes vider til objektet der håndterer kommandoer. 3. Kommando Dette objektet modtager en kommando, og kalder den tilknyttede metode i editeringsdata objektet. 4. Editeringsdata Når en metode kaldes her, ændres editeringsdata eller systemets status. Generisk arkitektur for en eventbaseret editor Derefter kaldes opdaterings metoden i Display objektet, så ændringene vises. 5. Tillægsdata Mange editorer inkluderer meta data, der holder oplysninger om formattering, fonter etc. Metoder til stavekontrol findes også i dette objekt. 6. Filsystem Dette er et objekt til at åbne og gemme filer. Dette kan være rene data eller data og metadata. Mange editorer har faciliteter til at gemme automatisk efter tidsintervaller. 7. Display Dette objekt har til opgave at organisere det der vises på skærmen, både data og systemets status. Dette objekt kalder Skærm objektets metode til opdatering. Sprogbehandlingsystemer Sprogbehandlingsystemer tager et ægte eller kunstig sprog som input, fortolker dette, og giver en anden repræsentation som output. Typiske eksempler på dette er kompilatorer, der læser et høj-niveau programmeringsprog og omdanner dette til maskinkode. Det kan også være en XML fortolker, der læser en XML fil, og omdanner indholdet til instruktioner eller data. Endelig kan det dreje sig om systemer der oversætter fra et sprog til et andet. Komponenter 1. En leksikal analyseringsenhed, der oversætter det oversatte sprog til en intern form. Abstrakt arkitektur til et sprogbehandlingsystem 2. En symbol tabel der har oversigt over entiteters navne (Variabelnavne, klassenavne osv.) der anvendes i det sprog der skal oversættes. 3. En syntaks analyseringsenhed, der kontrollerer syntaksen til det sprog der skal oversættes. Der anvendes en defineret grammatik til sproget, og et syntaks træ bliver bygget. 4. Et syntaks træ, der er en intern struktur til det program der kompileres. 5. En semantisk analyseringsenhed der anvender informationer fra syntaks træet og symboltabellen til at checke syntaksen i input teksten. Datamatikeruddannelsen forår/efterår 2006 Side 59 av 73

60 6. En kodegenerator der gennemløber syntaks træet og generer abstrakt maskinkode. Arkitektoniske modeller Komponentene i et sprogbehandlingsystem kan organiseres i 2 modeller. Data-flow model Denne model er almindelig anvendt, og er effektiv i miljøer hvor der anvendes batch-processering. Denne model er mindre effektiv, hvis kompileren skal integreres med en editor. Repositorie baseret model Med denne model, kan en kompiler integreres i et Data-flow model af kompiler sæt med programmeringsværktøjer. Dette kan være en editor, en komponent der formatterer til udskrift, en komponent der optimerer koden osv. Alle værktøjer har adgang til data repositoriet. På denne måden kan editoren og udskriftskomponenten anvende data fra repositoriet til at give en optimal fremstilling af koden. Nye værktøjer kan desuden let tilføjes. Model af kompiler som data repositorie Datamatikeruddannelsen forår/efterår 2006 Side 60 av 73

Succesfuld implementering af automatiseret test

Succesfuld implementering af automatiseret test Succesfuld implementering af automatiseret test Forudsætningerne og faldgruberne John Fodeh john.fodeh@hp.com 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject

Læs mere

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. It-håndbogen Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste

Læs mere

Sammenligning af metoder

Sammenligning af metoder Sammenligning af metoder Hvorfor sammenligne? Den ideelle metode Generelle frameworks (NIMSAD/Andersen) Wood-Harper framework til sammenligning Problemer med sammenligning af metoder Hvorfor sammenligne?

Læs mere

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter

Læs mere

Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test

Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test Struktureret Test og Værktøjer... 1 Appendiks til bogen Struktureret Test... 1 1. Definition og formål... 2 2. Kategorisering... 2 2.1

Læs mere

Agil-model versus V-model set i lyset af en testers dilemmaer

Agil-model versus V-model set i lyset af en testers dilemmaer Agil-model versus V-model set i lyset af en testers dilemmaer 1 Præsentation Foredragsholder Ane Clausen: Cand.Scient i Datalogi Københavns Universitet, Danmark Gift, 3 børn 25 års erfaring med IT: 12

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur Cloud i brug Migrering af Digitalisér.dk til cloud computing infrastruktur 02 Indhold > Executive Summary............................................................... 03 Digitaliser.dk.....................................................................

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens:

Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens: DS/ISO 31000 Risikoledelse ISO 31000 - Risikoledelse Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens: overordnede

Læs mere

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen Nye testteknikker fra ISTQB - direkte fra hylderne Ole Chr. Hansen TestExpo 29. Januar 2015 Præsentation Ole Chr. Hansen Managing Consultant Fellow SogetiLabs Global Innovation Team Blog - http://ochansen.blogspot.com

Læs mere

Introduktion til projekter

Introduktion til projekter Introduktion til projekter v. 1.0.3 Introduktion I dette materiale ser vi overordnet på, hvad projekter egentlig er, hvordan de er skruet sammen og hvilke begreber, som relaterer sig til projekter. Vi

Læs mere

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste WTF? Thomas Schou-Moldt, Miracle A/S (siden 2008) Arkitekt, udvikler, teknisk projektleder, mv. Indtil videre afsonet lidt over 20 år i branchen, ingen udsigt til prøveløsladelse tsm@miracleas.dk, 5374

Læs mere

DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN

DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN Sikkerhed og Revision 2013 Martin Falk-Hansen & Svend M Er sikkerhed og revision et problem i agil udvikling? Og i givet fald hvorfor?

Læs mere

Infoblad. ISO/TS 16949 - Automotive

Infoblad. ISO/TS 16949 - Automotive Side 1 af 5 ISO/TS 16949 - Automotive Standarden ISO/TS 16949 indeholder særlige krav gældende for bilindustrien og for relevante reservedelsvirksomheder. Standardens struktur er opbygget som strukturen

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

Objektorienterede metoder

Objektorienterede metoder Objektorienterede metoder Gang 12. Kvalitet i større systemer Evt.: Ekstremprogrammering (XP) Dette materiale er under Åben Dokumentlicens, se http://www.sslug.dk/linuxbog/licens.html projektopgaven i

Læs mere

Dynamisk hverdag Dynamiske processer

Dynamisk hverdag Dynamiske processer Dynamisk hverdag Dynamiske processer Verden og hverdagen er kompleks og i konstant forandring - og derfor skal den måde vi arbejder med projekter og implementering være enkel og forandringsparat. Agil

Læs mere

- Erfaringer med implementering af MES løsninger. SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller

- Erfaringer med implementering af MES løsninger. SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller - Erfaringer med implementering af MES løsninger SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller DC Projektorganisation Arne J. Boye-Møller, Produktions IT, Projektafdelingen

Læs mere

Styring af testmiljøer almindelig god praksis

Styring af testmiljøer almindelig god praksis White paper Styring af testmiljøer almindelig god praksis Søren Beyer Nielsen Ph.D., M.Sc. Pragmatic Consult A/S v. 1.2 Pragmatic Consult A/S Stadagervej 42 2730 Herlev Danmark Tel: 44 92 23 77 Fax: 44

Læs mere

Agil test tilgang - erfaringer fra projekter

Agil test tilgang - erfaringer fra projekter Agil test tilgang - erfaringer fra projekter af Michael Roar Borlund November 2011 Image Area Agenda Introduktion Agil test Fremtidsvision Agil test tilgang Agil opbygning i QC Resumé og Spørgsmål 2 Introduktion

Læs mere

Supply Chain Netværk Design

Supply Chain Netværk Design Supply Chain Netværk Design Indsigt og forretningsværdi Den Danske Supply Chain Konference København den 8. juni 2016 Formålet med i dag Give en generel forståelse af hvad supply chain netværk design er

Læs mere

Idékatalog Planlægning og brug af test i statslige it-projekter

Idékatalog Planlægning og brug af test i statslige it-projekter Idékatalog Planlægning og brug af test i statslige it-projekter Januar 2014 INDHOLD 1. INDLEDNING...1 2. TYPER AF TEST...2 3. PLANLÆGNING AF TEST I FASERNE...6 3.1 IDÉFASEN...6 3.2 ANALYSEFASEN...7 3.3

Læs mere

Ud af krisen. Software på tværs, 15. juni 2009

Ud af krisen. Software på tværs, 15. juni 2009 Ud af krisen Software på tværs, 15. juni 2009 Om Ative Agile udvikling og rådgivning Klassisk udviklingsmodel Krav Design Ændrer sig Implementering Tager for lang tid Springes over Mareridt Test Deployment

Læs mere

Agile holdninger, ved Jesper Nielsen

Agile holdninger, ved Jesper Nielsen Agile holdninger, ved Jesper Nielsen AAU april 2007 Historien om Henrik der gik til styregruppemøder Færdig med fase 1, brugt for mange timer. Grundig omkring X Færdig med fase 2, også brugt for mange

Læs mere

Projektets karakteristika

Projektets karakteristika Projektets karakteristika Gruppeopgave Projektledelse DTU 1999 Projektets karakteristika Formål At give en karakteristik af projektets stærke og svage sider, som kan lægge til grund for den senere mere

Læs mere

Uge 5.3: (Search,) Select & implement and development methods

Uge 5.3: (Search,) Select & implement and development methods Innovationsprocesser Uge 5.3: (Search,) Select & implement and development methods A A R H U S U N I V E R S I T E T Department of Computer Science 1 Innovation & ICT development *** Innovation *** * ***

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 Side 1 af 8 Så ligger det færdige udkast klar til den kommende version af ISO 9001:2015. Standarden er planlagt til at blive implementeret medio september 2015. Herefter har virksomhederne

Læs mere

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev Branchens perspektiv på den gode indkøbs organisation En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 7/11-2016 Release-styring Hjælpe værktøjer Kvalitets sikring Leverandør kontrakter

Læs mere

Bring lys over driften af belysningen

Bring lys over driften af belysningen Bring lys over driften af belysningen CityTouch LightPoint Asset Management system for belysning CityTouch LightPoint / Asset Management 3 Velkommen til den nye intelligens inden for belysning. Professionel

Læs mere

Alle børn har ret til en skole med en kultur for kvalitetsudvikling, der er baseret på synergi mellem interne og eksterne evalueringsprocesser.

Alle børn har ret til en skole med en kultur for kvalitetsudvikling, der er baseret på synergi mellem interne og eksterne evalueringsprocesser. Alle børn har ret til en skole med en kultur for kvalitetsudvikling, der er baseret på synergi mellem interne og eksterne evalueringsprocesser. Denne deklaration følger den europæiske vision om, at alle

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

Accelerate Agil implementering fra EG NeoProcess

Accelerate Agil implementering fra EG NeoProcess Accelerate Prioritise Sprint Accelerate Agil implementering fra EG NeoProcess EG NeoProcess www.eg-neoprocess.dk Accelerate den agile implementering Verden og hverdagen er kompleks og i konstant forandring

Læs mere

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Procedurer for styring af softwarearkitektur og koordinering af udvikling LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode

Læs mere

Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik

Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik En referencelinie er en koordineret og veldefineret tilstand i et projekt,

Læs mere

Audit beskrivelser for PL

Audit beskrivelser for PL 3-4-1 V01 3-4-1 V02 3-4-1 V03 3-4-1 V04 3-4-1 V05 Er der etableret et system til regelmæssig kontrol af processerne? Punktet er opfyldt, hvis der er en synlig regelmæssig måling for processen med acceptgrænser.

Læs mere

PRINCE2 med tusind ord. Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd. AXELOS.com. The Stationery Office 2011

PRINCE2 med tusind ord. Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd. AXELOS.com. The Stationery Office 2011 PRINCE2 med tusind ord Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd AXELOS.com White Paper September 2011 Indhold 1 Hvad er PRINCE2? 3 2 Fordele ved PRINCE2 3 3 Principper

Læs mere

High performance maksimér potentialet. En måling er bedre end 100 mavefornemmelser. Per Hartlev ph@whitebox.dk 30/9-2015

High performance maksimér potentialet. En måling er bedre end 100 mavefornemmelser. Per Hartlev ph@whitebox.dk 30/9-2015 High performance maksimér potentialet En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 30/9-2015 Release-styring Hjælpe værktøjer Kvalitets sikring Leverandør kontrakter Kurser Opgave

Læs mere

Lær jeres kunder - bedre - at kende

Lær jeres kunder - bedre - at kende Tryksag 541-643 Læs standarden for kundetilfredshedsundersøgelse: DS/ISO 10004:2012, Kvalitetsledelse Kundetilfredshed Overvågning og måling Vejledning I kan købe standarden her: webshop.ds.dk Hvis I vil

Læs mere

Vurdering af kvalitet en note af Tove Zöga Larsen

Vurdering af kvalitet en note af Tove Zöga Larsen Vurdering af kvalitet en note af Tove Zöga Larsen Kvalitet... 2 Test... 2 Hvordan finder man testdata?... 2 Dokumentation af test... 3 Review... 3 Vurderingskriterier... 3 Gennemførelsen af et review...

Læs mere

Omfang af beføjelser til at træffe beslutninger (for eksempel anbefaling eller implementering)

Omfang af beføjelser til at træffe beslutninger (for eksempel anbefaling eller implementering) Skema til brug ved oprettelse af et team Formålet med teamet Forventede aktiviteter Tilsigtede resultater Tilgængelige ressourcer Begrænsninger Nødvendige færdigheder og kvaliteter Forventede teammedlemmer

Læs mere

I denne rapport kan du se, hvordan du har vurderet dig selv i forhold til de tre kategoriserede hovedområder:

I denne rapport kan du se, hvordan du har vurderet dig selv i forhold til de tre kategoriserede hovedområder: - Mannaz Ledertest Dette er din individuelle rapport, som er baseret på dine svar i ledertesten. I rapporten får du svar på, hvilke ledelsesmæssige udfordringer der er de største for dig. Og du får tilmed

Læs mere

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA 10 gode råd af konsulent Morten Korsaa, DELTA Vælg den rette model SKI rammekontrakten giver mulighed for at bruge to udviklingsmodeller den klassiske og den nye. Dit valg er afgørende for succes. Den

Læs mere

Innovationens Syv Cirkler

Innovationens Syv Cirkler Innovationens Syv Cirkler Med denne gennemgang får du en kort introduktion af Innovationens Syv Cirkler, en model for innovationsledelse. Dette er en beskrivelse af hvilke elementer der er betydende for

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

Usability. 2 web sites til gennemsyn

Usability. 2 web sites til gennemsyn Usability 2 web sites til gennemsyn Usability ISO 9241-11 (1998) Det omfang hvormed et produkt kan anvendes af brugere til at opnå mål på en effektiv, virkningsfuld og tilfredsstillende måde REQUIREMENTS

Læs mere

The LEGO Journey: Building an agile test foundation one brick at the time. Casper Gaardland Englund. Stephan Hjelmdal Nielsen. 2013 The LEGO Group l

The LEGO Journey: Building an agile test foundation one brick at the time. Casper Gaardland Englund. Stephan Hjelmdal Nielsen. 2013 The LEGO Group l The LEGO Journey: Building an agile test foundation one brick at the time Casper Gaardland Englund Stephan Hjelmdal Nielsen 2013 The LEGO Group l TestExpo 15 Hvem er vi? Casper Englund Uddannet datamatiker

Læs mere

Semesterbeskrivelse cand. it uddannelsen i it-ledelse 2. semester.

Semesterbeskrivelse cand. it uddannelsen i it-ledelse 2. semester. Semesterbeskrivelse cand. it uddannelsen i it-ledelse 2. semester. Semesterbeskrivelse Oplysninger om semesteret Skole: Statskundskab Studienævn: Studienævn for Digitalisering Studieordning: Studieordning

Læs mere

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen IT Service Management (ITIL) i en agil verden Lars Zobbe Mortensen Om Lars It service management konsulent ITIL ekspert og underviser Projekt leder PRINCE2 agile og underviser Tidligere leder for udviklings

Læs mere

Bilag 9, Kvalitetssikring

Bilag 9, Kvalitetssikring Bilag 9, Kvalitetssikring Version Ændringer Dato 2.1 Ændret i: 06-02-2014 - Punkt 1 - Punkt 2 - Krav 9.1 - Krav 9.2 - Krav 9.3 - Krav 9.5 - Krav 9.6 - Krav 9.7 - Krav 9.8 - Tilføjet krav 9.14 - Tilføjet

Læs mere

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling Java og JEE 1 2 Udfordringer og problemstillinger En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling 3 Generelt om Java og JEE 4 Generelt, I Man undervurderer hvor mange

Læs mere

CCS Formål Produktblad December 2015

CCS Formål Produktblad December 2015 CCS Formål Produktblad December 2015 Kolofon 2015-12-14

Læs mere

IT projekt. sæt et mål og nå det med omtanke!

IT projekt. sæt et mål og nå det med omtanke! IT projekt sæt et mål og nå det med omtanke! Det overordnede FORMÅL med dias-showet er at fortælle hvordan vi gennemfører IT projekter med succes ved hjælp af Microsoft Solutions Framework MSF modeller:

Læs mere

Arduinostyret klimaanlæg Afsluttende projekt informationsteknologi B

Arduinostyret klimaanlæg Afsluttende projekt informationsteknologi B Arduinostyret klimaanlæg Afsluttende projekt informationsteknologi B Udarbejdet af: Mathias R W Sørensen, klasse 3.4 Udleveringsdato: 02-03-2012 Afleveringsdato: 11-05-2012 IT-vejleder: Karl G. Bjarnason

Læs mere

Hvordan kan en ernæringsprofessionel indsamle data til ernæringsvurdering?

Hvordan kan en ernæringsprofessionel indsamle data til ernæringsvurdering? SNAPShot. Trin 1. Ernæringsvurdering Hvad er formålet med ernæringsvurdering? Systematisk indsamling, analyse og fortolkning af data fra klienten, pårørende, andre omsorgspersoner og behandlere med henblik

Læs mere

Mobiltest typiske udfordringer og deres løsninger

Mobiltest typiske udfordringer og deres løsninger Mobiltest typiske udfordringer og deres løsninger Side 1 af 6 Introduktion Ved test af mobile løsninger, er det vigtigt at man forholder sig til en række faktorer og udfordringer, ud over dem man kender

Læs mere

Pain Treatment Survey

Pain Treatment Survey Pain Treatment Survey Projektoplæg Projektoplæg til fælles udviklingsprojekt, i samarbejde mellem KLONK og smerteeksperter fra Sverige, Danmark og Norge www.klonk.dk Indholdsfortegnelse Baggrund... 2 Idé...

Læs mere

Iterativ og Agil udvikling

Iterativ og Agil udvikling Iterativ og Agil udvikling 1 2 Udfordringer i hverdagen En liste over de udfordringer man står overfor ved implementering af iterativ og agil udvikling. 3 Udfordringer med Iterationer 4 Iterationer, I

Læs mere

Systematisk testning af program til udregning af mellemskat

Systematisk testning af program til udregning af mellemskat Systematisk testning af program til udregning af mellemskat Indledning I denne opgave vil vi definere passende cases til systematisk black-box test af et program til beregning af mellemskat. Vi har valgt

Læs mere

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4 IT opgave Informationsteknologi B Vejleder: Karl Navn: Devran Kücükyildiz Klasse: 2,4 Dato:03-03-2009 1 Indholdsfortegnelse 1. Indledning... 3 2. Planlægning... 3 Kommunikationsplanlægning... 3 Problemstillingen...

Læs mere

Lean Startup Introduktion

Lean Startup Introduktion Lean Startup Introduktion Introduktion til Lean Startup Lean Startup tager Lean produktionsmetoder, som er udviklet af Toyota i Toyota Production System og anvender dem til processen med at starte en virksomhed.

Læs mere

Aktuel driftsstatus for IndFak

Aktuel driftsstatus for IndFak Aktuel driftsstatus for IndFak Side 1 af 5 Der er på nuværende tidspunkt 72 institutioner, som anvender IndFak. Der er fortsat forskellige driftsmæssige problemer samt uhensigtsmæssigheder i systemet.

Læs mere

Jobanalyserapport. for. Salgskonsulent (demo) 14-10-2008. Sidst ændret: 14-10-08

Jobanalyserapport. for. Salgskonsulent (demo) 14-10-2008. Sidst ændret: 14-10-08 Jobanalyserapport for Salgskonsulent (demo) 14-10-2008 Sidst ændret: 14-10-08 Profiles International Denmark Fossgårdsvej 32 2720 Vanløse +45 23740000 Copyright 1999-2003 Profiles International, Inc. 1

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Ledelse og management

Ledelse og management Kompetenceramme Kompetencer inden for Ledelse og management Kompetenceområdet for ledelsen består af de kompetencer, der er relateret til adfærd med fokus på at lede, motivereog udvikle menneskelige ressourcer

Læs mere

Uddelegering? Du er dig eller din leder eller en anden leder

Uddelegering? Du er dig eller din leder eller en anden leder Uddelegering? Du er dig eller din leder eller en anden leder Arbejder du ofte med opgaver, som kun du kan udføre? Tør du uddelegere? Eller er du bange for at miste kontrollen? Har du ikke tid til at uddelegere?

Læs mere

Hans Hansen STANDARD RAPPORT. Adaptive General Reasoning Test

Hans Hansen STANDARD RAPPORT. Adaptive General Reasoning Test Adaptive General Reasoning Test STANDARD RAPPORT Dette er en fortrolig rapport, som udelukkende må anvendes af personer med en gyldig certificering i anvendelse af værktøjet AdaptGRT fra DISCOVER A/S.

Læs mere

Bilag 19: Test af DTT-nettet

Bilag 19: Test af DTT-nettet Bilag 19: Test af DTT-nettet Indholdsfortegnelse 1. Sammendrag...3 2. Testlaboratorium...4 3. Acceptanstests...5 4. Systemtests...5 5. Stabilitetstests...6 6. Smartkorttests...6 7. Test af overensstemmelse

Læs mere

Side 1 af 5 20 artikler. Artikler Tilbage til liste Ny søgning Flere data Layout Gem som fil Udskriv målgruppe Generel definition: gruppe, hvis medlemmer en indsats er rettet imod Formidlingsversion: En

Læs mere

Et forløb kan se således ud, fordelt på moduler, emner og formål: Modul 1

Et forløb kan se således ud, fordelt på moduler, emner og formål: Modul 1 3 GDJRJLVNYHMOHGQLQJIRU3URMHNWNRRUGLQDWRUIRU8GYLNOLQJ6DPVSLORJ 5HVXOWDWHU %HJUXQGHOVHIRUXGGDQQHOVH Projekter er blevet almindelige i danske virksomheder. Hvor projekter før i tiden var af mere teknisk

Læs mere

PRINCE2 2009. Projekt & Program Forum - 21-05-2010 1

PRINCE2 2009. Projekt & Program Forum - 21-05-2010 1 PRINCE2 2009 Hvad er nyt? Projekt & Program Forum - 21-05-2010 1 Baggrund for ny version Projekt & Program Forum - 21-05-2010 2 Baggrund Refresh Project startede i 2006 Mere end 170 organisationer og individer

Læs mere

Generelle lederkompetencer mellemledere

Generelle lederkompetencer mellemledere Generelle lederkompetencer mellemledere Personale- og teamledelse: min. niveau 3 Skaber et godt arbejdsklima gennem information, dialog og involvering Har øje for den enkeltes talenter og ressourcer Sikrer

Læs mere

Jobcentrets VITAS business case

Jobcentrets VITAS business case Jobcentrets VITAS business case Lavet med udgangspunkt i en kommune med 50-80.000 borgere 15. december 2015 Jobcenter business casens indhold Formål med jobcenter business casen og STAR anbefaling Side

Læs mere

Teksten i denne instruktion er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse.

Teksten i denne instruktion er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. BILAG 10 PRØVER Indholdsfortegnelse 1. Prøver... 4 2. Fælles regler for afprøvning... 4 2.1 Afklaringsproces og udarbejdelse af test cases... 4 2.2 Beskrivelse af afklaringsproces og udarbejdelse af test

Læs mere

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt Scope Management ITU 11-09-2013 @janhmadsen Dagsorden Oplægsholder Projektstyring Scope Management i en fælles kontekst Definitioner Scope Management - styring af omfang ved projektets start under projektets

Læs mere

Delaftale 3 Pap-, papir-, glas-, metal- og træaffald

Delaftale 3 Pap-, papir-, glas-, metal- og træaffald Miljøstyrelsens Rammeaftale på affaldsfaglige konsulentydelser og -bistand Bilag 1: Kravspecifikation og anvendelsesområde Delaftale 3 Pap-, papir-, glas-, metal- og træaffald Side 1 af 8 Indholdsfortegnelse

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 8 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

II. Beskrivelse af kandidatuddannelsens discipliner

II. Beskrivelse af kandidatuddannelsens discipliner II. Beskrivelse af kandidatuddannelsens discipliner Særfag 18. Agenter, handlinger og normer (Agents, actions and norms) a. Undervisningens omfang: 4 ugentlige timer i 2. semester. Efter gennemførelsen

Læs mere

Automatisering Af Hverdagen

Automatisering Af Hverdagen Automatisering Af Hverdagen Programmering - Eksamensopgave 10-05-2011 Roskilde Tekniske Gymnasium (Kl. 3,3m) Mads Christiansen & Tobias Hjelholt Svendsen 2 Automatisering Af Hverdagen Indhold Introduktion:...

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Januar 2014 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

DM536. Rapport og debug

DM536. Rapport og debug DM536 Rapport og debug Kilder Vigtig.it (Felix Palludan Hargreaves) http://vigtig.it/dm502/howto_report.pdf http://vigtig.it/blog/teaching/#toc-relevant-tips Peter Schneider-Kamp http://imada.sdu.dk/~petersk/dm536/project2.pdf

Læs mere

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag Hvem er vi? Kursus Introduktion Anne Haxthausen ah@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark 100 studerende med forskellig baggrund: software teknologi It og Kom

Læs mere

Har du mulighed for at bruge dine styrker hver dag på arbejdet?

Har du mulighed for at bruge dine styrker hver dag på arbejdet? Har du mulighed for at bruge dine styrker hver dag på arbejdet? Brug styrkerne og skab vækst og øget engagement 20 % bruger deres styrker hver dag på jobbet Gør du hver dag det - du gør bedst på jobbet?

Læs mere

Harmoni. Med SAP PI. Når tingene går op i en højere enhed. Kort & Godt. January 2012

Harmoni. Med SAP PI. Når tingene går op i en højere enhed. Kort & Godt. January 2012 January 2012 3. årgang, nummer 1 Harmoni Med SAP PI Når tingene går op i en højere enhed Godt nytår! Vi er kommet ind i 2012 med fuld fart, og vi glæder os til et fortsat godt samarbejde med kunder og

Læs mere

Systematic Software Engineering A/S

Systematic Software Engineering A/S SPI i praksis Erfaringer fra et forløb hos Systematic Software Engineering Knowledge is the only asset that increases in value by sharing Anna-Lis, Product Maturity Consultant Annemette, Project Secretary

Læs mere

[A20] Kick off document and process description. 1 of 5

[A20] Kick off document and process description. 1 of 5 [A20] Kick off document and process description 1 of 5 kick off document Huge Lawn Projekt Kick-Off Alle projekter og ideer er forskellige. For at vi kan give et reelt bud på dit/jeres projekt eller idé

Læs mere

Page 1 of 5 20 artikler. Artikler Tilbage til liste Ny søgning Flere data Layout Gem som fil Udskriv projekt Generel definition: enkeltstående arbejdsopgave, der har et klart mål, kræver planlægning og

Læs mere

Kaizenevent En introduktion til metoden

Kaizenevent En introduktion til metoden : LEANREJSEN - Kaizenevent En introduktion til metoden Adobe full screen: Ctrl + L Brugerlicens DI ejer alle rettigheder til denne præsentation For filer i formatet Adobe giver DI en brugerlicens til alle

Læs mere

Softwaretest. - også af "ikke testbar" software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.

Softwaretest. - også af ikke testbar software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco. Softwaretest - også af "ikke testbar" software DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.dk Hvorfor softwaretest? Software er sjældent fejlfri Test sikrer at softwaren

Læs mere

Sporbarhed og Rapportering i Quality Center. Kim Stenbo Nielsen NNIT Application Management Services

Sporbarhed og Rapportering i Quality Center. Kim Stenbo Nielsen NNIT Application Management Services Sporbarhed og Rapportering i Quality Center Kim Stenbo Nielsen NNIT Application Management Services Indhold INTRODUKTION Hvem er jeg Hvad vil jeg fortælle om QC std. rapporteringsfaciliteter EXCEL RAPPORTER

Læs mere

Business Consulting New manager programme

Business Consulting New manager programme Business Consulting New manager programme Velkommen som manager i Business Consulting Faglig specialisering, bred orientering Vi søger talentfulde managere med lederkompetencer, der trives med udfordringer,

Læs mere

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT (EA) STRATEGY, BUSINESS AND IT ALIGNMENT EFTER FROKOST Del 2 - EA Use case Når forretningen driver teknikken. EA USE CASE Dansk produktionsvirksomhed Producerer og sælger elektronikkomponenter til Droner

Læs mere

Arduinostyret klimaanlæg Afsluttende projekt programmering C

Arduinostyret klimaanlæg Afsluttende projekt programmering C Arduinostyret klimaanlæg Afsluttende projekt programmering C Udarbejdet af: Mathias R W Sørensen, klasse 3.4 Udleverings-dato: 02-03-2012 Afleverings-dato: 11-05-2012 Programmeringvejleder: Karl G. Bjarnason

Læs mere

Informationsforvaltning i det offentlige

Informationsforvaltning i det offentlige Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital

Læs mere

Call Recorder Apresa. Apresa Call Recording

Call Recorder Apresa. Apresa Call Recording Apresa Call Recording Hvorfor optage samtaler? De optagede samtaler giver en værdifuld indsigt i eksempelvis: Medarbejdernes evne til at kommunikere positivt med kunden Medarbejdernes fokus på aftalte

Læs mere

Hvorfor skal vi bruge objekt orienteret databaser?

Hvorfor skal vi bruge objekt orienteret databaser? OODBMS Vs. RDBMS 1 Indholdsfortegnelse Hvorfor skal vi bruge objekt orienteret databaser?... 3 OODBMS i erhvervslivet... 4 Bagsiden af medaljen... 5 OODBMS i praksis... 6 Konklusion... 8 2 Hvorfor skal

Læs mere