Version marts 2017 Torben Gregersen Vejledning til gennemførelse af semesterprojekt 1

Størrelse: px
Starte visningen fra side:

Download "Version marts 2017 Torben Gregersen Vejledning til gennemførelse af semesterprojekt 1"

Transkript

1 Version marts 2017 Torben Gregersen Vejledning til gennemførelse af semesterprojekt 1

2 Indholdsfortegnelse Indledning Samarbejde i gruppen Personlige ressourcer Personlige relationer Gruppeledelse Gruppe / Team Aftaler Projektgennemførelse og udfærdigelse af projektdokumentation Problemformulerings-fase Specifikations-fase Arkitektur-fase HW-Arkitektur SW-Arkitektur HW/SW-Design-fase HW-Design SW-Design Implementerings- og modultest HW-Implementering og modultest SW-Implementering og modultest Integrationstest-fase Accepttest-fase Projektadministration Samarbejdskontrakt Tidsplan Mødeindkaldelse Referat Logbog Den komplette projektdokumentation.. 20 Referencer 20 2

3 Indledning Semesterprojekt 1 tager sit udgangspunkt i en opgaveformulering, som indeholder en beskrivelse af en elektrisk bil, der i en konkurrence skal gennemføre en bane med forhindringer på kortest mulig tid. Opgaveformuleringen for bilprojektet er beskrevet i dokumentet 1. semester-projekt, projektoplæg [1]. Bilprojektet skal opfattes som et lille udviklingsprojekt, som er fælles for E-, EE- og IKT-studerende på diplomingeniøruddannelsens 1. semester på Aarhus University School of Engineering (ASE). Der skal i dette projekt anvendes stort set samme tid på hardwareudvikling, som der skal anvendes på softwareudvikling. Projektet skal resultere i et prototype-produkt, som er selve den elektriske bil. Udover dette skal projektet resultere i et dokument, der dokumenterer udviklingen af dette prototype-produkt og de resultater der er opnået. Denne notes mål er at beskrive arbejdsmetoden for hvordan et projektarbejde, f.eks. bilprojektet, kan organiseres og udføres i praksis. Denne arbejdsmetode benævnes i det følgende som en proces. Processen, der beskrives her, er tilpasset processen for projektarbejde, der anvendes på de efterfølgende semestre. Forskellen mellem processen for gennemførelse af semesterprojekt 1 og processen for gennemførsel af senere semesterprojekter er blot, at detaljeringsgraden øges i løbet af diplomingeniøruddannelsen til og med bachelorprojektet. Rammerne omkring projektarbejdet er: 1. Samarbejde i gruppen 2. Projektgennemførelse og udfærdigelse af projektdokumentation 3. Projektadministration 4. Den komplette projektdokumentation Disse rammer udgør et godt fundament for projektarbejdet. 1. Samarbejde i gruppen Gruppens samarbejde er af stor betydning for et godt projektarbejde. Det, der har betydning for en projektgruppes velbefindende, er præcis de samme ting, som har betydning i alle mulige andre sammenhænge, hvor et antal personer skal foretage sig noget seriøst sammen. I en projektgruppe har grupperelaterede glæder, bekymringer, konflikter og magtkampe deres rod i de samme sociale mekanismer, og gruppen skal beskæftige sig aktivt med sagen, hvis den skal blive velfungerende. Noget af det gruppen skal tage højde for, er: 1.1. Personlige ressourcer Vi har alle stærke og mindre stærke sider, og det er selvfølgelig hensigtsmæssigt, hvis de enkelte medlemmer i gruppen bidrager med det, som de er bedst til. Alle skal have et rimeligt overblik over projektet. Det er typisk gældende i projektgrupperne, at lyst og evner til teoretisk arbejde, laboratoriearbejde, programmeringsarbejde, at holde orden i filer og papirer og at holde humøret højt, vil være ujævnt fordelt blandt gruppens medlemmer. Tages der hensyn til dette, når arbejdsopgaverne fordeles, øges gruppemedlemmernes tilfredshed og selvfølelse, og gruppens ressourcer udnyttes optimalt. 1.2 Personlige relationer Det er selvfølgelig rarest at være sammen med folk, man kan lide, men man skal være indstillet på også at kunne arbejde sammen med folk, man ikke bryder sig om. Det vil naturligvis være tåbeligt at sammensætte en projektgruppe udelukkende med personer, der ikke kan fordrage hinanden. Men eftersom vi ikke altid selv kan vælge vore samarbejdspartnere, skal vi øve os i at kunne samarbejde med "kedelige" personer. Vi skal træne os i at bøje os mod hinanden. 3

4 1.3 Gruppeledelse Projektgruppen ledes af en projektleder, som har fokus på at projektudviklingen planlægges og gennemføres hensigtsmæssigt, dvs. sådan at de aftalte mål for projektet kan opnås. Projektlederen er et af gruppens medlemmer. Et andet gruppemedlem kan være procesleder. Proceslederen har fokus på at processen forløber optimalt, så de aftalte mål for projektet opnås. Rollerne som hhv. projektleder og procesleder kan eventuelt gå på skift, f.eks. med et 2-ugers interval. 1.4 Gruppe / Team En gruppe er ikke nødvendigvis det samme som et team. Dannelsen af et team ud fra en gruppe er betinget af, at alle gruppemedlemmer føler et fælles ansvar for projektet. En gruppe kan ikke beslutte sig for at blive til et team på et indledende gruppemøde, hvor projektet startes op. Det er noget, der langsomt vokser frem, hvis de rette betingelser er til stede. En af de nødvendige betingelser er, at alle gruppemedlemmer er med i det, der foregår. En målestok for et velfungerende team kan hænge sammen med hvor mange af gruppemedlemmerne, der deltager i gruppens øvrige sociale aktiviteter. 1.5 Aftaler Indgåede aftaler skal overholdes. Det gælder ikke alene aftaler, der er bogførte i mødereferater, men også mere "løse" aftaler, for eksempel en mundtlig aftale mellem to gruppemedlemmer. Hvis man ikke kan stole på hinanden, går gruppen mere eller mindre i opløsning, og resultatet af projektarbejdet bliver mangelfuldt. Erfaringer med vejledning af semesterprojekter viser, at der ofte opstår problemer med samarbejdet i gruppen. Det kan typisk være problemer som: - Nogle gruppemedlemmer udebliver fra aftalte møder uden at melde afbud - Det er ikke aftalt hvordan ledelsesstrukturen i gruppen skal være, så en eller flere påtager sig en selvbestaltet lederrolle og styrer enevældigt - Det er ikke aftalt hvor stort et problem skal være, før vejlederen kontaktes - Gruppemedlemmerne har ikke samme ambitionsniveau - Der er ingen kontrol med, om samarbejdet fungerer for alle - Det er ikke aftalt hvordan omgangstonen i gruppen skal være. Den må ikke være krænkende for nogen - Ingen tager referat fra møderne - Der anvendes ikke mødeindkaldelser med dagsorden - Der er ikke aftalt konsekvenser for den enkelte, hvis samarbejdet negligeres eller saboteres Det er et krav, at der nedfældes og underskrives en samarbejdsaftale mellem medlemmerne i gruppen. Det kan yderligere anbefales at nedfælde og underskrive en tilsvarende samarbejdsaftale mellem gruppen og vejlederen. 4

5 2. Projektgennemførelse og udfærdigelse af projektdokumentation Arbejdsmæssigt udføres et projekt, som både indeholder udvikling af hardware (HW) og software (SW), i følgende faser: - Problemformulerings-fase - Specifikations-fase - Arkitektur-fase - Design-fase - Implementerings- og modultest-fase - Integrationstest-fase - Accepttest-fase Nedenstående figur beskriver et HW/SW-projekts typiske faser og dets output (artefakter): Figur 1. HW/SW-projekts typiske faser og dets output (artefakter) Undervejs i HW/SW-projektets faser, som er beskrevet ovenfor, opstår en række artefakter. Der opstår dels en række dokumenter som artefakter. Hensigten er også, at der skal opstå et samlet produkt som artefakt. Dette produkt kan opdeles i: - et HW-produkt (en prototype eller et salgbart produkt) - et SW-produkt (kildekode (source code), som oversættes til eksekverbar kode) Artefakterne er derfor: - Problemformulering (dokument) - Kravspecifikation (dokument) samtidigt: Accepttestspecifikation (dokument som skrives, men som ikke kan udfyldes med resultatet af accepttesten før produktet er færdigudviklet) - Systemarkitektur (dokument) - HW-design (dokument) SW-design (dokument) 5

6 - Implementering af hvert enkelt HW-modul (veroboard, PCB etc.), som derefter gennemgår modultest (noter i logbog på 1. semester) - Implementering af hvert enkelt SW-modul (source code -> eksekverbar kode), som derefter gennemgår modultest (noter i logbog på 1. semester) - Integrationstest (noter i logbog på 1. semester) - Accepttestspecifikation (dokument, som allerede er skrevet i kravspecifikations-fasen - nu beskrives de opnåede testresultater fra den gennemførte accepttest) I det følgende beskrives projektets faser og deres output/artefakter nærmere: 6

7 2.1 Problemformulerings-fase (output/artefakt: problemformulering (dokument)) I problemformulerings-fasen beskrives overordnet, hvad projektet går ud på. I en live -situation svarer problemformuleringen til det, der kommer ud af de første henvendelser fra en potentiel kunde til et HW/SWudviklingsfirma. Henvendelserne kan ske i form af mails, telefonsamtaler, møder etc., som beskriver et ønske fra kunden. Hvis udviklingsfirmaet vurderer, at det er muligt at løse opgaven, kan kravene efterfølgende beskrives nøje i et dokument: problemformulering. I semesterprojekt 1(PRJ1) er problemformuleringen på forhånd stillet fra undervisernes side, dvs. henvendelsen til jer er allerede sket ved opstart af semesterprojekt Specifikations-fase (output/artefakt: kravspecifikation (dokument)) (output/artefakt: accepttestspecifikation (dokument)) Hvis udviklingsfirmaet vurderer, at det er muligt at løse opgaven ud fra problemformuleringen (se ovenfor), kan kravene efterfølgende beskrives nøje i samarbejde med kunden. I specifikations-fasen afklares alle forhold, der vedrører rekvirenten af projektet, så udviklingsfirmaet og kunden er enige om, hvad der skal udvikles. Kravene skal alle være formuleret, så de er mulige at teste. Der arbejdes ud fra et top-down -view, hvor hele systemet, både HW-mæssigt og SW-mæssigt, i første omgang beskrives som en black box, der kan anvendes af en eller flere brugere (aktører). Aktører kan også være andre færdigudviklede systemer, som det system, der ønskes udviklet, skal kunne kommunikere med. Aktører kan både være primære og sekundære aktører. Primære aktører vises altid til venstre for systemkassen (her Bil ). En primær aktør kan gribe direkte ind i systemets adfærd, f.eks. kan brugeren af bilen sætte bilen i gang. En sekundær aktør er nødvendig for at systemet kan fungere, men den har ikke en aktiv rolle i systemet. Sekundære aktører anbringes altid til højre for systemkassen (her Bil ). Præsentationen af aktører og system vises i et Aktør-Kontekst Diagram: Figur 2. Aktør-Kontekst Diagram for Bil De enkelte aktørers roller beskrives efterfølgende for at uddybe figuren (se dokumentet 1. semester-projekt, projektoplæg [1]) 7

8 Herefter udarbejdes systemets funktionelle krav i samarbejde med kunden. Systemets samlede funktionalitet deles op i afgrænsede del-funktioner, Use Cases. Denne opsplitning giver mulighed for at bevare overblikket i specifikationsfasen og i de følgende faser i udviklingsprocessen. For indledningsvist at skabe et overblik illustreres de Use cases, der anvendes i systemet, i en figur: Figur 3. Use Case Diagram for Bil Bemærk at Use cases navngives i bydeform (imperativ) for at opnå klarhed og præcision. Funktionaliteten for hver enkelt Use Case beskrives herefter præcist i skemaer for at uddybe figuren (se dokumentet 1. semester-projekt, projektoplæg [1]). Nogle krav er ikke mulige at beskrive som funktionalitet (handling) i Use Cases. Tekniske specifikationer som mål, vægt, systemets levetid, temperaturbestandighed etc. beskriver ikke funktionalitet. Derfor beskrives denne type krav som ikke-funktionelle krav. De ikke-funktionelle krav beskrives som regel umiddelbart efter beskrivelsen af de funktionelle krav. Herefter beskrives HW/SW-systemets brugergrænseflade. Denne kan bedst forstås af læseren (kunden, efterfølgende HW/SW-udviklere), når de funktionelle krav er beskrevet forinden. Brugergrænsefladen defineres i samarbejde med kunden indtil der er opnået enighed. Herved er brugergrænsefladen fastlåst, så systemets HW/SW-udviklere ikke opfinder funktionalitet, som kunden ikke har bestilt. Brugerfladen på bilen i 1. semesterprojektet er som regel yderst simpel, da den som regel kun består af en enkelt trykknap, som ikke kræver en lang beskrivelse. Udfordringen i specifikations-fasen er at specificere de aftalte krav i samarbejde med kunden, samtidigt med at kravene skal kunne forstås af det team af HW/SW-udviklere, som efterfølgende skal udvikle HW/SW-produktet. Når alle krav er beskrevet præcist i kravspecifikationen, kan det nu beskrives, hvordan hele HW/SW-produktet skal testes. Dvs. der skal udføres en præcis beskrivelse af hvordan accepttesten af systemet skal udføres. Accepttest for hver enkelt Use Case beskrives med præcise testparametre, og det forventede resultat af testen beskrives præcist. Herved kan accepttesten af systemet gennemføres på nøjagtig samme måde senere, og evt. fundne fejl kan vises for den ansvarlige udvikler. De ikke-funktionelle krav beskrives ligeledes med præcise test-parametre og præcise forventede resultater, så testen kan gentages (se dokument 1. semester-projekt, projektoplæg [1]). Når accepttesten skrives, kan man samtidigt verificere at kravene - såvel funktionelle som ikke funktionelle krav - er beskrevet tilstrækkeligt tydeligt. Alle krav skal være testbare! 8

9 2.3 Arkitektur-fase (output/artefakt: systemarkitektur (dokument)) Denne fase har overordnet set til formål at gøre projektet overskueligt ved at analysere det, og herefter nedbryde det i mindre bestanddele indtil der opnås overskuelighed. I første omgang besluttes hvilke dele af projektet, der skal implementeres som HW, og hvilke dele der skal implementeres som SW. Herefter skal der udføres en nedbrydning af hhv. HW-delen og SW-delen til mindre bestanddele indtil der opnås overskuelighed. Bestanddelene navngives ofte på engelsk af hensyn til de værktøjer (simulatorer, compilere etc.), der skal anvendes til realiseringen af HW-/SW-produktet. HW nedbrydes i bestanddele, som kan kaldes blokke eller moduler. SW nedbrydes ligeledes i bestanddele, som benævnes som moduler. Hvis der skal anvendes en objektbaseret SWarkitektur, benævnes bestanddelene som moduler. Hvis der derimod skal anvendes en objektorienteret SW-arkitektur, benævnes bestanddelene som klasser. I bilprojektet, hvor sproget C oftest anvendes som programmeringssprog, kaldes bestanddelene derfor for moduler, da C ikke er objektorienteret sprog. Anvendes et objektorienteret sprog (som f.eks. C++ ) i bilprojektet, benævnes bestanddelene som klasser. Det er muligt at udføre nedbrydning til overskuelighedsniveau uden i detaljer at vide, hvordan det enkelte modul/klasse skal udvikles. Der er kun brug for en beskrivelse af hvad modulet/klassen har ansvar for og en beskrivelse af samtlige væsentlige grænseflader mellem projektets forskellige SW- bestanddele. Dette giver frihed til på et senere tidspunkt at vælge et andet programmeringssprog til at udvikle de samme moduler/klasser. Nedbrydningen til mindre bestanddele skal principielt være så detaljeret, at et mere detaljeret HW/SW-design af blokke/moduler/klasser kan overgives til underleverandører (andre HW/SW-udviklingsfirmaer, ansatte i forskellige HW/SW-afdelinger i eget firma, delgrupper af ASE-studerende i en projektgruppe etc.). Overblikket over hhv. HW-arkitektur og objektbaseret/-orienteret SW-arkitektur kan skabes ved at udarbejde henholdsvis SysML-diagrammer til HW-arkitekturen og UML-diagrammer til SW-arkitekturen. 9

10 2.3.1 HW-Arkitektur HW-arkitekturen kan udføres vha. SysML (System Modelling Language). HW-blokke kan i første omgang illustreres vha. et BDD (Block Definition Diagram), som nedbryder den samlede hardware i mindre bestanddele (blokke). Nedbrydningen kan fortsætte, indtil der opnås overskuelighed over den samlede hardware. Blokkene navngives og signalerne, der optræder på de enkelte porte i hver blok, navngives. bdd Car «block» Car «ports» out lightout1: Light out lightout2: Light in lightin1: Light In lightin2: Light s1 s2 «block» Sensor ports in J1: 5V in J2: 0V out lightout: Light in lightin: Light out J3: Signal «block» Arduino Mega2560 ports in P1: 9V in P2: 0V in A0: Signal in A1: Signal «block» Power Supply ports out T1: 5V out T2: 0 out T3: 9V out T4: 5V Figur 4. BDD for Bil (reduceret udgave) I det BDD, der er vist ovenfor, er det ikke muligt at vise, hvordan de enkelte HW-signaler forbindes mellem blokkene. Det er nødvendigt at vise disse forbindelser for at færdigøre HW-arkitekturen. Forbindelserne kan illustreres vha. et IBD (Internal Block Diagram). Portene er forinden navngivet (f.eks. J1, T1) i BDD. Det er kun selve HWforbindelserne og HW-signalernes retning, der er tilføjet i IBD, sammenlignet med informationerne i BDD. ibd Car : Car lightout1 lightout J1 T1 s1: Sensor J2 T2 : Power Supply lightin1 lightin J3 T4 T3 A0 P2 P1 : Arduino Mega2560 A1 lightout2 lightout J1 s2: Sensor J2 lightin2 lightin J3 Figur 5. IBD for Bil (reduceret udgave) IBD i ovenstående figur viser de signaler, der optræder mellem de enkelte blokke. Hvert signal starter og ender i en port. En port er den fysiske grænseflade på blokken. Det er vigtigt at hvert signal har entydige porte. 10

11 I stil med Use Case -figuren i kravspecifikation kan BDD og IBD ikke alene forklare blokkenes og signalernes funktionalitet. Deres funktionalitet kan forklares præcist vha. forklarende tekst i tabeller. Først beskrives blokken. Nedenstående tabel er et eksempel på en blokbeskrivelse. Der er mange muligheder for at skrive denne dokumentation med varierende detaljeringsgrad afhængigt af det aktuelle problem. Det kan være praktisk at have blokbeskrivelse og blokdiagram (BDD) samlet. Blok-navn Funktionsbeskrivelse Signaler Kommentar Sensor Detekterer lys 5V Strømforsyning 0V Reference Signal Udgangssignal Light Lys Arduino Mega2560 Processerer input fra Min. 7V Strømforsyning Sensor 0V Reference Signal Lys Signal Lys Power Forsyner Arduino 5V Strømforsyning Mega2560 og Sensor med 0V Reference spænding Min. 7V Strømforsyning 5V Strømforsyning For at fuldende grænsefladebeskrivelsen skal signalerne behandles detaljeret. Signalbeskrivelsen kan med fordel samles i en tabel for alle signaler, evt. sorteret alfabetisk. Denne tabel kan anvendes når grænsefladerne skal designes, testes etc. Signal-navn Funktion Område Port 1 Port 2 Kommentar 0V Reference til Stel analoge spændinger Power, T1 Power, T1 Power, T3 Sensor1, J1 Sensor2, J1 Arduino Mega2560, P1 5V Forsyningsspænding 4,9-5,1V Power, T4 Arduino Mega2560, P2 9V Forsyningsspænding 8,9-9,1V Power, T2 Power, T2 Sensor1, J2 Sensor2, J2 Light Fysisk lys Signal Indikerer registrering af fysisk lys 0-5V Sensor1, J3 Sensor2, J3 Arduino Mega2560, A0 Arduino Mega2560, A1 Rise time < 3.5ms 11

12 2.3.2 SW-Arkitektur SW-arkitekturen fastlægges ved at finde de navneord, som optræder i kravspecifikationen. Disse analyseres for at beslutte om de kan være kandidater til at optræde som moduler/klasser i systemet. Følgende eksempel viser et objektbaseret design på en del af bilen, hvor modulets/klassens navn og navnet på hver enkelt funktion er angivet. Hvis der skal programmeres i et objektorienteret sprog som C++ kaldes en funktion for en metode. Modulernes/klassernes indbyrdes anvendelse er illustreret med pile. En pil rettet mod et modul /klasse indikerer, at der kaldes en eller flere funktioner/metoder i denne klasse. I stil med SysML s BDD og IBD kan illustrationen af moduldiagrammet/klassediagrammet ikke stå alene. De enkelte moduler/klasser skal beskrives med en detaljeringsgrad, der gør det muligt for andre SW-udviklere at udføre et detaljeret design på modulerne/klasserne. Figur 6. Moduldiagram/Klassediagram for Bil (reduceret udgave) Hver modul/ klasse, undtagen modulet/klassen som indeholder main(), repræsenterer en header- og en source-fil. Ovenstående eksempel på et statisk moduldiagram/klassediagram repræsenterer derfor 2 header-filer og 3 source-filer (den 3. source-fil indeholder main() ). Header-filerne indeholder funktionernes/metodernes prototyper og source-filerne indeholder funktionernes/metodernes implementering (source code). Modulbeskrivelse/Klassebeskrivelse af Motor Ansvar: Modulets/klassens ansvar er at kontrollere bilens motor, så den kan køre fremad eller baglæns med variabel hastighed. Modulets/klassens ansvar er også at standse bilens motor Funktioner/Metoder: void forward ( unsigned char speed ) Parametre: Den ønskede speed (0-100), som er den procentuelle angivelse af motorens maksimale ydelse Returværdi: Ingen Beskrivelse: Omsætter parameteren speed til en PWM duty factor, som styrer motoren. Herefter sættes motorens kørselsretning, så bilen kører fremad void backward ( unsigned char speed ) Parametre: Den ønskede speed (0-100), som er den procentuelle angivelse af motorens maksimale ydelse Returværdi: Ingen Beskrivelse: Omsætter parameteren speed til en PWM duty factor, som styrer motoren. Herefter sættes motorens kørselsretning, så bilen bakker void stop( void ) Parametre: Ingen Returværdi: Ingen Beskrivelse: Får motoren, og dermed bilen, til at standse 12

13 Beskrivelsen af hver enkelt funktion/metode skal være tilstrækkelig præcis til, at en anden person kan designe/implementere funktionen/metoden ud fra beskrivelsen. Meget simple funktioner/metoder beskrives eventuelt ikke. Efter afsluttet HW/SW-systemarkitektur kan de enkelte HW-blokke/moduler og SW-moduler/klasser nu uddelegeres til udviklere, som kan udføre design i en så omfattende detaljeringsgrad, at de er klar til at blive implementeret. 13

14 2.4 HW/SW-Design-fase (output/artefakt: HW/SW-design-dokumenter) Formålet med HW/SW-design-fasen er at skabe et overblik, der er så detaljeret, at det er muligt at implementere produktets HW og SW. Designfasen er baseret på de beslutninger, der er taget i HW/SW-arkitektur-fasen HW-Design På basis af HW-arkitektur-fasen, hvor grænsefladen til hver enkelt HW-blok er beskrevet, udføres nu et detaljeret design af hver enkelt HW-blok. Der udarbejdes et diagram (schematic), hvor der gøres rede for hver enkelt komponent. Redegørelsen sker i form af præcise forklaringer til figuren med diagrammet, suppleret med de nødvendige beregninger af hver enkelt komponents værdi. Beregninger sker på basis af de valgte komponenters datablade og modulets interfacebeskrivelse, som er fastlagt i systemarkitektur-fasen. I det følgende vises et eksempel på design af et simpelt HW-modul: LED fabrikat: LITEON Part No. : LTW-2S3D7-012A Strømmen gennem lysdioden D1 besluttes til at være 15 ma Ifølge databladet giver dette et spændingsfald over D1 på 3,25V Forsyningsspændingen V1 er 5V Spændingsfaldet over R1 er da: VD1 = 5V 3,25V = 1,75V R1 kan derfor beregnes således: R1 = 1,75V / 15mA = 116,7 Ω ~ 120 Ω Figur 7. Design af et simpelt HW-modul Der udarbejdes styklister for samtlige komponenter, der skal anvendes. Hvis der skal anvendes PCB (Print Circuit Board) i implementeringsfasen, skal layout et til dette PCB beskrives i den detaljerede HW-design fase. Alt ovenstående HW-design beskrives i et HW-design dokument. 14

15 2.4.2 SW-Design På basis af SW-arkitektur-fasen, hvor grænsefladerne til hver enkelt SW- modul/klasse blev beskrevet, udføres nu et SW-design, der er så detaljeret, at alle væsentlige moduler/klasser, deres input/outputparametre og evt. deres interne algoritmer bliver veldefinerede. Designprocessen fortsættes, indtil der er klarhed om, hvordan den tilhørende source code (implementering) kan skrives. Hvis de interne algoritmer er komplekse, kan det være nødvendigt at beskrive dem vha. af UML-aktivitetsdiagrammer (activity diagrams) og/eller vha. UML-tilstandsdiagrammer (state diagrams). I bilprojektet er den algoritme, der håndterer optælling af passerede refleksbrikker, kombineret med frem- og tilbagekørsel, temmelig kompleks. Denne algoritme kan med fordel forklares vha. et UML-aktivitetsdiagram og/eller et UML-tilstandsdiagram. UML-aktivitetsdiagram (activity diagram) for funktionen/metoden forward() i modulet/klassen Motor: Figur 8. Design af en funktion/metode i et SW-modul/klasse vha. et UML-aktivitetsdiagram I stil med det detaljerede HW-diagram skal figurerne understøttes af en præcis, teknisk forklaring ledsaget af evt. nødvendige beregninger. Der er ikke vist et eksempel på anvendelse af UML-tilstandsdiagrammer (state diagrams) i dette dokument. Anvendelsen gennemgås grundigt på 2. semester i forbindelse med 2. semesterprojektet. Alt ovenstående SW-design beskrives i et SW-design dokument. 15

16 2.5 Implementerings- og modultest-fase (Output/artefakt: HW: prototype/færdigt produkt (veroboard/pcb)) (Output/artefakt: SW: source code, som oversættes til en eksekverbar fil) (Output/artefakt fra modultest: logbog på 1. semester) HW-Implementering og modultest På basis af HW-arkitekturen og det detaljerede HW-design bygges de enkelte HW-blokke/moduler, i første omgang som prototyper. Afhængigt af det miljø, som blokkene/modulerne skal fungere i, bygges de som fuglerede, på veroboard eller på PCB. Miljøfaktorer, som afgør hvordan den designede HW skal implementeres, kan f.eks. være: mekanisk påvirkning (vibrationer), frekvensområde (høje frekvenser kræver korte, velovervejede forbindelser), EMC, kemisk påvirkning, temperaturpåvirkning etc. Hver implementeret HW-blok/modul testes omhyggeligt i laboratoriet. Hvis dette ikke fungerer korrekt, rettes fejlen. Med mindre der er tale om monteringsfejl eller løse forbindelser, er det typisk nødvendigt at ændre HW-modulets design. Det kan yderligere evt. være nødvendigt at gå tilbage og ændre arkitekturen. Er der rettet i HW-design og/eller HW-arkitektur, skal de tilhørende dokumenter opdateres SW-Implementering og modultest På basis af SW-arkitekturen og det detaljerede SW-design skrives source code for hver enkelt SW-modul/klasse. Der udføres en modultest af hver metode i klassen på den HW, som klassen skal styre. F.eks. testes den SWmodul/klasse i bilprojektet, der styrer motoren på den ægte HW (H-bro + selve motoren). Er dette HW-modul/klasse ikke færdigudviklet, kan SW-modulet/klassen testes på en simuleret HW (måleinstrumenter, lysdioder etc.), men sluttelig skal det eftervises, at SW-modulet/klassen kan styre HW-modulet som ønsket. Hvis SW-modulet/klassen ikke fungerer korrekt og hvis HW-blokken med sikkerhed fungerer korrekt, rettes SW-fejlen. Det er typisk nødvendigt at ændre SW-modulets/klassens design. Det kan evt. yderligere være nødvendigt at ændre systemarkitekturen. Er der rettet i SW-design og/eller i SW-arkitektur, skal de tilhørende dokumenter opdateres. 2.6 Integrationstest-fase (output/artefakt: logbog på 1. semester) Efter afsluttet implementering og modultest af HW-/SW-modulerne samles disse moduler gradvist til et færdigt system i udviklingslaboratoriet. Når systemet er samlet fuldstændigt, og det ser ud til at fungere, er systemet klar til gennemførelse af accepttest. Bilen, som anvendes til 1. semester-projektet, ryster og vibrerer under kørslen, så det kan betale sig at implementere den designede HW så solidt, at der ikke opstår løse forbindelser (og dermed funktionssvigt) under kørslen (konkurrencen). 2.7 Accepttest-fase (output/artefakt: accepttestspecifikation (dokument)) Det færdige system testes i henhold til accepttestspecifikationen, som blev udarbejdet i kravspecifikations-fasen. Systemet testes grundigt sammen med kunden, og der markeres OK eller Ikke OK for hvert enkelt punkt i accepttesten. I semesterprojekt 1 skrives en præcis konklusion på resultaterne fra accepttesten i slutningen af projektdokumentation. 16

17 3. Projektadministration Administrationen af et projektforløb skal sikre at projektgruppen: - Har overblik over projektforløbet - Ved hvem, der skal lave hvad, hvornår - Ved hvor langt man er nået - Ved hvor meget man mangler - Kan reetablere udviklingsarbejdet i tilfælde af uheld 3.1 Samarbejdskontrakt Som nævnt tidligere er det er en fordel hvis projektgruppen starter med at udarbejde en skriftlig samarbejdskontrakt. Denne kontrakt skrives af gruppen i fællesskab, så vidt muligt i fuld enighed. Aftalen præsenteres for vejlederen, hvorefter den underskrives af alle gruppemedlemmer. Samarbejdskontrakten kan evt. revideres, hvis dette skønnes nødvendigt, og hvis dette accepteres af alle medlemmerne. I referatet fra møderne vil det således fremgå, om samarbejdet fungerer i forhold til de aftaler, der blev indgået i starten af projektet. Det er vigtigt, at det er hver enkelt gruppe, der laver sin egen samarbejdskontrakt (og ikke anvender en slags standardkontrakt ), da gruppen derved får et ejerskab af aftalen, og denne bliver tilpasset kulturen i den konkrete gruppe. Oftest kan aftalen skrives på en enkelt A4 side. Som minimum bør aftalen indeholde følgende punkter: - Hvor ofte holdes gruppemøder. Hvordan indkaldes til møderne (og af hvem)? Hvem udformer dagsorden? - Med hvor kort varsel kan et medlem melde afbud til et møde? Hvad er konsekvensen, hvis et medlem udebliver fra et møde? Er der kun konsekvens ved gentagne udeblivelser? - Hvem tager referat af møderne? Hvem udsender referatet? - Hvordan ledes gruppen? Er der en eller flere faste ledere, eller går lederrollen på skift? Hvilket ansvar og hvilke opgaver har lederen/lederne? - Hvordan afgøres, om et problem har en karakter, så vejlederen bør informeres? - Hvad er gruppens ambitionsniveau (vil vi blot netop bestå, eller går vi efter 12 tallet)? Har alle gruppens medlemmer samme ambitionsniveau (det er vel ikke forventeligt)? Hvis det ikke er tilfældet, noteres hver enkelt medlems ambitionsniveau. Hvordan tilfredsstilles de enkelte medlemmers ambitionsniveauer? - Hvilken omgangstone er vi enig om at bruge i gruppen? - Hvad er konsekvensen for et medlem, der ikke overholder samarbejdskontrakten? Skal der være en form for straf? I hvilke situationer vil vi inddrage vejlederen i for eksempel konfliktløsning 3.2 Tidsplan Ved projektets opstart, når problemformulerings-fasen er overstået, skal projektgruppen hurtigst muligt udarbejde en tidsplan, f.eks. som et Gantt chart, efter nedenstående model: 17

18 Fase/uge Kravspecifikation Accepttestspecifikation Figur 9. Eksempel på et Gantt chart til fastlæggelse af tidsplan Det kan være nødvendigt at justere tidsplanen undervejs, og dermed arbejdebelastningen pr. tidsenhed, for at opnå det bedst mulige projektresultat. 3.3 Mødeindkaldelse En vigtig del af projektadministrationen er at der indkaldes til møde med jævne, gerne periodiske mellemrum. Mødeindkaldelse skal foregå på en måde, så alle har mulighed for at se den. En skabelon for en indkaldelse til et møde, hvor vejlederen deltager, kan se således ud: Indkaldelse til vejledermøde # nn Dato: Tid: Sted: Deltagere: Dagsorden 1. Valg af mødeleder 2. Valg af referent 3. Godkendelse af referat fra forrige møde 4. Opfølgning på aktionspunkter fra forrige møde 5. Her kan indføjes ekstra punkter 6. Gennemgang af tidsplan 7. Nye aktionspunkter til næste møde. Hvem gør hvad. 8. Tidspunkt for næste møde 9. Evt. Et fast punkt på dagsordenen for hvert møde i gruppen bør være refleksion over samarbejdet i gruppen. Herved sikres, at alle har en mulighed for at få taget evt. luft af ballonen eller måske rose øvrige gruppemedlemmer. 3.4 Referat I den ovenfor viste indkaldelse til et vejledermøde er udpeget hvem der skal være referent. Referenten skriver hurtigst muligt efter vejledermødet et referat, som udsendes til samtlige projektdeltagere, incl. vejlederen. En skabelon for et referat til et vejledermøde kan se således ud: Referat fra vejledermøde # nn Dato: Tid: Sted: Fremmødte: Udeblevet med afbud: Udeblevet uden afbud: Dagsorden 18

19 ad 1) ad 2) 1. Valg af mødeleder 2. Valg af referent 3. Godkendelse af referat fra forrige møde 4. Opfølgning på aktionspunkter fra forrige møde 5. Her kan indføjes ekstra punkter 6. Gennemgang af tidsplan 7. Nye aktionspunkter til næste møde. Hvem gør hvad. 8. Tidspunkt for næste møde 9. Evt. 3.5 Logbog Vigtige hændelser af teknisk og ikke teknisk art, som opstår under projektforløbet, skrives i en logbog. Det er især vigtigt at notere hændelser i implementeringsfasen i forbindelse med udvikling, modultest, integrationstest og fejlfinding af hhv. HW og SW. Tidspunktet for hver enkelt hændelse angives i logbogen. 19

20 4. Den komplette projektdokumentation Projektet dokumenteres i en sammenhængende fil i PDF-format med fortløbende sidenumre. Filen skal indeholde følgende: - Forside (incl. titel, gruppenummer, studienummer og navn for hvert gruppemedlem, navn på institution, navn på vejleder, dato for aflevering, evt. illustration) - Indholdsfortegnelse (skal angive overskrifter og sidenumre på samtlige afsnit) - Projektformulering - Kravspecifikation - Arkitektur (HW/SW) - HW-designdokument - SW-designdokument - Accepttest incl. resultater fra accepttesten - Konklusion på projektet - Individuel konklusion fra hver deltager i projektgruppen Dokumentet 1. semesterprojekt, projektoplæg [1] kan eventuelt anvendes som skabelon for projektdokumentationen. Det skal tydeligt angives, hvem der har bidraget til de forskellige dele af projektet, herunder hvem der har skrevet de forskellige dele af projektdokumentationen. Den individuelle konklusion, sammen med det, som den enkelte studerende har udviklet og beskrevet i projektdokumentationen, er grundlaget for at bestå semesterprojekt 1. Omfanget af PDF-dokumentationen skal være i størrelsesordenen anslag, hvor mellemrum mellem ordene ikke tælles med. Figurer, billeder og lignende tæller heller ikke med i omfanget. Øvrige bilag som mødeindkaldelser, mødereferater, logbog, datablade, source code etc. pakkes sammen i én ZIP-fil. Projektdokumentationen (PDF) og samtlige bilag (ZIP) uploades på: Generel vejledning om digital eksamen findes på: Referencer [1] 1. semesterprojekt, projektoplæg, Henning Hargaard, Aarhus University School of Engineering (ASE),

Vejledning til gennemførelse af semesterprojekt 1

Vejledning 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 mere

Version september 2019 Samuel Thrysøe Vejledning til gennemførelse af semesterprojekt 1

Version 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 mere

Vejledning til udviklingsprocessen for projekt 2

Vejledning til udviklingsprocessen for projekt 2 Vejledning til udviklingsprocessen for projekt 2 Versionshistorik Ver. Dato Initialer Beskrivelse 0.01 17.11.14 KBE Første version 0.02 24.11.14 TFJ Rettet efter 1. review 0.03 26.11.14 KBE Omskrevet analyse

Læs mere

Version 1.0, sidst rettet 15/ af Samuel Thrysøe. Projekt 1: Fremtidens intelligente seng

Version 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 mere

Fra Computer til Virkelighed. TPE-kursus Elektroniske Systemer P1

Fra 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 mere

Vejledning til udfærdigelse af projektrapporter - version 1.2. Vejledning til udfærdigelse af projektrapporter

Vejledning 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 mere

Vejledning til dokumentation af projekter - version 1.2. Vejledning til dokumentation af projekter

Vejledning 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 mere

Fag: 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 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 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

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

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. 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 mere

Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3)

Vejledning 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 mere

Bias Reducing Operating System - BROS -

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 mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Projektstyring

Secure 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 mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation

Secure 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 mere

BILAG 5.D DOKUMENTATION

BILAG 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 mere

Førsteårsprøven 2015. Projektbeskrivelse 2. Semester Multimediedesigner

Fø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 mere

Case: Svømmeklubben Delfinen

Case: 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 mere

Software Dokumentation

Software 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 mere

Arduino Programmering

Arduino 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 mere

LEVERANCE 1.3. Model for kvalitetssikring

LEVERANCE 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 mere

Design og udvikling af et blodtryks ma lesystem

Design 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 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

Værktøj 2 - Milepælsplan

Værktøj 2 - Milepælsplan Værktøj 2 - Milepælsplan Formål Ved at udarbejde en milepælsplan for projektet deles projektet op i mindre og mere håndterbare bidder. Formålet er bl.a. at sikre, at de leverancer og delleverancer, som

Læs mere

Procedure for systemtest

Procedure 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 mere

Lavet af Danni jensen og David Olsen

Lavet af Danni jensen og David Olsen Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse

Læs mere

Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer)

Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Klik her for at angive tekst. Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Krav og vejledning til

Læs mere

MULTIMEDIEDESIGNER 1. ÅRS PRØVE

MULTIMEDIEDESIGNER 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 mere

World Robot Olympiad 2019

World Robot Olympiad 2019 World Robot Olympiad 2019 Regler for Open kategori Version: 4. januar 2019 Vigtige ændringer for WRO 2019... 2 Regler for Open kategori... 3 1. Materiale... 3 2. Regler for robot... 3 3. Konkurrencen...

Læs mere

Michael Jokil 11-05-2012

Michael Jokil 11-05-2012 HTX, RTG Det skrå kast Informationsteknologi B Michael Jokil 11-05-2012 Indholdsfortegnelse Indledning... 3 Teori... 3 Kravspecifikationer... 4 Design... 4 Funktionalitet... 4 Brugerflade... 4 Implementering...

Læs mere

1) Til en praktik prøve. 2) Aflevere Synopsis Som er starten på dit afsluttende eksamensprojekt.

1) Til en praktik prøve. 2) Aflevere Synopsis Som er starten på dit afsluttende eksamensprojekt. Praktikindkald Praktikprøvetilmelding Praktikprøve d. 22-23.03 Udarb. af synopsis Påskeferie Multimedie Designer Uddannelsen Information om 4 semester, foråret 2012 Det overordnede tema for 4. semester

Læs mere

BILAG 7. Dokumentation

BILAG 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 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

SOFTWARE DOKUMENTATION

SOFTWARE DOKUMENTATION SOFTWARE DOKUMENTATION TEKNOLOGI B OG A PÅ HTX Indhold Dokumentation af software i Teknologi på HTX... 2 Overblik... 2 Kravspecifikation... 2 Blokdiagram... 3 Use Case Diagram... 3 Pseudokode... 4 Dokumentation

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2018 Projekt, del II Institut for matematik og datalogi Syddansk Universitet 13. marts, 2018 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Automatisk Vandingssystem

Automatisk 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 mere

Gennemførelsesprocedure for tekniske erhvervsuddannelser

Gennemførelsesprocedure for tekniske erhvervsuddannelser Gennemførelsesprocedure for tekniske erhvervsuddannelser Erhvervs Uddannelses Center Nord 16.12.2013 CBNI/JJ/etj Målet er At signalere, de krav vi stiller til eleverne, og hvordan vi vil følge op på disse.

Læs mere

Workshops til Vækst. - Modul 3: Eksternt fokus. Indholdsfortegnelse

Workshops til Vækst. - Modul 3: Eksternt fokus. Indholdsfortegnelse Workshops til Vækst - Modul 3: Eksternt fokus Indholdsfortegnelse Workshops til Vækst... 1 Eksternt fokus... 2 Praktiske forberedelser... 3 Mentale modeller... 5 Indbydelse... 6 Program... 7 Opsamling

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

BILAG 9 SAMARBEJDSORGANISATION

BILAG 9 SAMARBEJDSORGANISATION BILAG 9 SAMARBEJDSORGANISATION BILAG 9: Samarbejdsorganisation 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:

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

Procesanalyse. Projektstyring. Projektplanlægning

Procesanalyse. Projektstyring. Projektplanlægning Procesanalyse Følgende procesanalyse vil beskrive specialeprocessen. Der vil igennem procesanalysen reflekteres over, hvilke elementer der kan videreføres til kommende arbejdsliv. Emnerne som procesanalysen

Læs mere

Start af nyt schematic projekt i Quartus II

Start af nyt schematic projekt i Quartus II Start af nyt schematic projekt i Quartus II Det følgende er ikke fremstillet som en brugsanvisning der gennemgår alle de muligheder der er omkring oprettelse af et Schematic projekt i Quartus II men kun

Læs mere

Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3)

Vejledning 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 mere

Udviklingsprojekter i Center of Excellence. Regionshospitalet Silkeborg Medicinsk Afdeling Center of Excellence

Udviklingsprojekter i Center of Excellence. Regionshospitalet Silkeborg Medicinsk Afdeling Center of Excellence Udviklingsprojekter i Center of Excellence Regionshospitalet Silkeborg Medicinsk Afdeling Center of Excellence Nye projekter i Center of Excellence I Center of Excellence fokuserer vi på metodeudvikling

Læs mere

Bilag 10 Kvalitetsstyring

Bilag 10 Kvalitetsstyring Bilag 10 Kvalitetsstyring Side 1 af 6 Bilag 10 Kvalitetsstyring Leverandøren skal anvende og dokumentere sit kvalitetssikringssystem. Hvis kvalitetssikringen ikke indeholder de nedenfor beskrevne opgaver,

Læs mere

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Procesvejledningen har til formål, at skabe overblik over app-udviklingsprocessen, og skal sikre kvalitet og genkendelighed blandt apps ene

Læs mere

Automatisk Vandingssystem

Automatisk 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 mere

El kredsløb Undervisningsforløb til Natur/Teknik

El kredsløb Undervisningsforløb til Natur/Teknik El kredsløb Undervisningsforløb til Natur/Teknik Side 1 af 25 Første lektion ca. 90 min. Undervisningsrummet Træningsrummet Studierummet Som indledning tales der med eleverne om el/strøm Se punkt 1 i vejledning

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2018 Projekt, del II Institut for matematik og datalogi Syddansk Universitet 20. marts, 2019 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Microcontroller, Arduino

Microcontroller, 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 mere

Københavns Kommune gennemfører hvert andet år en fælles trivselsundersøgelse på alle arbejdspladser i kommunen.

Københavns Kommune gennemfører hvert andet år en fælles trivselsundersøgelse på alle arbejdspladser i kommunen. TRIVSELSUNDERSØGELSEN 2015 Indhold Indledning 3 Fase 1: Før Forberedelse af undersøgelsen 5 Fase 2: Under Gennemførelse af undersøgelsen 8 Fase 3: Efter Analyse og dialog om undersøgelsen 11 Indledning

Læs mere

Til nogle projekter kan der være knyttet en styregruppe ligesom der i nogle projektforløb kan være brug for en eller flere følge-/referencegrupper.

Til nogle projekter kan der være knyttet en styregruppe ligesom der i nogle projektforløb kan være brug for en eller flere følge-/referencegrupper. PROJEKTORGANISATION OG PROJEKTARBEJDE Rollefordeling i en projektorganisation Ethvert projekt har en projektejer, en projektleder og en eller flere projektmedarbejdere. Disse parter er altså obligatoriske

Læs mere

Vejledning Rapportbanken

Vejledning Rapportbanken Vejledning Rapportbanken Version 1.2 (opdateret 18. november 2013) Support KL yder kun begrænset support på anvendelse af Rapportbanken. Brug derfor gruppen KOMHEN 2.0 på Dialogportalen (http://dialog.kl.dk)

Læs mere

Kære bachelor-opgaveskriver. Velkommen.

Kære bachelor-opgaveskriver. Velkommen. Kære bachelor-opgaveskriver Velkommen. Dette vejlederbrev i beskriver rammerne for min vejledning og for vores samarbejde omkring din bacheloropgave. I brevet kan du læse mere om, hvad jeg tilbyder i vejledningsforløbet,

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

Retningslinjer for praktikperioden på laborantuddannelsen - Laborant AK

Retningslinjer for praktikperioden på laborantuddannelsen - Laborant AK Side 1 af 11 Rammer Retningslinjer for praktikperioden på laborantuddannelsen - Laborant AK Efter laborantuddannelsens 3. semester skal den studerende i praktik. Praktikken foregår i en virksomhed jf.

Læs mere

Strategiudrulning. Ledelsens vejledning. DI-version

Strategiudrulning. Ledelsens vejledning. DI-version DI-version 2013-11-20 Ledelsens vejledning 1-1-1 - STU - Ledelsens Vejledning - 2013-11-2011-20 Alle rettigheder tilhører DI side 1 af 9 Instruktion til kaizenleder Rettigheder DI ejer alle rettigheder

Læs mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation

Secure 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 mere

Guide til projektledere: Succesfuld konceptudvikling, kommunikationsstrategi og eksekvering af dit projekt på BetterNow

Guide til projektledere: Succesfuld konceptudvikling, kommunikationsstrategi og eksekvering af dit projekt på BetterNow Guide til projektledere: Succesfuld konceptudvikling, kommunikationsstrategi og eksekvering af dit projekt på BetterNow version 1.0 maj 2012 Indholdsfortegnelse 1. Indledning... 3 2. Definer budskabet

Læs mere

Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN

Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN Indholdsfortegnelse Introduktion... 2 Definitioner... 2 Generelt... 3 Oprettelse af en skabelon... 4 Sidetypeskabeloner... 5 Globale displaymoduler...

Læs mere

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele LEVERANCE 2.1 Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele Konceptet beskriver, hvordan koden forvaltes, og hvordan

Læs mere

Workshop vedrørende praktikplanen For praktikanter og praktikvejledere på områderne for beskæftigelse og voksne udsatte (Myndighed)

Workshop vedrørende praktikplanen For praktikanter og praktikvejledere på områderne for beskæftigelse og voksne udsatte (Myndighed) Gør tanke til handling VIA University College Workshop vedrørende praktikplanen For praktikanter og praktikvejledere på områderne for beskæftigelse og voksne udsatte (Myndighed) Slides kan findes på: Praktik.via.dk

Læs mere

Vejledning til udfyldelse af ansøgningsskema vedrørende den fællesregionale pulje til forskning i forebyggelse

Vejledning til udfyldelse af ansøgningsskema vedrørende den fællesregionale pulje til forskning i forebyggelse Vejledning til udfyldelse af ansøgningsskema vedrørende den fællesregionale pulje til forskning i forebyggelse Det er vigtigt, at ansøgningsskemaet udfyldes korrekt. Kun fyldestgørende ansøgninger kan

Læs mere

Automatisk Vandingssystem

Automatisk 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 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

Helena Nattestad Kjærbæk august-januar, Lars Laursen marts-juni. Sociale medier - Kommunikation og netetikette. Grundlæggende database, SQL og PHP

Helena Nattestad Kjærbæk august-januar, Lars Laursen marts-juni. Sociale medier - Kommunikation og netetikette. Grundlæggende database, SQL og PHP Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin August 2018-juni 2019 Institution Tønder Handelsskole Uddannelse EUX Fag og niveau Mediefag C Lærer(e) Helena

Læs mere

Bias Reducing Operating System

Bias 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 mere

Emergency call button. Stabilt og simpelt

Emergency 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 mere

World Robot Olympiad 2018

World Robot Olympiad 2018 World Robot Olympiad 2018 Regler for Open kategori Version: 11. Marts 2018 Regler for Open kategori... 3 1. Materiale... 3 2. Regler for robot... 3 3. Konkurrencen... 3 4. Præsentation... 4. Bedømmelsesskema

Læs mere

Rammer og kriterier for ekstern teoretisk prøve. Radiografuddannelsen modul 7, overgangsordning University College Lillebælt

Rammer og kriterier for ekstern teoretisk prøve. Radiografuddannelsen modul 7, overgangsordning University College Lillebælt Rammer og kriterier for ekstern teoretisk prøve Radiografuddannelsen modul 7, overgangsordning University College Lillebælt Gældende efteråret 2016 Formål Formål med prøven er at bedømme i hvilken grad

Læs mere

Til stede: Karen Egedal Andreasen, Janice Vester, Inger-Marie Brun, Asbjørn Molly og Lone Hersted Afbud:

Til stede: Karen Egedal Andreasen, Janice Vester, Inger-Marie Brun, Asbjørn Molly og Lone Hersted Afbud: Referat af semesterevalueringsmøde Master i Organisatorisk Coaching og Læring (MOC), 2.+4. semester, efterårssemestret 2014 Koordinatorer: Lone Hersted + Asbjørn Molly Dato: 29.05. 2015 Til stede: Karen

Læs mere

Manual med retningslinjer for eksamen/svendeprøven Datatekniker

Manual med retningslinjer for eksamen/svendeprøven Datatekniker Manual med retningslinjer for eksamen/svendeprøven Datatekniker Udarbejdet som delelement af forsøgs og udviklingsprojektet Udvikling af nye evaluerings- og eksamensformer Projektnummer: 107530 0. Indhold

Læs mere

Svendeprøve Projekt Tyveri alarm

Svendeprø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 mere

Struktureret system udvikling Minimodul 1: Introduktion, UML og use cases

Struktureret 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 mere

Journal JTAG: Udarbejde af: Benjamin Grydehøj I samarbejde med PDA Projektgruppen. Elektronikteknologafdelingen på Erhvervsakademi Fyn.

Journal JTAG: Udarbejde af: Benjamin Grydehøj I samarbejde med PDA Projektgruppen. Elektronikteknologafdelingen på Erhvervsakademi Fyn. Journal JTAG: Udarbejde af: Benjamin Grydehøj I samarbejde med PDA Projektgruppen Elektronikteknologafdelingen på Erhvervsakademi Fyn. Journal JTAG Xilinx XC9536 29-9-3 Generel beskrivelse af JTAG: JTAG:

Læs mere

7. Referencer til andre værktøjer. 8. Sammenhæng med internationale standarder. 9. Referencer til Projektledelse Teori og praksis. 10.

7. Referencer til andre værktøjer. 8. Sammenhæng med internationale standarder. 9. Referencer til Projektledelse Teori og praksis. 10. Projektlederens værktøj 7. Referencer til andre værktøjer Nr. Navn Sammenhæng med Kritisk sti (CPM) 4.3.3 Tidsplan Udarbejdelse af tidsplan er forudsætningen for at kritisk sti kan findes 4.4.2 Successiv

Læs mere

Program Dokumentation PC Software Skrevet af. Gruppen. Version 1.0

Program Dokumentation PC Software Skrevet af. Gruppen. Version 1.0 Program Dokumentation PC Software Skrevet af Gruppen. Version 1.0 Indholds fortegnelse 1. INDLEDNING...3 1.1. FORMÅL...3 1.2. REFERENCER...3 1.3. VERSIONSHISTORIE...3 1.4. DEFINITIONER...3 1.5. DOKUMENTATIONENS

Læs mere

Hvad skal du vide for at bygge din egen computer?

Hvad skal du vide for at bygge din egen computer? Hvad skal du vide for at bygge din egen computer? Kender du alle de her dele og hvad de gør godt for? Er du mellem 11 og 16 år, og tænker på at sammensætte din egen computer? Så er denne her guide lige

Læs mere

Vejledning til inddatering af afsluttende projekt i UC Viden

Vejledning til inddatering af afsluttende projekt i UC Viden Find vejen frem VIA University College Dato: 13. marts 2015 Vejledning til inddatering af afsluttende projekt i UC Viden Formålet med at registrere og uploade dit afsluttende projekt til UC Viden er, at

Læs mere

M U S. Medarbejderudviklingssamtale - en miniguide

M U S. Medarbejderudviklingssamtale - en miniguide Medarbejderudviklingssamtale - en miniguide Indhold HVORFOR MUS?....................... 4 STRATEGISK KOMPETENCEUDVIKLING............... 4 HVAD ER MUS?....................... 5 RAMMER FOR SAMTALEN 5 LØN

Læs mere

VÆRKTØJ 4 UDVIKLING AF DATA- OG VIDENSDELINGSMODEL

VÆRKTØJ 4 UDVIKLING AF DATA- OG VIDENSDELINGSMODEL VÆRKTØJ 4 UDVIKLING AF DATA- OG VIDENSDELINGSMODEL 1. Formål Dette værktøj kan hjælpe jer til at til at udvikle en samlet data- og vidensdelingsmodel for, hvordan I indsamler og opbevarer data, samt hvordan

Læs mere

Dynamic Order Kom godt i gang

Dynamic Order Kom godt i gang Dynamic Order Kom godt i gang Projektstyring Ressourcestyring Kompetencestyring - Timeregistrering Side 1 af 17 Indholdsfortegnelse Dynamic Order Kom godt i gang... 1 Indholdsfortegnelse... 2 Introduktion...

Læs mere

Undervisningen Der afholdes i forbindelse med praktikken et opstarts- og et midtvejsseminar se herom senere.

Undervisningen Der afholdes i forbindelse med praktikken et opstarts- og et midtvejsseminar se herom senere. Modul 3c - Praktik Formål Målet med praktikken er at give dig mulighed for at udbygge og afprøve din viden og kompetence i det sociale arbejdes praksis i institutionelle omgivelser på et tidspunkt, hvor

Læs mere

Spørgetime Redigeret 15/ Først gennemgår jeg slagets gang, derefter tjekker vi tidsplanen, og så må I spørge om elektronik mm.

Spø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 mere

Struktureret system udvikling Minimodul 2: Kravspecifikation og accepttest

Struktureret 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 mere

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT PROJEKTBESKRIVELSE cuneco en del af bips INFORMATIONER FOR AFLEVERING TIL DRIFT Dato 20. marts 2014 Projektnr. 13 031 Sign. SSP 1 Indledning Dette projekt vil have fokus på at specificere de informationer,

Læs mere

Deltagere Netcompany: Bastian Bajon, Jette Lund, Martin Havemann, Morten Christensen Kopp, Carsten Andersen

Deltagere Netcompany: Bastian Bajon, Jette Lund, Martin Havemann, Morten Christensen Kopp, Carsten Andersen Referat leverandørpræsentation med Netcompany 3. juni 2016 9.30-11.30: Deltagere Netcompany: Bastian Bajon, Jette Lund, Martin Havemann, Morten Christensen Kopp, Carsten Andersen Deltagere Væksthusene:

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2016 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 29. februar, 2016 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

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

Workshop vedrørende praktikplanen

Workshop vedrørende praktikplanen Gør tanke til handling VIA University College Workshop vedrørende praktikplanen For praktikanter og praktikvejledere på Udførerområderne Slides kan findes på: Praktik.via.dk Socialrådgiveruddannelsen Aarhus

Læs mere

2 Resumé. Denne projektrapport omhandler udvikling af et Intelligent House Control system hvor lys og varme kan overvåges og styres i en bygning.

2 Resumé. Denne projektrapport omhandler udvikling af et Intelligent House Control system hvor lys og varme kan overvåges og styres i en bygning. 2 Resumé Denne projektrapport omhandler udvikling af et Intelligent House Control system hvor lys og varme kan overvåges og styres i en bygning. De aktive slaver på det distribuerede realtidssystem er

Læs mere

FRA MODARBEJDE TIL SAMARBEJDE

FRA MODARBEJDE TIL SAMARBEJDE FRA MODARBEJDE TIL SAMARBEJDE Side1 1 FRA MODARBEJDE TIL SAMARBEJDE Denne artikel er til projektlederen der er træt af, at ofre sin arbejdsglæde, fordi andre ikke samarbejder. Til projektlederen der vil

Læs mere

Dansk/historie-opgaven

Dansk/historie-opgaven Dansk/historie-opgaven - opbygning, formalia, ideer og gode råd Indhold 1.0 FORMELLE KRAV... 2 2.0 OPGAVENS OPBYGNING/STRUKTUR... 2 2.1 FORSIDE... 2 2.2 INDHOLDSFORTEGNELSE... 2 2.3 INDLEDNING... 2 2.4

Læs mere

HTX. Afsluttende projekt. E-learning Komunikation/It C Helena, Katrine og Rikke 1.1 01-05-2013

HTX. Afsluttende projekt. E-learning Komunikation/It C Helena, Katrine og Rikke 1.1 01-05-2013 HTX Afsluttende projekt E-learning Komunikation/It C Helena, Katrine og Rikke 1.1 01-05-2013 Systemudvikling Indledende aktiviteter Kommunikationsplanlægning for projektet, Laswells fem spørgsmål. o Hvem

Læs mere

Modulbeskrivelse. Modul 14. Bachelorprojekt. Sygeplejeprofessionen kundskabsgrundlag og metoder. Professionsbachelor i sygepleje

Modulbeskrivelse. Modul 14. Bachelorprojekt. Sygeplejeprofessionen kundskabsgrundlag og metoder. Professionsbachelor i sygepleje Modulbeskrivelse Modul 14 Bachelorprojekt Sygeplejeprofessionen kundskabsgrundlag og metoder Professionsbachelor i sygepleje 1 Indholdsfortegnelse Introduktion til modul 14 beskrivelsen... 3 Modul 14 -

Læs mere

Gennemførelsesprocedure for tekniske erhvervsuddannelser

Gennemførelsesprocedure for tekniske erhvervsuddannelser Gennemførelsesprocedure for tekniske erhvervsuddannelser Erhvervs Uddannelses Center Nord 21./10-18 Jj/cbni Målet er At følge op på elevernes faglige standpunkt, trivsel og særlige kompetencer med henblik

Læs mere

Eksempel på hvordan arbejdet med individuelle planer kan organiseres og sættes op i Bosted

Eksempel på hvordan arbejdet med individuelle planer kan organiseres og sættes op i Bosted 14.04.11 Eksempel på hvordan arbejdet med individuelle planer kan organiseres og sættes op i Bosted Denne vejledning er en beskrivelse af, hvordan man har organiseret arbejdet med borgerens individuelle

Læs mere

Bilag 2.4. Procesbeskrivelse for fælles udbud. Gør tanke til handling VIA University College

Bilag 2.4. Procesbeskrivelse for fælles udbud. Gør tanke til handling VIA University College Bilag 2.4. Procesbeskrivelse for fælles udbud Gør tanke til handling VIA University College Indholdsfortegnelse 1. Formål...3 2. Opgaven...3 3. Begreber...3 4. Udgifter til gennemførelse af fællesudbud...4

Læs mere