Vejledning til udviklingsprocessen for projekt 2
|
|
- Adam Krog
- 6 år siden
- Visninger:
Transkript
1 Vejledning til udviklingsprocessen for projekt 2 Versionshistorik Ver. Dato Initialer Beskrivelse KBE Første version TFJ Rettet efter 1. review KBE Omskrevet analyse og design afsnit med inputs fra møde d. 19/11. Tilføjet beskrivelse af HW konstruktion, SW design og integrationstest KBE Rettelser med inputs fra TFJ KBE Rettelser med inputs fra FOH og TG. Fastlagt ordvalg for udviklingsprocessen KBE Rettelser på baggrund af møde d. 5/12 (TG, KBE) KBE Rettelser tilføjet med inputs fra TG og GEK KBE Rettelser og første officielle version, fjernet skabeloner.
2 Indholdsfortegnelse Indledning... 3 Baggrund... 4 Semesterprojektmodellen... 5 Projektformulering... 7 Specifikation... 7 Arkitektur... 9 HW Design, Implementering og modultest SW Design, Implementering og modultest Integrationstest Accepttest Referencer
3 Indledning Denne vejledning har til formål at beskrive den udviklingsproces, som følges på 2. semesterprojektet. Projektet er fælles for E-, EP- og IKT-studerende på diplomingeniøruddannelsens 2. semester på Aarhus Universitet. Temaet er Home Automation, hvor der skal udvikles både elektronik, PC og indlejret software, som er beskrevet i et separat projektoplæg [1]. Det er vigtigt at et projekt organiseres med en klar rollefordeling, for hvem der gør hvad, og at der etableres et godt samarbejde i projektgruppen. Der henvises til vejledningen om arbejdet i projektgruppen [2]. Semesterprojektet har fokus på at arbejde efter en struktureret udviklingsproces, hvor en del af emnerne fra 2. semester kurset Introduktion til System Engineering (herefter I2ISE) indgår i de enkelte faser af processen. Vejledningen har primært fokus på selve udviklingsprocessen og hvilken projektdokumentation, der skal udarbejdes i de enkelte udviklingsfaser. Projektdokumentationen udarbejdes i faserne og omhandler dokumenter som typisk også produceres i virksomhederne, med særlig fokus på specifikation, konstruktion og test af produkter. Faserne, som skal følges, omfatter projektformulering, specifikation, arkitektur, design, implementering og test. Som afslutning på projektet, skal der skrives en projektrapport. Her beskrives selve projektet og processen, hvordan opgaven er løst og hvordan projektet er gennemført. Her skal de enkelte valg, opnåede erfaringer samt styrker/svagheder beskrives og fremhæves. Det er projektrapporten, som skal læses af både censor og vejleder og den danner grundlaget for bedømmelsen af jeres arbejde. For yderligere information henvises til vejledning for dokumentation af semesterprojekter [3]. I det følgende vil baggrunden for udviklingsprocessen blive beskrevet, hvorefter selve 2. semester udviklingsprocessen samt de enkelte faser vil blive gennemgået. Der henvises til kompendium, slides og øvelser i faget I2ISE for eksempler på brug af metoder og diagrammer som anvendes i de forskellige udviklingsfaser, herunder specifikation med Use Cases, systemarkitektur med SysML og softwaredesign med UML. 3
4 Baggrund Udviklingsprocessen beskrevet i dette dokument er inspireret af vandfaldsmodellen og V-modellen som vist i figur 1. V-modellen omhandler udviklingsfaser og dertil relaterede testfaser, der indeholder test af resultatet for tilhørende specifikation, arkitektur eller design fase. Når man f.eks. er færdig med at specificere, hvad systemet skal gøre planlægges også, hvordan det færdige system skal testes når det afleveres til kunden (accepttest). Det er ikke alle faser i figur 1, der indgår i udviklingsprocessen som dette dokument omhandler. Figur 1 V-modellens udviklingsfaser Vandfaldsmodellen er bedst egnet til mindre, statiske projekter, hvor krav til projektet kan fastlægges og disse ikke ændrer sig i løbet af projektets gennemførelse. Det er netop tilfældet for 2. semesterprojektet, hvor gruppen selv fastlægger kravene til projektet. Vandfaldsmodellen er ikke egnet, hvis det er uklart hvad kunden gerne vil have udviklet og kravene dermed hyppigt ændres undervejs, eller hvis projektet har middel eller høj kompleksitet. Vandfaldsmodellen er heller ikke egnet, hvis teknologien er ukendt eller er umoden. I disse tilfælde er det en god idé at gennemføre et for-projekt eller bruge iterative metoder, der er bedre til håndtering af usikkerhed om krav og ændringer. Figur 2 viser hvordan en udviklingsproces kan gøres mere agil med udgangspunkt i vandfalds- og V-modellen. Her planlægges flere iterationer, hvor kun en del af systemet udvikles i hver iteration. I en iteration gennemløbes faserne i V-modellen omfattende specifikation, arkitektur, design, implementering og test, i nogle tilfælde med levering til kunden. Systemet udvikles iterativt, hvor der ved hver delleverance tilføjes mere og mere funktionalitet til systemet. 4
5 Figur 2 Plan for en udviklingsproces med iterationer og delleverancer Semesterprojektmodellen Semesterprojektmodellen for 2. semester består af en række udviklingsfaser som vist i figur 3. Hver fase har et klart mål og afsluttes med en leverance i form af et eller flere dokumenter, færdige komponenter og/eller et testet system. De første faser gennemføres i fællesskab med det formål at få defineret, specificeret og opdelt systemet i blokke, så de efterfølgende faser med detaljeret design, implementering og modultest kan gennemføres parallelt. De 3 parallelle faser bør gennemføres som små iterationer, hvor der for hver iteration besluttes, hvad der skal leveres. De færdige dele af systemet samles og testes i flere integrationstests, hvor systemet gradvist tilføjes mere funktionalitet og afprøves internt af projektgruppen. Det er på 2. semester valgfrit om modultest og integrationstest dokumenteres. Enhedstest omfatter test af enkelte hardwareblokke eller softwareklasser, hvor andre blokke simuleres efter behov. Integrationstest planlægges og udføres i trin, hvor flere og flere dele af systemet sættes sammen og testes. 5
6 Figur 3 Semesterprojekt modellen illustreret med de faser som projektet gennemløber Som afslutning på udviklingen af et system gennemføres en accepttest, hvor der udarbejdes en rapport med kommentarer til fejlende tests eller tests, som ikke kan gennemføres. Det forventes ikke ubetinget at alle Use Cases, som er specificeret og beskrevet i kravspecifikationen, er implementeret. Det skal dog klart fremgå af de enkelte dokumenter, hvilke krav og Use Cases, som systemet er designet og implementeret til, at skulle opfylde. Der henvises til Scrum [6] som inspiration til et styringsværktøj for udførelsen af aktiviteterne for HW design, SW design, implementering og test. Her ville det være relevant at inddele hver iteration i et eller flere sprints og holde de møder, som er defineret for Scrum. Der er i projektet defineret en række deadlines, hvor der skal være gennemført review af dokumenterne. Disse reviews er listet nedenfor: 1. Deadline omfatter review af Projektformulering, Tidsplan, Kravspecifikation og Acceptestspecification 2. Deadline omfatter review af Systemarkitektur og evt. en første version af HW/SW-designdokumenter 3. Deadline omfatter gennemførelse af accepttest med vejleder 6
7 Fælles for alle produktdokumenter er, at de skal indeholde følgende: Forside med titel, version, dato og gruppenummer, samt navne på projektgruppens deltagere Versionshistorik med resumé af ændringer med dato, version og initialer Indholdsfortegnelse Indledning med kort beskrivelse af dokumentets formål Referencer til relaterede dokumenter I de følgende kapitler vil indholdet af de forskellige faser og dokumenter bliver beskrevet. Der henvises til kompendium, slides og øvelser i faget Introduktion til System Engineering for eksempler på, hvordan specifikationen med Use Cases, systemarkitektur med SysML og software med UML kan beskrives og formuleres. Projektformulering Det første skridt i projektarbejdet er at få beskrevet, hvad projektet går ud på. Gruppen diskuterer med udgangspunkt i projektoplægget, visionen og målet for projektet. Projektets overordnede fokus og funktionalitet beskrives på 1-2 sider. Hvad er problemet som systemet skal kunne løse i relation til omverdenen, og hvordan bidrager systemet til løsningen af problemet? En overordnet illustration kan være værdifuld i beskrivelsen af jeres idé. Projektet skal afgrænses, så det står klart hvad der er med og hvad er ikke med. Det skal ligeledes fremgå hvilken funktionalitet, der er højst prioriteret og hvilke dele af løsningen, der vil kunne vente til en senere opgradering af systemet. Projektformuleringen skal godkendes af gruppens vejleder og udarbejdes sammen med en første tidsplan med milestones. En milestone er et veldefineret tidspunkt i projektforløbet, hvor en eller flere dokumenter er godkendt og opdateret, eller hvor et produkt kan demonstrere en vis grad af færdiggørelse. Specifikation I denne fase specificeres systemet i detaljer. Formålet er at få detaljeret kravene til hvad systemet kan, både i funktionalitet og kvalitet. De funktionelle krav beskrives i form af use cases (UCs). Kvalitetskrav/ikke-funktionelle krav skal være målbare og formuleret så de kan testes. Som inspiration til kvalitetskrav kan kategorierne fra FURPS [5] bruges. Kravene kan prioriteres med formulering ved brug af MoSCoW [4] prioritering. På dansk bruges udsagnsordene skal (Must), bør (Should,) kan (Could) eller vil ikke (Won t). En kravspecifikation bør indeholde nedenstående emner: Systembeskrivelse Funktionelle krav formuleret ved UCs o Beskrivelse af systemets aktører 7
8 o UC diagram o Fully dressed UC-beskrivelser Kvalitetskrav/ikke-funktionelle krav o Samtlige testbare kvalitetskrav til systemet Andre krav: o Krav til anvendt udviklingsproces o Tekniske krav o Krav til grænseflader (ekstern HW/SW og kommunikation med andet udstyr) o Krav til anvendte udviklingsværktøjer Skitse/prototype af brugergrænseflade o F. eks. skærmbilleder (User Interface) For at validere kravspecifikationen, udarbejdes en accepttestspecifikation. Denne formuleres i forlængelse af kravspecifikationen og review es sammen med denne. Formålet er at sikre at alle krav fra kravspecifikationen kan testes når systemet er færdigudviklet. Findes der ikke testbare krav bør kravspecifikationen opdateres. Accepttestspecifikationen er desuden et aftalegrundlag med kunden for, hvilke test der skal kunne gennemføres for at systemet kan accepteres af kunden. Accepttestspecifikationen bør formuleres så enkelt og klart som muligt, så kunden (eller dennes repræsentant) selv kan gennemføre testen og kontrollere resultatet. En accepttestspecifikation bør indeholde nedenstående: Beskrivelse af testsystemet o Skitse af testopstilling og udstyr, der er påkrævet for at gennemføre testen o Testkomponenter (antal, evt. ID, versionsnummer) Testscenarier for hvert forløb i hver UC, med definition af konkrete test data. Testscenarierne bygges op i teststeps. For hvert test step specificeres følgende: o Brugerens handling o Systemets forventede respons herpå o Systemets faktiske respons herpå o Godkendelse af teststep et (eller reference til fejlrapport) Accepttestens scenarier er enkelte, veldefinerede scenarier for de enkelte UCs. Scenariernes teststeps skal formuleres så de følger steps i den UC, der testes. Fordi en funden fejl skal kunne genskabes/reproduceres. Fasen afsluttes med et review af krav- og acceptestspecifikationerne, som opdateres på baggrund af input fra reviewet. 8
9 Arkitektur Arkitekturfasen har til formål at tilvejebringe en systemarkitektur på baggrund af de krav, der er specificeret for systemet. I denne fase nedbrydes systemet i blokke og grænsefladerne mellem disse blokke specificeres. Målet er at skabe et arbejdsgrundlag for den efterfølgende SW design-, HW design- og implementeringsfase. På baggrund af systemarkitekturen skal det være muligt at arbejde parallelt i flere teams med de enkelte blokke i systemet. Det skal således være klart, hvad en given blok skal gøre, og hvordan der kommunikeres mellem blokkene. Som minimum skal hardwareblokkens forbindelser (input og output) og signaler være specificeret. For softwaren udarbejdes en domænemodel for hele systemet og applikationsmodel for hvert delsystem (hver CPU) vha. UML. Applikationsmodellen beskriver vha. klasse- og sekvensdiagrammer, hvordan grænseflade-, domæne- og kontrolklasser arbejder sammen for at opfylde kravene i en given use case. Som minimum skal klasserne i applikationsmodellen udarbejdes med et indledende forslag til metoder og attributter. Det er på dette tidspunkt ikke nødvendigt med en præcis, detaljeret definition af alle parametre og typer for hver metode og attribut. Figur 4 Arkitekturen som den skal beskrives for 2. semesterprojektet med systemarkitektur, del-systemerne (CPU erne) PC, X.10 kontroller og X.10 enhed. Arkitektur-fasen består således af følgende aktiviteter illustreret på figur 4: 1. Fastlæggelse af systemarkitekturen med opdeling af systemet i delsystemer. Systemarkitekturen indeholder en SysML-beskrivelse, der fastlægger hvilke HW-blokke (delsystemer med hver sin CPU ) systemet skal bestå af, udarbejdet vha. SysML strukturdiagrammer (BDD er og IBD er). På et separat SysML BDD vises desuden allokeringen af software applikationer til delsystemerne (CPU erne). Dette kan gøres vha. stereotypen <<allocates>> på associationer fra software- til hardwareblokke. 2. Fastlæggelse af grænsefladen mellem de enkelte delsystemer: Kommunikationsprotokollen mellem systemets enheder defineres og beskrives, herunder for 2. semesterprojektet den serielle kommunikation mellem PC og X.10 kontroller (STK500-kit) samt selve X.10 protokollen. 9
10 3. Udarbejdelse af HW-arkitektur: Hvert delsystem ( CPU ) nedbrydes til mindre HW- blokke illustreret vha. SysML struktur diagrammer (BDD er og IBD er) indtil tilstrækkelig overskuelighed opnås. Der udarbejdes desuden en tabelbeskrivelse af HW-interfaces. 4. Udarbejdelse af SW-arkitektur: Hvert delsystem ( CPU ) nedbrydes til mindre SW-bestanddele (klasser) illustreret vha. UML klassediagrammer indtil tilstrækkelig overskuelighed opnås. Der udarbejdes klasse- og sekvens-diagrammer baseret på relevante use cases til udarbejdelse af en applikationsmodel. Beskrivelsen af systemarkitekturen kan således indeholde nedenstående: Systemarkitektur Overordnet beskrivelse af delsystemer i relation til omgivelserne med SysML strukturdiagrammer (BDD er og IBD er) Beskrivelse af scenarier jf. use cases med sekvensdiagrammer for kommunikation mellem delsystemerne, og mellem delsystemer og aktører Grænseflader Kommunikationsprotokoller, der bruges på snitfladerne mellem delsystemer og eksterne enheder (aktører) HW-arkitektur Beskrivelse af HW-arkitekturen med SysML strukturdiagrammer (BDD er og IBD er) samt evt. sekvensdiagrammer, alle suppleret med tekst eller tabeller, som beskriver Blokkenes formål og funktion Grænseflade for forbindelser mellem blokke Specifikation af elektriske signaler og protokoller SW-arkitektur En domænemodel for hele systemet En applikationsmodel (UML) for hvert delsystem ( CPU ), bestående af sekvensdiagrammer og statiske UML klassediagrammer Indledende forslag til attributter og metoder i klassediagrammerne for SW-interfaces Fasen afsluttes med et review af systemarkitekturen, som efterfølgende opdateres på baggrund af input fra reviewmødet. 10
11 HW Design, Implementering og modultest Hver blok (print eller kredsløb), som er identificeret og specificeret i systemarkitekturen for hardwaren, designes. Blokkene beskrives med kredsløbsdiagrammer, hvor eksterne forbindelser relateres til porte i SysML diagrammerne. Teori, formler og beregninger beskrives og udarbejdes i forbindelse med konstruktion af blokken. Designet skal indeholde komponentberegninger, udarbejdelse af diagrammer (schematics), styklister og evt. PCB-layout. Simulerings og testresultater præsenteres med grafer og resultater i tabeller. Testopstillinger for verifikation af de enkelte moduler beskrives med præsentation af måleresultater. SW Design, Implementering og modultest SW designet detaljeres med opdaterede klassediagrammer med attributter og metoder og parametertyper. Hver klasse beskrives i detaljer, hvor public metoder beskrives med navn, returtyper, parameter og funktionalitet. Dokumentation af klasserne skal være i overensstemmelse med den faktiske implementerede kode. Hvis applikationsmodellen indeholder mange klasser opdeles designet i logiske pakker. Beskrivelsen kan suppleres med sekvens-diagrammer, hvor det vil være relevant. Bruges som eksempel til beskrivelse af et kompliceret kommunikationsforløb mellem klasserne. State-diagrammer kan medtages til beskrivelse af tilstande for en given klasse, hvis denne er implementeret som en state-maskine. Komplicerede metoder beskrives med pseudocode eller forklarende tekst. Det beskrives hvordan de enkelte klasser af designet er testet og hvordan resultatet er verificeret. Det kunne være små testprogrammer og brug af modultest. Som minimum noteres test, resultater og fejlrettelser i projektets logbog. Integrationstest Delsystemerne sættes sammen og testes. Der udarbejdes en plan for, hvordan systemet sættes sammen og testes i flere små iterationer med brug af top-down eller buttom-up tests (drivers og stubbe). Eksempelvis kan PC kommunikation med X.10 controlleren testes uafhængigt om forbindelsen mellem X.10 controller og X.10 enheden er færdig. Der simuleres med LED er på X.10 controlleren kommunikation med X.10 enheden. Denne fase dokumenteres ikke nødvendigvis, men væsentlige resultater medtages i den endelige rapport, hvor integrationstesten kort dokumenteres. Som minimum noteres test, resultater og fejlrettelser i projektets logbog. Der tilføjes ligeledes løbende fejlrapporter indeholdende reference til det fejlede test step, alvorsgraden heraf (f. eks. mindre fejl, større fejl, kritiske fejl), hvordan fejlen rettes, og fejlens konsekvens for testen (testen afbrydes, testen skal gentages senere eller lignende). 11
12 Accepttest I den afsluttende fase forberedes accepttesten. Der udarbejdes en testopstilling, og der holdes generalprøve på testen inden den gennemføres med vejlederen. Evt. manglende dele af systemet gøres bekendt for vejlederen inden testens start. Hvis ikke alle dele af systemet er færdiggjort, er det gyldigt at simulere de ting som mangler. Det kunne f.eks. være at tænde en lysdiode i stedet for en rigtig lampe, eller simulere softwaredele af systemet, som mangler at blive færdiggjort. Mens accepttesten gennemføres, udfyldes accepttestspecifikationen med faktiske observationer og resultat. Referencer [1] Projektoplæg 2. semester.pdf [2] Arbejdet i projektgruppen 2. semester.pdf [3] Vejledning til dokumentation af semesterprojekter.pdf [4] Prioritering af krav med MoSCoW, [5] Beskrivelse af krav med FURPS+, [6] Scrum agile development framework, 12
Bias Reducing Operating System - BROS -
Bias Reducing Operating System - BROS - Accepttestspecifikation Projektgruppe 3: Rasmus Lund Jensen (11111) Nicolai Glud(11102) Jacob Roesen(10095) Mick Holmark(11065) Johnny Kristensen(10734) 1 Versionshistorik
Læs mereHassansalem.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 mereVejledning til gennemførelse af semesterprojekt 1
Vejledning til gennemførelse af semesterprojekt 1 Version 1.7 24. marts 2017 Torben Gregersen tg@ase.au.dk Modificeret til EE projekt forår 2018. Finn Jensen Indholdsfortegnelse Indledning... 3 1. Samarbejde
Læs mereVersion marts 2017 Torben Gregersen Vejledning til gennemførelse af semesterprojekt 1
Version 1.7 24. marts 2017 Torben Gregersen tg@ase.au.dk Vejledning til gennemførelse af semesterprojekt 1 Indholdsfortegnelse Indledning... 3 1. Samarbejde i gruppen.. 3 1.1 Personlige ressourcer.. 3
Læs mereVejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3)
Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3) Version 2.00 / 14-09-2016 / PHM Indholdsfortegnelse Indledning... 3 Baggrund... 3 Iterativ udvikling med ASE-modellen... 4 Udviklingsprocessen
Læs mereVejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3)
Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3) Version 2.10 / 04-01-2018 / PHM Indholdsfortegnelse Indledning... 3 Baggrund... 3 Iterativ udvikling med ASE-modellen... 4 Udviklingsprocessen
Læs mereSecure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation
Udgave 2 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Accepttest-specifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC
Læs mereVersion september 2019 Samuel Thrysøe Vejledning til gennemførelse af semesterprojekt 1
Version 1.05 10. september 2019 Samuel Thrysøe sat@ase.au.dk Vejledning til gennemførelse af semesterprojekt 1 Indholdsfortegnelse INDLEDNING... 3 1. SAMARBEJDE I GRUPPEN... 3 1.1. PERSONLIGE RESSOURCER...
Læs mereCase: Svømmeklubben Delfinen
1. Semesterprojekt Datamatikeruddannelsen, 2. Obligatoriske opgave, efterår 2017 Case: Svømmeklubben Delfinen Svømmeklubben Delfinen er en mindre klub, der er i vækst. Klubbens ledelse ønsker derfor udviklet
Læs mereStruktureret system udvikling Minimodul 2: Kravspecifikation og accepttest
Struktureret system udvikling Minimodul 2: Kravspecifikation og accepttest Rasmus L. Olsen, 18 februar 2009 Kursusoversigt og tidsplan Mm1: Introduktion til kursus, UML og use cases (11 Februar, 2008)
Læs mereDesign og udvikling af et blodtryks ma lesystem
Design og udvikling af et blodtryks ma lesystem 3. semesterprojekt side 1 af 5 Design og udvikling af et blodtryks målesystem Problemformulering I daglig klinisk praksis er der ofte behov for kontinuert
Læs mereStruktureret system udvikling Minimodul 2: Kravspecifikation og accepttest
Struktureret system udvikling Minimodul 2: Kravspecifikation og accepttest Rasmus L. Olsen, 27 februar 2008 Kursusoversigt og tidsplan Mm1: Introduktion til kursus, UML og use cases (13/2, 2008) Mm2: Kravspecifikation
Læs mereProcedure for systemtest
LANDBRUGS- OG FISKERISTYRELSEN Procedure for systemtest Retningslinjer for hvordan test udføres i LFST Kontrakt om Testressourcer Underbilag 1c 23. oktober 2017 Version 1.0 En beskrivelse af hvordan test
Læs mereUnderbilag 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 mereHvem 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 mereFra Computer til Virkelighed. TPE-kursus Elektroniske Systemer P1
Fra Computer til Virkelighed TPE-kursus Elektroniske Systemer P1 Fra Computer til Virkelighed En kort introduktion til kurset Systems Engineering Projektfaser Opsamling og opgave Om kurset Mål: at I lærer
Læs mereVejledning til udfærdigelse af projektrapporter - version 1.2. Vejledning til udfærdigelse af projektrapporter
Vejledning til udfærdigelse af projektrapporter Indholdsfortegnelse 1. Indledning... 2 2. Krav til det afleverede projektmateriale... 2 3. Projektrapporten... 4 4. Procesbeskrivelsen... 9 5. Projektrapporten
Læs mereVejledning til dokumentation af projekter - version 1.2. Vejledning til dokumentation af projekter
Vejledning til dokumentation af projekter 1 Indledning Det hænder desværre jævnligt, at et projekt, hvori der er investeret en fornuftig planlægning, en ihærdig indsats, teknisk snilde, omfattende analysearbejde,
Læs mereKatrines Kælder Kasseapparat
Katrines Kælder Kasseapparat Projektdokumentation Aarhus Universitet Gruppe 4-4. Semester - E15 Vejleder: Lars Mortensen Dato 11-09-2015 David Heilesen Danielewicz - 201400148 - IKT Kalle Rønlev Møller
Læs mereVejledning - 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 mereSecure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation
Udgave 1 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Testspecifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC Testspecifikation
Læs mereBILAG 7. Dokumentation
BILAG 7 Vejledning til tilbudsgiver Bilaget indeholder Kundens mindstekrav til. 2 Indholdsfortegnelse 1. Indledning... 4 2. somfanget... 4 2.1 Proces for udarbejdelse og godkendelse af... 4 2.2 Generelle
Læs mereBILAG 5.D DOKUMENTATION
BILAG 5.D DOKUMENTATION INDHOLDSFORTEGNELSE 1. Indledning...4 2. Kundens krav til Leverancedokumentation...4 Side 2 of 10 Instruktion til besvarelse af bilaget: Teksten i denne instruktion er ikke en del
Læs mereVersion 1.0, sidst rettet 15/ af Samuel Thrysøe. Projekt 1: Fremtidens intelligente seng
Version 1.0, sidst rettet 15/9-2014 af Samuel Thrysøe Projekt 1: Fremtidens intelligente seng 1 Indhold Indhold 2 Indledning 3 Forside 3 Indholdsfortegnelse 3 Liste over forkortelser 3 Problemformulering
Læs mereAutomation Projektledelse Networking GAPP. GAPP kravspecifikation
GAPP GAPP kravspecifikation Kravspecifikation - formål Kategorisere, vurdere og samle krav i logisk og funktionelle grupper for at: Øge overblikket Undgå overlappende og modstridende krav Skærpe de enkelte
Læs mereDm071 / Dm072 - Obligatorisk projekt 3: Design af model
Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Fag: Projektet omhandler emner fra fagene Software Design og Software Konstruktion. Formål: Formålet med projektet er at give dig mulighed for sammen
Læs mereSecure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Projektstyring
Udgave 1 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Projektstyring Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC Projektstyring
Læs mereSammenligning 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 mereIndholdsfortegnelse for kapitel 1
Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................
Læs mereBILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER
BILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER 1 INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved indgåelse heraf. Formål med bilag: Formålet
Læs mereBilag 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 mereFørsteårsprøven 2015. Projektbeskrivelse 2. Semester Multimediedesigner
Førsteårsprøven 2015 Projektbeskrivelse 2. Semester Multimediedesigner Projektbeskrivelse Formål Som afslutning på første studieår skal I gennemføre et tværfagligt projektforløb, der skal afspejle væsentlige
Læs merePlan for præsentationen
Rejsen på vej til Test Drevet Udvikling i Uddannelses- og Forskningsministeriet Præsenteret af Klaus Olsen Willy Kofoed kontorchef i Uddannelses- og Forskningsministeriet Kenneth B Andersen IT Minds På
Læs mere[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 mereVejledning - 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 mereSoftware Dokumentation
Software Dokumentation Jan Boddum Larsen Teknologi B og A på HTX Dokumentation af software i Teknologi I samfundet sker der en bevægelse mod mere digitale løsninger i teknologi. Det betyder at software
Læs mereBias Reducing Operating System
Ingeniørhøjskolen i Aarhus Ingeniørhøjskolen Århus Elektro-Ingeniør linien Semesterprojekt E4PRJ4 Bias Reducing Operating System Skrevet af: Nicolai Glud Studienummer: 11102 Johnny Kristensen Studienummer:
Læs mereNye 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 mereStruktureret system udvikling Minimodul 1: Introduktion, UML og use cases
Struktureret system udvikling Minimodul 1: Introduktion, UML og use cases Rasmus L. Olsen, 27 februar 2008 Introduktion Kursets hjemmeside http://www.kom.aau.dk/~rlo/ Kursus holder Rasmus L. Olsen Færdiguddannet
Læs mereFag: Projekt E1PRJ1 Emne: Kravspecifikation Softdrink-Automat Gruppe: 6 Dato: 10. april 2003 Medlemmer: Benjamin Sørensen, Joanna Christensen, Jacob
Fag: Projekt E1PRJ1 Emne: Kravspecifikation Softdrink-Automat Gruppe: 6 Dato: 10. april 2003 Medlemmer: Benjamin Sørensen, Joanna Christensen, Jacob Nielsen, Jesper Kock, Klaus Eriksen, Mikkel Larsen og
Læs merePrøverne gennemføres som henholdsvis en Idriftsættelsesprøve, en Driftovertagelsesprøve og en. Prøve Delprøve Delprøve
Bilag 12 Afprøvning Side 1 af 9 Bilag 12 Afprøvning I forbindelse med etablering af EPJ skal der gennemføres kvalitetsstyringsaktiviteter jf. bilag 10, herunder afprøvning og evaluering af den samlede
Læs mereNoter til dm529. Jonas Nyrup. 11. november 2011
Noter til dm529 Jonas Nyrup 11. november 2011 Indhold 1 Kravdisciplinen: Kravmodellen og Indfangning af Krav 2 1.1 (ikke)-funktionelle krav...................... 2 1.2 Kravattributter...........................
Læs mereSvendeprøve Projekt Tyveri alarm
Svendeprøve Projekt Tyveri alarm Påbegyndt.: 8/2-1999 Afleveret.: 4/3-1999 Projektet er lavet af.: Kasper Kirkeby Brian Andersen Thomas Bojer Nielsen Søren Vang Jørgensen Indholds fortegnelse 1. INDLEDNING...3
Læs mereSpørgetime. Først gennemgår jeg slagets gang, derefter tjekker vi tidsplanen, og så må I spørge om elektronik mm..
Design og Produktion, Elektronik ( redigeret 13/6-2015 ) Først gennemgår jeg slagets gang, derefter tjekker vi tidsplanen, og så må I spørge om elektronik mm.. Aflevere bøger, fumlebrædder, mm, oprydde
Læs mereSF1460_A Modtag besked Integrationsbeskrivelse - version 2.3.0
SF1460_A Modtag besked - version 2.3.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereUdbud af RIPA-Syd. Underbilag 14.B - Fejlproces
Udbud af RIPA-Syd til Underbilag 14.B - Fejlproces Underbilag 14.B Fejlproces Side 1 af 7 Indholdsfortegnelse: 1. INDLEDNING...4 1.1 Roller...4 1.2 Proces:...5 1.2.1 1.3 Beskrivelse af trinene i processen:...5
Læs mere2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING
2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et
Læs mereUML til kravspecificering
UML til kravspecificering UML mini-kompendium - til brug i forbindelse med modellering af kravspecifikationer. Copyright 2006 Teknologisk Institut, IT-Udvikling Aktivitetsdiagram 2/9 Aktion Aktionsnavn
Læs mereIT-KONTRAKTER HVORDAN HÅNDTERES BEHOVET FOR FLEKSIBILITET I PRAKSIS?
IT-KONTRAKTER HVORDAN HÅNDTERES BEHOVET FOR FLEKSIBILITET I PRAKSIS? Mads Nygaard Madsen, advokat og partner, certificeret IT-advokat, certificeret juridisk ekspert i IT-tvister 22. september 2015 DISPOSITION
Læs mereProduct Ownerens værktøjskasse
Product Ownerens værktøjskasse 26. marts 2014 Jesper Thaning, agil praktiker & partner i BestBrains Agenda Vurdering af behov (værdi og risiko) Nedbrydning Det visuelle Afklaring af User Stories PO i større
Læs mereIt-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 mereADK 1.0 KRAVSPECIFIKATION
ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 23-06-2014 MST Oprettelse af integrationskrav 0.2 25-06-2014 HAH Review for forståelighed og stringens.
Læs mereMicrocontroller, Arduino
Microcontroller, Arduino Programmerbar elektronik. uc Vi skal lære at lave programmer til uc for at kunne lave el-produkter. Forstå princippet i programmering af en uc og se mulighederne. Programmeringen
Læs mereAutomatisk Vandingssystem
Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen - 201205713 - IKT Kasper Sejer Kristensen
Læs mereFAT test kan kun undtagelsesvis overføres, et eksempel kunne være verifikation af tag nummerering og el-diagrammer, som kræver en adskilt maskine.
Kontraktbilag 8 Prøver 1 FAT og SAT FAT og SAT skal sikre at systemet er klar til kvalificering, dvs. alle test fra IQ, OQ og PQ bør kunne genfindes. Testmateriale udarbejdet af leverandør i forbindelse
Læs mereSemesterbeskrivelse OID 3. semester.
Semesterbeskrivelse OID 3. semester. Semesterbeskrivelse Oplysninger om semesteret Skole: Statskundskab Studienævn: Studienævn for Digitalisering Studieordning: Studieordning for Bacheloruddannelsen i
Læs mereSpørgetime Redigeret 15/ Først gennemgår jeg slagets gang, derefter tjekker vi tidsplanen, og så må I spørge om elektronik mm.
Dagsorden for spørgetime: Først gennemgår jeg slagets gang, derefter tjekker vi tidsplanen, og så må I spørge om elektronik mm. Til slut sætter I jeres produkter op så de er klar til at blive præsenteret.
Læs mereArduino Programmering
Microcontroller, Arduino I teknologi skal vi lære at lave programmer til uc for at have muligheden til eksamen at kunne lave intelligente el-produkter. I hvert fald skal vi have set mulighederne, og forstået
Læs mereAutomatisk Vandingssystem. Rettelser. 1 af 11
Automatisk Vandingssystem Rettelser 1 af 11 Automatisk Vandingssystem Projektrapporten Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen
Læs mere[Skriv projektets navn]
1.1 Projektafslutningsrapport [Skriv projektets navn] [Skriv dato] Indhold 1 STAMDATA...2 2 FORRETNINGENS FORMÅL MED PROJEKTET...2 3 AFGRÆNSNING...2 4 MÅL OG SUCCESKRITERIER...2 5 ØKONOMISKE HOVEDTAL OG
Læs mereDANSK IT ARKITEKTUR CERTIFICERING
DANSK IT ARKITEKTUR CERTIFICERING Practitioneruddannelsen System Arkitekt Practitioner Kompetencebeskrivelse Version 2018.02.08 DANSK IT www.dit.dk/ark Copyright All Rights Reserved DANSK IT ARKITEKTUR
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.4.0
SF1460_C Aflever besked - version 2.4.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereAutomatisk Vandingssystem
Rettelser Note: glossary til karprint..................................... 8 Note: Der skal laves software diagrammer til system arkitektur - applikationsmodel sekvens diagrammer state machines osv...............................
Læs mereAnvendelse af BPT til manuel test
DIAS 1 Konference HP Test brugergruppen Anvendelse af BPT til manuel test Agenda DIAS 2 _ Præsentation af mig selv _Manuel BPT _ Manuel BPT i KMD _Konklusion _ Diskussion og spørgsmål Præsentation DIAS
Læs mereSTS Designdokument. STS Designdokument
STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne
Læs mereAutomatisk Vandingssystem
Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen - 201205713 - IKT Kasper Sejer Kristensen
Læs mereSemesterbeskrivelse Innovation og Digitalisering, 3. semester.
Semesterbeskrivelse Innovation og Digitalisering, 3. semester. Semesterbeskrivelse Oplysninger om semesteret Skole: Statskundskab Studienævn: Studienævn for Digitalisering Studieordning: Studieordning
Læs mereAutomatisk Vandingssystem. Rettelser. 1 af 11
Automatisk Vandingssystem Rettelser 1 af 11 Automatisk Vandingssystem Projektrapporten Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen
Læs mereLEVERANCE 1.3. Model for kvalitetssikring
LEVERANCE 1.3 Model for kvalitetssikring Udarbejdelse af kvalitetssikringsmodel, krav til open source kode og dokumentation og godkendelsesprocedurer m.v. Samt fokus på understøttelse af CE-mærkning. 1
Læs mereVentetider i projekter
Ventetider i projekter - en undersøgelse af 25 projekter og deres udfordringer Del I: Hvad venter vi på? Del II: Hvad er en ventetid? Del III: Hovsa! Hvorfor stopper vi her? Del IV: Spild ikke ventetiden!
Læs mereDynamisk 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 mereVelkommen til. Kravspecifikation i Softwareudvikling Workshop hos Brüel & Kjær. 14. september 2012, 9.30 12.30
Velkommen til Kravspecifikation i Softwareudvikling Workshop hos 14. september 2012, 9.30 12.30 Flemming Hansen, IT innovation e-mail: flemming.hansen@it-innovation.dk Kravspecifikation i softwareudvikling,
Læs mereAutomatisk Vandingssystem. Rettelser. 1 af 14
Automatisk Vandingssystem Rettelser 1 af 14 Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.2.2
SF1460_C Aflever besked - version 2.2.2 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereGuide til integration med NemLog-in / Brugeradministration
Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)
Læs mere1) Mennesker, computere og interaktion. Her er omdrejningspunktet basale forudsætninger for interaktion mellem mennesker og computere.
Semesterbeskrivelse OID 2. semester. Semesterbeskrivelse Oplysninger om semesteret Skole: Statskundskab Studienævn: Studienævn for Digitalisering Studieordning: Studieordning for Bacheloruddannelsen i
Læs mere4. Semesterprojekt System Arkitektur. MyP3000 I4PRJ4 E2004
Ingeniørhøjskolen i Århus 20. december 2004 IKT Dalgas Avenue 2 8000 Århus C 4. Semesterprojekt System Arkitektur MyP3000 I4PRJ4 E2004 Gruppe 4: Benjamin Sørensen, 02284 Tomas Stæhr Berg, 03539 Nikki Ashton,
Læs mereBeskrivelse af indhold i ITOS kurset: Master Class i Kravspecifikation indenfor embeddede systemer
Beskrivelse af indhold i ITOS kurset: Master Class i Kravspecifikation indenfor embeddede systemer Introduktion Dag 1 1:00 før frokost Bordet rundt - forventninger Formål Resultat for kursister Opgaver
Læs mereAutomatisk Vandingssystem
Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen - 201205713 - IKT Kasper Sejer Kristensen
Læs mereITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539)
ITWIN1 Afsluttende projekt PhotoDays Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 - AFSLUTTENDE PROJEKT PhotoDays Benjamin Sørensen & Tomas Stæhr Berg 02284 & 03539 1 1 Underskrifter Rapporten
Læs mereKontrakt om Testressourcer. Bilag 1a - Situationsbeskrivelse. 23. oktober Version 1.0
Kontrakt om Testressourcer Bilag 1a - Situationsbeskrivelse 23. oktober 2017 Version 1.0 [Vejledning til tilbudsgiver: Leverandøren skal ikke besvare dette bilag og anmodes om ikke at ændre i bilaget eller
Læs mereBilag 3 FODS 8.2, Fuldt Digital Lokalplaner Kravspecifikation.
HLA 11. juli 2012 Bilag 3 FODS 8.2, Fuldt Digital Lokalplaner Kravspecifikation. Dette notat indeholder kravspecifikationen til offentligt udbud vedrørende Fuldt Digitale Planer og udgør således bilag
Læs mereNyttig viden om den afsluttende opgave på Skov- og naturteknikeruddannelsen
Nyttig viden om den afsluttende opgave på Skov- og naturteknikeruddannelsen For at afslutte din uddannelse som skov- og naturtekniker skal du 1) løse en praktisk opgave på dit praktiksted, 2) skrive en
Læs mereKontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet
Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 8 Test 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav (MK).
Læs mereEmergency call button. Stabilt og simpelt
Emergency call button Stabilt og simpelt 1 Agenda Områder af speciel interesse Gennemgang Hvad har jeg lært? Spørgsmål 2 Områder af speciel interesse Domæne, Krav, Use Cases, Kvalitetsattributter Arkitektur
Læs mereKravspecifikation For. Gruppen
Kravspecifikation For Gruppen Indholdsfortegnelse 1. INDLEDNING...3 1.1 FORMÅL...3 1.2 REFERENCER...3 1.3 LÆSEVEJLEDNING...3 2. GENEREL BESKRIVELSE...4 2.1 SYSTEM BESKRIVELSE...4 2.2 SYSTEMETS FUNKTION...4
Læs mereJEM1 LAB14. Journal. Jonas Lange, Martin Funding Fisker og Torben Porsgaard 11/4/2009
JEM1 LAB14 Journal Jonas Lange, Martin Funding Fisker og Torben Porsgaard 11/4/2009 Denne journal er fremstillet i forbindelse med udarbejdelsen af en J2ME applikation der holder og persisterer links og
Læs mereBilag 10. Afprøvning
Bilag 10 Afprøvning 2 Vejledning til tilbudsgiver Dette bilag beskriver, hvordan Leverancer og videreudviklingsydelser skal afprøves af Kunden i samarbejde med Leverandøren. Bilaget gælder kun for større
Læs mereMULTIMEDIEDESIGNER 1. ÅRS PRØVE
MULTIMEDIEDESIGNER 1. ÅRS PRØVE Eksamensprojekt, 2. semester, forår 2010 TEMA: E-HANDEL Erhvervsakademiet København Nord Udleveret mandag d. 3. maj 2010 Afleveres i 4 eksemplarer senest d. 28. maj kl.
Læs mereBilag 3A.7 Brugergrænseflader
Version 0.8 19-12-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 4 2 INDLEDNING... 5 3 USER EXPERIENCE GUIDELINES (UX-GUIDELINES)... 6 3.1 GENERELLE UX-GUIDELINES... 6 3.1.1 MODTAGERORIENTERET SPROG...
Læs mereSYSTEMDOKUMENTATION AF POC
DIGITALISERINGSSTYRELSEN POC PÅ ORKESTRERINGSKOMPONENTEN SYSTEMDOKUMENTATION AF POC Version: 1.1 Status: Endelig Godkender: Forfatter: Copyright 2019 Netcompany. All rights reserved Dokumenthistorik Version
Læs mereGenerel projektbeskrivelse
02121 Ingeniørarbejde Softwareteknologi Januar 2010 1 Introduktion Generel projektbeskrivelse Formålet med programmeringsprojektet er at give deltagerne erfaring med at designe og konstruere et simpelt
Læs merePROJEKTAFSLUTNINGSRAPPORT
AAU It Services Selma Lagerlöfs Vej 300 9220 Aalborg Ø PROJEKTAFSLUTNINGSRAPPORT [SKRIV PROJEKTETS NAVN] Revisionshistorik Revisionsdato Version Ændringer Forfatter 1 Indhold 1 Stamdata... 2 2 Forretningens
Læs mereProjektlederens roller og kompetencer. Cases til Projektlederens roller og kompetencer
Cases til Projektlederens roller og kompetencer Palle Ragn 1/9 Bibliografiske oplysninger Kursus: Lokalitet: Afgangsprojekt, Diplom uddannelsen i ledelse JCVU, Århus, Danmark Forfatter: Palle Ragn, 160364
Læs mereBILAG 6 TEST OG PRØVER
BILAG 6 TEST OG PRØVER Vers. 2.0 3.09.2013 (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skal ikke udfyldes af Tilbudsgiver. Bilaget
Læs mereProcedurer 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 mereKlare MÅL. Matematik D/C
Klare MÅL Matematik D/C 2 Matematik F/E Mål for undervisningen - Niveau D 1. Eleven kan anvende matematisk modellering til løsning af opgaver og undersøgelse af spørgsmål fra erhverv, hverdag eller samfund,
Læs mereMicrocontroller, Arduino
Microcontroller, Arduino Kompendium til Arduino-programmering i Teknologi. Vi skal lære at lave programmer til uc for at kunne lave el-produkter. Vi skal forstå princippet i programmering af en uc og se
Læs mereBirksund kommune. Datatekniker svendeprøve 2011
Birksund kommune Datatekniker svendeprøve 2011 1 Indholdsfortegnelse 1 Indholdsfortegnelse 2 2 Introduktion 3 2.1 Scenarie 3 2.2 Baggrund for licitationen 3 3 Krav fra Birksund kommune 4 4 Krav til projektgruppens
Læs mereBILAG 1: TIDSPLAN BILAG 1: TIDSPLAN 21. februar 2014
BILAG 1: TIDSPLAN 21. februar 2014 INSTRUKTION TIL TILBUDSGIVER Nærværende bilag indeholder tidsplanen for Systemet. Tilbudsgivers eventuelle forbehold til bilag 8 anføres i forbeholdslisten og skrives
Læs mere