metode og struktur for informati- onsniveauer

Metode og struktur for informati-onsniveauer Foreløbig udgave til offentlig høring

November 2012

2 Metode og struktur for informationsniveauer · cuneco · 2012-11-15

cuneco.dk center for produktivitet i byggeriet Rapport Metode og struktur for informationsniveauer Redaktion Kristian Birch Pedersen, Exigo Consult ApS Eigil Nybo Gert Jespersen, NCC Construction Danmark A/S Henrik Lützhøft Madsen, COWI A/S Morten Zimmermann, EKJ rådgivende ingeniører as cuneco – en del af bips bips Lyskær 1 2730 Herlev Telefon 70 23 22 37 Fax 70 23 42 37 E-mail [email protected] www.bips.dk


Indhold

Indhold Indledning ............................................................................................... 5 1

1.1 Formål ............................................................................................. 7

1.2 Målgruppe ....................................................................................... 8

En kort metodeintroduktion ................................................................... 9 2

Scenarier for anvendelse ...................................................................... 10 3

3.1 Indgåelse af projekteringsaftale ................................................... 10

3.2 Brug af funktionsudbud ................................................................ 11

3.3 Bygningsmodellering som produktionsværktøj ............................ 11

Definition og kodning af informationsniveauer .................................... 12 4

4.1 Egenskabsdata .............................................................................. 15

4.2 Kodning af informationsniveauer ................................................. 16

4.3 Views ............................................................................................. 18

4.4 Views vs. sæt af egenskabsdata .................................................... 19

4.5 Udvidelsesmuligheder .................................................................. 21

Anvendelse af informationsniveaumetoden ........................................ 22 5

5.1 Leverancespecifikation ................................................................. 23

5.2 Leverancespecifikation i et faseopdelt projekt ............................. 23

5.3 Eksempler på leverancespecifikation i forskellige projektforløb .. 24

5.4 Skabeloner på cuneco-serveren ................................................... 27

5.5 Leverancespecifikation i et agilt projektforløb eller partnering ... 28

5.6 Processpecifikation baseret på informationsniveauer ................. 30

5.7 Informationsniveauer i relation til aftaleforhold .......................... 31

Konklusion ............................................................................................. 32 6

Litteraturfortegnelse ............................................................................. 33 7


Bilag A Udviklingsmetode ............................................................................. 35

A.1 Indledning ..................................................................................... 35

A.2 Step 1 - Fastlæg og beskriv gyldighedsområdet ........................... 36

A.3 Step 2 - Overvej at genbruge eksisterende

klassifikationsstrukturer, metoder og specifikationer .................. 38

A.4 Step 3 - Oplist vigtige termer ........................................................ 38

A.5 Step 4 - Beskriv de overordnede definitioner af

informationsniveauer inden for gyldighedsområdet .................... 39

A.6 Step 5 - Definer forekomster af bygningsdelstyper pr.

informationsniveau ....................................................................... 41

A.7 Step 6 - Definer informationsniveauer for delsystemer eller

grupper af komponenter ............................................................... 42

A.8 Step 7 - Definer egenskabsdata for hvert informationsniveau .... 44

A.9 Step 8 - Definer restriktioner for egenskaber, såsom tilladelige

værdier samt relationer og krav på tværs af fagområder ............. 45

A.10 Step 9 - Test ved at skabe konkrete datasæt ................................ 46

A.11 Opsummering af udviklingsmetode .............................................. 47

Bilag B – Termer og definitioner ................................................................... 48


Indledning 1

Tegningen har gennem mange år været et af de vigtigste kommunikations-

midler i såvel samarbejdet mellem byggeriets parter, som internt i projekt-

grupper, i dialogen med bygherren og på byggepladsen. De første tegninger

kan dateres helt tilbage til Babylon, omkring 2130 f.Kr. Tegneteknikkerne

blev videre udviklet af romerne til også at indeholde planer og snit, men har

i praksis ikke udviklet sig siden Leonardo da Vinci’s tekniske tegninger i det

15. århundrede (Sørensen, 2009).

Digitaliseringen af byggebranchen er imidlertid godt i gang med at ændre

på dette, så de primære informationsbærere (tegninger) ikke længere er

simple manuelt udarbejdede afbildninger, men visuelt realistiske digitale

repræsentationer, som afspejler opførelse og egenskaber for bygværket

samt dets omgivelser. Det er i dag muligt og fornuftigt i praksis at udarbej-

de komplette digitale modeller af bygninger eller anlæg inden de udføres i

virkeligheden. Mange bygherrer, arkitekter, ingeniører og entreprenører

drager allerede nytte af dette, og skaber digitale bygningsmodeller som

detaljeret beskriver såvel performance af den færdige bygning som dens

opførelsesproces.

De digitale arbejdsmetoder giver en betydelig mulighed for optimering og

integrering af processer i byggeriet, men medfører også en stigende infor-

mationsmængde, og dermed stigende udfordringer med håndteringen af

informationerne. I digitale bygningsmodeller implementeres allerede i de

første faser af projekteringen informationer og data fra mange kilder såsom

interne firmadatabaser, leverandører og producenter. Disse informationer

er af vidt forskellig kvalitet og ikke altid lige strukturerede.

Som illustreret på Figur 1 udarbejdes i byggeprojekter løbende både forelø-

bige og specifikke informationer, med en stigende konkretiseringsgrad over

tid. Disse informationer anvendes på tværs af organisationer til en række

formål såsom grundlag for analyser og beregninger, priskalkulationer, tids-

planlægning, energiberegning, udførelsesgrundlag og visualiseringer mv.

Dette giver store udfordringer i forbindelse med kommunikationen af disse

informationer, hvor ikke alle informationer er tænkt som valide fra afsen-

derens side, men som af samarbejdspartneren kan blive opfattet som gæl-

dende information, der kan anvendes som grundlag for det videre projekt-

arbejde. Ofte kan en digital model skabe en illusion om færdiggørelse, der

reelt ikke til stede.


Figur 1: Illustration af udviklingen af den totale mængde af informationer i projektmateria-le for et byggeprojekt sammenholdt med mængden af valid information.

Byggebranchen håndterer og kommunikerer som ovenfor illustreret ofte

informationer af vidt forskellig validitet, og det er derfor essentielt, at er-

kende behovet for at kunne stille præcise krav til omfanget, kvaliteten, og

definitionen af disse informationer, og dermed opnå fordele af digitaliserin-

gen.

Det er ambitionen med informationsmetoden at skabe et værktøj, der mu-

liggør en entydig kommunikation af validiteten af de informationer, der

måtte være indeholdt i projektmaterialet såvel digitalt som analogt. Dels så

det mere entydigt kan specificeres, hvilken ydelse der skal leveres, men ikke

mindst, så det entydigt kan fastslås på hvilket grundlag ydelsen skal leveres.

Et værktøj, der kan validere informationer, vurderes ikke blot nyttig for de

mere traditionelle parter i en projekteringsproces (bygherre, projekterende

og udførende), men også for en mere effektiv inddragelse af leverandører

og projekterende leverandører i processen. Værktøjet vil også styrke par-

ternes muligheder for at indgå entydige samarbejdsaftaler, og dermed

fremme deres og branchens produktivitet.

Håndtering af grænseflader og forventningsafstemning er andre væsentlige

udfordringer for mange og et område, der ofte giver anledning til fejl og

forsinkelser. De fleste i byggebranchen kan genkende et møde som illustre-

ret på Figur 2, hvor der er opstået tvivl om hvem der skal levere informatio-

ner om udsparinger.


Uoverensstemmelsen mellem projektets partner som illustreret i Figur 2

grunder ofte i udfordringer som:

• Afklaring af grænseflader

• Forventningsafstemning

• Projektering fra forskellige lokaliteter/virksomheder

• Forskellig takt og detaljering på tværs af fag

• Manglende viden/fokus på efterfølgende processer

(f.eks. udførelsen)

Det er alle disse indledningsvist beskrevne udfordringer, cuneco skaber et

værktøj til at løse med den metode og struktur for anvendelse og udvikling

af informationsniveauer i byggebranchen, som beskrives i denne rapport.

Kort fortalt anvendes informationsniveaumetoden til at kommunikere hvad

der ved en overgang mellem to aktører henholdsvis skal afleveres af infor-

mationer, og hvad der modtages af informationer.

I denne rapport beskrives resultatet af det første af flere cuneco-projekter

omhandlende informationsniveauer. I projektet udvikles den metode og

struktur, der skal anvendes i de efterfølgende projekter, hvor indholdet i

informationsniveaumetoden skal detaljeres. Desuden gives konkrete prin-

cipielle eksempler på metodens anvendelse.

1.1 Formål

På baggrund af ovenstående eksempel og udfordringer fra hverdagen i byg-

gebranchen er de vigtigste formål med informationsniveaumetoden over-

ordnet at skabe:

• Et system der er med til at sikre en bedre kommunikation mellem

byggeriets parter.

Figur 2: Typisk samtale på et projekteringsmøde.


• Grundlag for, at det er klart, hvad der ved en overgang mellem to

aktører henholdsvis skal afleveres af informationer, og hvad der

modtages af informationer.

• Klarere spilleregler mellem aktører, samtidig med at det bliver let-

tere at vurdere omfanget af en opgave.

Ved informationsoverdragelser og kravstillelse mellem aktører vil det såle-

des blive klart, for såvel den der afleverer, som den der modtager, hvilke

eksplicitte informationer der er indeholdt, og på hvilket informationsniveau

disse befinder sig. Kort sagt: ”præcise krav giver entydige resultater”.

Metoden skal understøtte informationshåndteringen gennem hele byggeri-

ets livscyklus, lige fra ide til projektering, gennem udførelse samt til drift og

vedligeholdelse.

1.2 Målgruppe

Målgruppen for dette projekt og efterfølgende projekter er alle byggeriets

parter i hele byggeprocessen. Den videre implementering af informations-

niveaubegrebet baseres på dette projekts udviklede metoder og struktur.

Det er en vigtig ambition, at informationsniveaumetoden skal være et

værktøj for alle parter – ikke blot bygherre, projekterende og udførende –

men også leverandører og driftsfolk etc. Desuden skal informationsmeto-

den kunne facilitere både de traditionelle ”hardcore-data” i en projekte-

ringsproces i form af materiale- og geometriske data, men også funktions-

egenskaber, tidsdata, prisdata, arbejdsmiljø etc., altså principielt alle de

informationer, der er aktuelle ved et byggeprojekt.


En kort metodeintroduktion 2

Informationsniveaumetoden beskrives i detaljer i de følgende kapitler i

rapporten, men som en appetitvækker introduceres metoden her med et

lille eksempel.

På Figur 3 er illustreret en kendt og simplificeret byggeproces. Skemaet i

figuren betegnes en leverancespecifikation, og tallene refererer til aftalte

informationsniveauer for de tilhørende bygningsdele og rum. Skemaet vi-

ser, at der ved afslutning af idefasen leveres informationer om rum på in-

formationsniveau 2 samt om vægge på informationsniveau 1. Som illustre-

ret er informationsniveauet for de øvrige bygningsdele ikke specificeret i

idefasen. Disse bygningsdele kan være indeholdt i ideforslaget, med der er

ikke noget krav til deres informationsniveau. Det ses af figuren, at i takt

med at projektet skrider frem øges informationsniveauet for de forskellige

bygningsdele og rum i projektet. Ikke alle bygningsdele er på samme infor-

mationsniveau ved afslutningen af hver fase. Tilsvarende er det også illu-

streret, at informationsniveauet ved aflevering til drift for nogle bygnings-

dele er lavere end f.eks. ved afslutning af udførelsesplanlægningen. Meto-

den er således meget fleksibel og understøtter en lang række forskellige

anvendelsesscenarier.

Hovedelementerne i informationsniveaumetoden er som illustreret ovenfor leverancespecifikationer samt informationsniveaudefinitioner for objekter som bygningsdele og rum. Desuden understøtter metoden også specifikati-on af informationsniveauer for processer

Struktur og kodning af informationsdefinitionerne samt eksempler på,

hvordan leverancespecifikationen anvendes er beskrevet yderligere i de

næste kapitler.

Figur 3: Eksempel på anvendelse af informationsniveauer til specifikation af hvilke informationer, der skal afleveres om bygningsdele og rum ved afslutningen faser i en simplificeret byggeproces.


Scenarier for anvendelse 3

Der er fremkommet mange input til dette projekt fra cunecos behovsanaly-

ser, arbejdsgruppens brainstorming-sessions, workshops med videre. Som

et redskab til at formalisere og kommunikere disse behov anvendes scena-

rier og storytelling.

I dette kapitel beskrives ved hjælp af små historier tre scenarier for praktisk

brug af cunecos informationsniveaumetode. Scenarierne er fiktive og be-

skriver nogle mulige eksempler på, hvordan informationsniveauer i fremti-

den kan anvendes til at forbedre gennemførelsen af byggeprojekter samt

medvirke til at sikre klare og veldefinerede aftaler mellem byggeriets par-

ter.

Scenarierne bruges til at inspirere, kommunikere og indsamle viden om

branchens behov i relation til udvikling og anvendelse af informationsni-

veaumetoden.

Scenarierne omhandler:

1. Indgåelse af projekteringsaftale 2. Brug af funktionsudbud 3. Bygningsmodellering som produktionsværktøj

3.1 Indgåelse af projekteringsaftale

”Ole er projekteringsleder på et nyt laboratoriebyggeri på en uddannelses-

institution i hovedstadsområdet, hvor bygherrens projektleder, Peter, har

besluttet at bruge den nye cuneco informationsniveaumetode i forbindelse

med aftaleindgåelse.

Inden indgåelse af projekteringsaftalen udfører Peter og Ole i samarbejde

en projektanalyse, der definerer og beskriver projektets kontekst, komplek-

sitet, organisation og succeskriterier. På denne baggrund definerer de en

hensigtsmæssig fasemodel for laboratorieprojektet. Laboratoriet skal inde-

holde meget specialudstyr, og de beslutter derfor, at det for inventar og

installationer ikke er hensigtsmæssigt at anvende den traditionelle fasemo-

del, men i stedet at inddrage leverandørerne i en dialogbaseret udbudsform,

hvor der opstilles funktionskrav på Informationsniveau 2 til udstyret.

Under udfyldelsen af leverancespecifikationen logger Ole og Peter på cune-

cos server for at sikre, at de har den samme opfattelse af, hvad informatio-

ner om vinduer og døre på informationsniveau 3 og 4 betyder i praksis. Til

deres store glæde er de lidt tekniske detaljer suppleret med nogle illustrati-


oner, så de hurtigt får fornemmelse af, hvor detaljerede de forskellige byg-

ningsdele skal være på forskellige stadier i projektet.

Tilsvarende undersøger de også, hvilke egenskabsdata arkitekten skal levere

for rum og facader, for at installationsingeniøren kan udføre en energiram-

meeftervisning.”

3.2 Brug af funktionsudbud

”I en totalentreprise ønsker totalentreprenøren at benytte et funktionsud-

bud for et atriumovenlys. Han indbygger derfor i sine rådgiveraftaler, at

vinduerne specificeres på informationsniveau 2. Samtidig identificeres

grænsefladerne til de øvrige bygningsdele til at være konstruktionssamlin-

gerne, tilslutning for den elektriske styring samt fugerne. Det aftales derfor,

at disse grænseflader fastlægges på informationsniveau 3 som grundlag for

funktionsudbuddet.

Omvendt sikrer totalentreprenøren i sin kontrakt med underentreprenøren,

at denne får ansvaret for tidsplanen for bygningsdelene, som indgår i atri-

umovenlyset. Dermed opnås et optimalt forløb i forhold til projektets rådgi-

vere, både for kontrol af funktionskravenes opfyldelse og geometrisk koor-

dinering med øvrige bygningsdele.”

3.3 Bygningsmodellering som produktionsværktøj

”Entreprenørfirmaet MNP Entreprise har besluttet at anvende cuneco in-

formationsniveaumetoden i forbindelse med indgåelse af aftaler med deres

rådgivere på totalentrepriser. Det giver dem klare fordele i forbindelse med

produktionsplanlægningen, da de nu har systematiseret den måde, rådgi-

verne opbygger deres bygningsmodeller på. Herved kan MNP automatisk og

løbende udføre successive økonomiske kalkulationer og foretage risikoana-

lyse af projektets tidsplan.

MNP vælger at opgradere de bygningsmodeller, de får fra rådgivere i infor-

mationsniveau 4 for konstruktionerne og indvendige vægge til informati-

onsniveau 6, da disse så kan anvendes direkte som input til deres arme-

ringsrobotter og CNC-skæremaskinerne, der skærer og pakker henholdsvis

armering og lægter i den takt, de skal bruges på byggepladsen.”


Definition og kodning af infor-4mationsniveauer

Informationsniveaumetoden baseres på anvendelsen af informationsni-

veauer, der entydigt specificerer informationsleverancers omfang samt

konkretiserings- og detaljeringsniveau for bygningsdele, rum og processer.

Grundlaget for at kunne udfylde leverancespecifikationen illustreret i kapi-

tel 0 er definitioner af informationsniveauer. Definitionerne er faste, stati-

ske og indeholder for hver bygningsdel, rum eller proces en beskrivelse af

kravene til informationer for hvert informationsniveau. I modsætning til

indholdet i leverancespecifikationen er informationsniveaudefinitionerne

faste og det samme for alle aftaler, så eksempelvis produktegenskaber for

et vindue på informationsniveau 3 altid har samme indhold uafhængigt af

projekttype, fase eller aktør. På et aktuelt projekt skal der således ikke ta-

ges stilling til indholdet informationsniveaudefinitionerne, men kun til tids-

punktet eller fasen informationen skal leveres i, samt hvem den skal leveres

af.

Det er fundet hensigtsmæssigt som udgangspunkt at anvende 6 forskellige

informationsniveauer. De 6 informationsniveauer benævnes med tal fra 1-

6, hvor 1 svarer til det laveste informationsniveau og 6 til det højeste in-

formationsniveau.

Informationsniveauer defineres uafhængigt af projekttype, samarbejdsform

og faseforløb. Der er således ikke en direkte sammenhæng mellem et speci-

fikt informationsniveau og f.eks. hovedprojekteringsfasen i et byggeprojekt,

da det kan aftales forskelligt fra projekt til projekt, hvilket informationsni-

veau specifikke bygningsdele eller processer skal være på i en bestemt fase.

Som illustreret i Tabel 1 og Tabel 2 indeholder informationsniveaudefinitio-

ner for bygningsdele en kombination af omfang, detaljering og konkretise-

ring af specifikke egenskaber for den pågældende bygningsdel.


Illustration Beskrivelse

Informationsniveau 1

Søjlen er ikke specificeret på dette

informationsniveau.


Funktionskrav

Søjle indgår i det bærende system.

Produktegenskaber

Stålsøjle

Formegenskaber

~200x300 mm

Placering

I modulsystem pr. ~6 m


Funktionskrav

Søjle indgår i det bærende system.

Produktegenskaber

Stålsøjle

Formegenskaber

I-profil 240 mm

Placering

I modulsystem pr. 5,4 m

Tabel 1: Eksempel på en søjle i informationsniveau 1-3. Beskrivelsen skal ses som en ek-semplificering og er ikke en fyldestgørende beskrivelse af tilstrækkelige informationer pr. informationsniveau.


Illustration Beskrivelse


Funktionskrav

Søjles bæreevne 124 kN

Produktegenskaber

Materiale: S355 J2

Formegenskaber

HE 240 B

Placering



Funktionskrav

Søjles bæreevne 124 kN

Produktegenskaber

Søjle Materiale: S355 J2, varmval-

set

Bolte i samling: Kvalitet 8.8. A4

Formegenskaber

HE 240 B

Bolte i samling: M16

Placering


Bolte i samling: c-c 120 mm


Datagrundlag for automatisk

produktion (pseudo-kode)

%

O4968

N01 M216

N02 G20 G90 G54 D200 G40

N05 T0300

N06 G96 S854 M42 M03 M08

N07 G41 G00 X1.1 Z1.1

T0303

N08 G01 Z1.0 F.05

N09 G00 Z1.1

N10 X1.0

N11 G01 Z0.0 F.05

%

Tabel 2: Eksempel på en søjle i informationsniveau 3-6. Beskrivelsen skal ses som en ek-semplificering og er ikke en fyldestgørende beskrivelse af tilstrækkelige informationer pr. informationsniveau.


4.1 Egenskabsdata

Informationer om rum, bygningsdele og processer kan beskrives ved hjælp af egenskabsdata. Som beskrevet i cunecos metode og struktur for egen-skabsdata, er egenskabsdata data om egenskaber dvs. en repræsentation af egenskaber på et givet objekt. Egenskaber defineres som ”karaktertræk ved objekter” og kan både være generelle egenskaber, der findes på alle objek-ter, der tilhører en given klasse, eller specifikke egenskaber, der kun findes på de enkelte forekomster af objekterne. For så enkelt som muligt at kunne kommunikere og definere informations-niveauer har udviklingsarbejdet bag denne metodebeskrivelse vist, at det er hensigtsmæssigt at gruppere objekters egenskabsdata. Som vist på Figur 4 foreslås informationer om objekter og dermed deres egenskabsdata overordnet grupperet i minimum 3 områder: Funktionskrav, Resultat og Produktion. Funktionskrav omhandler informationer, der stiller krav til de specifikke løsninger i Resultatområdet. Produktionsområdet om-handler de produktionsrelaterede informationer, der anvendes til at skabe, drifte eller nedbryde resultatet. Hvert område kan videre opdeles i grupper af egenskabsdata, som f.eks. produkt-, placering-, form- og grænsefladeegenskabsdata for resultatområ-det, hvormed der menes:

Produktegenskaber o Beskriver løsningernes produktegenskabsdata såsom byg-

ningsdelsspecifikationer, materialer og fabrikat.

Placeringsegenskaber o Beskriver løsningernes placeringsegenskabsdata såsom

modulsystem, lokalisering, orientering og mål.

Formegenskaber o Beskriver løsningernes formmæssige egenskabsdata såsom

facon, profil og areal.

Grænsefladeegenskaber o Beskriver løsningernes referencer til tilstødende objekter,

samt deres samlinger, tilslutninger og fuger m.v.


Figur 4: Gruppering af egenskabsdata.

Ovenstående opdeling af informationer i 3 områder og herunder grupper af egenskabsdata giver mulighed for entydigt at stille krav, som varierer på tværs af område eller egenskabsdatagruppe. Dette muliggør, at det i en given fase af projektet kan specificeres, at f.eks. søjlernes placering skal være fastlagt, men deres endelige dimension og materialetype først vil væ-re på plads i næste fase af projektet. I praksis betyder det, at der med informationsniveaumetoden kan opstilles entydige specifikationer, hvor f.eks. produktegenskaber for nogle bygnings-dele er kendt tidligt i projektforløbet, men deres konkrete placering først specificeres senere. Dette er typisk praksis i mange projektforløb, hvor det relativt tidligt beslut-tes at opføre et byggeri med betonelementer, mens den konkrete placering af de enkelte vægge først fastlægges senere. Tilsvarende fastlægges bæ-rende vægges placering ofte tidligere end deres specifikke tykkelse (form), eller det er forskellige aktører, som specificerer henholdsvis placering og form. Byggeprojekter er præget af en lang række sådanne delte eller forskudte informationsleverancer, som er svære at håndtere med de gængse aftale former. Med opdeling af informationer i områder og gruppering af egen-skabsdata har projektgruppen skabt et stærkt værktøj til at håndtere dette, som det vil blive illustreret yderligere i kapitel 5.

4.2 Kodning af informationsniveauer

Med henblik på at kunne kommunikere entydigt omkring informationsleve-rancer indføres en kodning af egenskabsområderne og de underliggende grupper. Der anvendes bogstaver ved kodningen og de fastlægges i cunecos projekt omhandlende egenskabsdata samt begrebsmodel for procesdomæ-net.


Et eksempel på en overordnet kodning af områder og egenskabsdatasæt

kunne se ud som herunder. Det skal bemærkes, at listen alene er et eksem-

pel og ikke er gennemarbejdet, hvilket vil ske i senere cuneco-projekter.

Metoden understøtter, at koderne kan nedbrydes successivt:

A: Funktionskrav

• AA: Økonomi

• AB: Energi

• AC: Miljø

• AD: Indeklima

• AE: Akustik

• …

B: Resultat

• BA: Produkt

• BB: Placering

• BC: Form

• BD: Grænseflader

C: Produktion

• CA: Udførelsesmæssige forhold

• CAA: Fugtstyring

• CAB: Arbejdsmiljøhensyn

• CAC: Produktionsplanlægning

• CB: Projektering • CBA: Analyse og simulering

• CBAA: Bygherrekravsvurdering • CBAB: Statisk simulering • CBAC: Indeklimasimulering • CBAD: Energiforbrugssimulering • CBAE: Lyssimulering • CBAF: Bæredygtighedsvurdering • CBAG: Flugtvejssimulering • CBAH: Brandsimulering • CBAJ: Analyse af overholdelse af bygningsregle-

mentet • CC: Pris

• CD: Tid

• CE: Kvalitetssikring

• CF: Drift- og vedligehold

…..

Koderne for områder og egenskabsdatasæt anvendes som præfiks ved

kommunikation, aftaler og beskrivelse af informationsniveauer eller som

kendemærke i tabeller, der indeholder informationsniveaudefinitioner

Eksempelvis angiver koden ”A3”, at funktionskrav specificeres på informa-

tionsniveau 3. Tilsvarende angiver ”BA3 B2”, at produktegenskaber specifi-

ceres på informationsniveau 3 og de øvrige placering-, form-, og grænsefla-

deegenskaber i resultatområdet på informationsniveau 2.


Det anbefales, at indholdet i informationsniveaudefinitionerne fastlægges

successivt – det vil sige, at der i den videre udvikling først defineres infor-

mationsniveauer for de overordnede sæt af egenskabsdata, inden de fast-

lægges for mere detaljerede.

I de følgende afsnit beskrives anvendelsen og kodningen af informationsni-

veauer yderligere.

4.3 Views

De fleste processer i byggeriet kræver informationer for at kunne gennem-

føres. Den mængde af information, som er krævet for at gennemføre en

given proces betegnes i CCS et view (af information). Det kan være views

for information krævet til eksempelvis udførelsesplanlægning, drift, energi-

beregning mv.

Views anvendes således til at udvælge klasser af objekter med udvalgte sæt af egenskaber med henblik på at opfylde specifikke formål som illustreret på Figur 5.

F.eks. kan et view indeholde de klasser af bygningsdele med tilhørende

egenskabsdata, som man skal bruge for at lave en energiberegning.

Mængden af views vil ligesom mængden af egenskaber være nærmest

uendelig, da det er de praktiske behov i konkrete situationer, der vil define-

re, hvad et view vil indeholde, og hvad det skal bruges til.

CCS vil indeholde en række prædefinerede views, som brugerne umiddel-bart vil kunne anvende til nærmere specificerede formål. Det vil tillige være muligt for brugerne at lave tilpasninger til disse views eller at oprette egne views til specifikke formål.

Nogle processer kan gennemføres med forskelligt omfang, detaljering eller

konkretisering. Disse processer defineres på forskellige informationsni-

veauer med dertil hørende forskellige views. Processen priskalkulation kan

som illustreret på Figur 6 gennemføres med forskelligt omfang og nøjagtig-

Figur 5: Illustration af et view til processen energiberegning.


hed. Ønskes et groft overslag anvendes f.eks. view’et på informationsni-

veau 2. Det giver mulighed for at gennemføre en kalkulation baseret på en

simpel gennemsnitlig enhedspris for f.eks. kontorbyggeri multipliceret med

det samlede bruttoetageareal. Ønskes en mere nøjagtig kalkulation anven-

des view’et på informationsniveau 3 eller 4, hvor der inddrages flere egen-

skabsdata til at fastlægge enhedsprisen. Tilsvarende er mængderne ikke

længere alene fastlagt på baggrund af bygningens bruttoareal, men er en

opgørelse af de faktiske mængder af bygningsdele. Jo højere informations-

niveau des flere egenskabsdata er indeholdt i viewet, hvilket, som illustre-

ret på figuren, giver mulighed for at udføre en kalkulation med en større

nøjagtighed.

En priskalkulation på informationsniveau 3 stiller krav om, at der er egen-

skabsdata til rådighed i et tilsvarende informationsniveau. Som illustreret

på Figur 6 med de røde pile omfatter dette både egenskabsdata for bygnin-

gen som helhed, men også større bygningsdele såsom facaden. Ved pris-

kalkulationen fastlægges desuden yderligere egenskabsdata såsom en-

hedspriser, der ikke er indeholdt i egenskabsdata fra resultatområdet.

4.4 Views vs. sæt af egenskabsdata

Views og sæt af egenskabsdata er beslægtede begreber, men indeholder

nogle væsentlige forskelle.

Views indeholder en specifikation af hvilke egenskabsdata, der skal være

tilgængelige på det givne informationsniveau for at kunne gennemføre en

proces. Et view anvender ofte sæt af egenskabsdata fra forskellige områder,

hvorimod egenskabsdatasæt ikke kan være indeholdt i hinanden, og såle-

des indeholder klart adskilte egenskabsdata. Desuden kan der for hvert

view være behov for at specificere supplerende egenskabsdata, som fast-

lægges i den pågældende proces i det pågældende informationsniveau.

På Figur 7 er konceptuelt illustreret, hvordan views gør brug af egenskabs-

data på tværs af områder.

Figur 6: Illustration af anvendelsen af views (af information) på forskellige informationsniveauer til gennemførelse af en priskalkulation med forskellig nøjagtighed.


Ved anvendelse af sæt af egenskabsdata refereres alene til en leverance af information. Views består både af krav til hvilken information, der skal fast-lægges, inden processen kan gennemføres, og hvilken information, der leveres, når processen er gennemført. Som illustreret på Figur 6 er formålet med view’et priskalkulation, at kunne beregne prisen på et samlet projekt eller bygningsdele med en fastlagt nøjagtighed for hvert informationsni-veau. I Figur 8 illustreres, hvordan et view på forskellige informationsniveauer stiller krav til leverance af information fra forskellige sæt af egenskabsdata. Koderne i skemaet er tidligere forklaret i afsnit 4.2, f.eks. betyder ”B Væg-system” på informationsniveau ”A2 B3”, at Funktionskrav specificere på informationsniveau 2, og informationer i resultatområdet (B) på informati-onsniveau 3.

Figur 8: Eksempel på definering af views for processen drift- og vedligeholdelsesplanlæg-ning på forskellige informationsniveauer baseret på sæt af egenskabsdata.

Figur 7: Illustration af hvordan views defineres på tværs af egenskabsdatasæt.


4.5 Udvidelsesmuligheder

Ved den fremtidige definition af views og informationsniveauer for forskel-

lige fagområder kan det vise sig hensigtsmæssigt ikke at definere alle de

tidligere beskrevne 6 informationsniveauer. For at skabe let genkendelig-

hed på tværs af fagområder anbefales det ved fremtidige informationsni-

veaudefinitioner at operere indenfor rammerne af 6 informationsniveauer.

Hvis det f.eks. viser sig, at det ved definering af views for energisimulering

er tilstrækkeligt med 3 informationsniveauer, nummereres disse 2,3,4. In-

formationsniveauer 1, 5, 6 kan så være blanke.

Hvis der derimod er behov for underinddeling af informationsniveauer,

eller der opstår behov for forskellige alternative informationsniveaudefini-

tioner, anbefaler projektgruppen, at der til disse specialtilfælde anvendes

små bogstaver efter tallet for informationsniveauet. Som et eksempel be-

tragtes et underview til produktionsplanlægning (kode: CAC), der kan være

”Fordeling af projekteringsydelser og ansvar ved leverance og montage af

elementer af beton og letklinkerbeton”, med koden CACD. Hvis der ved

definering af informationsniveau 3 for viewet CACD opstår behov for 2 pro-

jektspecifikke alternativer bliver koderne således CACD3a og CACD3b.

Nogle processer kan stille krav om særlige egenskabsdata, som er udover

det, der normalt og obligatorisk er indeholdt i et view på et bestemt infor-

mationsniveau. Dette kodes ikke, men skal fremgå af informationsniveau-

definitioner, som illustreret i Figur 8.

Fleksibiliteten i anvendelsesmulighederne af informationsniveaukoderne er

illustreret i Figur 9.

Figur 9: Eksempel på udvidelsesmulighederne i kodningen af informationsniveauer.


Anvendelse af informationsni-5veaumetoden

I sidste kapitel blev det introduceret hvordan informationsniveauer kodes

og defineres. I dette kapitel beskrives, hvordan informationsniveaumeto-

den anvendes som et effektivt værktøj til at specificere informationsleve-

rancer.

Informationsniveaumetoden er ikke en ny 3D-arbejdsmetode, projekte-

ringsmetode eller fuldautomatisk proces, der fratager byggebranchens

aktører deres faglige dømmekraft og viden. Metoden forudsætter, aner-

kender og understøtter den nødvendige faglige indsigt, der skal til at gen-

nemføre et byggeprojekt. Informationsniveaumetoden er en ny måde at

understøtte aftaler om informationsleverancer og informationsflow samt

et redskab til at styre projektforløb i byggeprojekter.

Metoden kan anvendes i traditionelt faseopdelte projektforløb samt i andre

organiserede forløb såsom funktionsudbud, systemleverancer mv. Desuden

understøttes agile samarbejdsmetoder såsom Scrum (se e.g.

http://www.scrum.org). Metoden sigter mod at understøtte processer i

projektbaserede produktioner, samt vilkårlige faseforløb. Desuden er den

rettet mod hele forløbet fra projektering til udførelse og drift.

Tilsvarende kan metoden anvendes i forbindelse med både digital og analog

projektering.

Afhængig af det enkelte byggeprojekts størrelse og organisationsform kan

der være mange forskellige måder at indgå aftaler på mellem projektets

aktører og dermed implementere informationsniveaumetoden. Et generelt

eksempel på, hvordan informationsniveaumetoden kan understøtte de

øvrige aftaleforhold i projektet, kan følge nedenstående 6 trin:

1. Udfør før indgåelse af en aftale baseret på informationsniveauer en

projektanalyse, der definerer og beskriver projektets kontekst, kompleksitet, organisation, aktører og succeskriterier

2. Fastlæg en hensigtsmæssig procesmodel for byggeprojektet (f.eks. fasemodel for projektering og udførelse)

3. Identificer relevante aktører for relevante roller 4. Analyser informationsbehovet i projektets forskellige faser eller an-

vend en af cunecos skabeloner for f.eks. en traditionel faseopde-ling, totalentrepriser eller funktionsudbud

5. Udfyld leverancespecifikationen 6. Følg løbende op på om projektets fremdrift er i overensstemmelse

med det aftalte


5.1 Leverancespecifikation

Som et vigtigt redskab i informationsniveaumetoden anvendes leverance-

specifikationen som grundlag for at aftale, hvem der leverer hvilken infor-

mation hvornår samt i hvilket detaljerings- og konkretiseringsniveau.

Leverancespecifikationen kan udarbejdes successivt eller fastlægges for

hele projektet fra starten af samarbejdet. En enkel leverancespecifikation

er illustreret i Figur 10 for Fase 1 på et byggeprojekt. Som vist leveres in-

formationer fra resultatområdet (B) for bygningsdele, der indgår i de 7 an-

førte hovedsystemer på informationsniveau 1-3. Som illustreret strukture-

res leverancespecifikationen efter CCS og bygningsdelene i hvert hovedsy-

stem er ikke nødvendigvis på samme informationsniveau i fase 1.

Antallet af hovedsystemer, delsystemer og komponenter, der indgår i leve-

rancespecifikationen, vil afhænge af det specifikke projekt, og det samme

vil detaljeringen af listen - dvs. venstre side i leverancespecifikationen.

Figur 10: Eksempel på enkel leverancespecifikation.

Leverancespecifikationen kan som illustreret på Figur 11 udvides med en

specifikation af aktører på hver leverance.

Figur 11: Eksempel på leverancespecifikation med aktører.

5.2 Leverancespecifikation i et faseopdelt projekt

For hver fase i et byggeprojekt udvides leverancespecifikationen med flere

kolonner som illustreret i Figur 12. Det giver mulighed for at variere infor-


mationsniveau for hver bygningsdelstype, og tilsvarende enkelt tilføje for-

skellige aktører. Det er væsentligt at bemærke, at der ikke er en fastlåst

sammenhæng mellem de traditionelle fasemodeller og informationsni-

veauer. Leverancespecifikation anvendes til helt fleksibelt at aftale, hvornår

en aftalt eksplicit information skal være tilgængelig, og understøtter, at

forskellige fagområder ikke nødvendigvis følger den samme takt for detalje-

ring af informationer.

Figur 12: Eksempel på leverancespecifikation i faseopdelt projekt.

5.3 Eksempler på leverancespecifikation i forskellige pro-jektforløb

En af de store styrker ved informationsniveaumetoden er dens anvendel-

sesmuligheder til at understøtte entydige aftaleforhold i vilkårlige projekt-

forløb. Det illustreres i det følgende med nogle eksempler.

Figur 13 viser først et eksempel på, hvordan de informationer, som skal

afleveres i forbindelse med et tidligt udbud af pælefundamenter kan speci-

ficeres. Her ses det, at terrænsystemet (A) er opdelt i fire projektspecifikke

delsystemer anført med %-tegn. Som anført ud for A Terrænsystem afleve-

res informationer i resultatområdet (B) generelt i informationsniveau 2,

men for delsystem %UF3 af typen Pælefundamenter afleveres informati-

onsniveau B4.

System og bygningsdelstypelisten kan nedbrydes successivt, og som følge af

systemets fleksible opbygning og struktur er det muligt at udspecificere

aftaler om nogle bygningsdele mere end andre. Kriterierne for en yderligere

nedbrydning kan være mange, f.eks. brug af flere rådgivere, brug af funkti-

onsudbud, eller at sikre udvalgt information tidligt (f.eks. for myndigheds-

behandling eller tidlig produktion). Netop opstillingen af leverancespecifika-

tionen baseret på informationsniveauer sikrer en enklere kommunikation af

formål og værdi ved en sådan underopdeling.


Figur 13: Eksempel på leverancespecifikation ved projektforløb med tidligt udbud på fun-damenter.

På tilsvarende vis er i Figur 14 illustreret, hvordan produktegenskaberne for

de indvendige vægge er specificeret på et relativt højt informationsniveau 4

i fase 4, mens deres placerings- og formegenskaber er på det laveste infor-

mationsniveau. Det kan f.eks. være i et projekt, hvor det er besluttet, at de

indvendige vægge er 120 mm gipsvægge, men deres placering er endnu

ikke fastlagt i fase 4.

Figur 14: Eksempel på leverancespecifikation, hvor produktegenskaberne for de indvendi-ge vægge er specificeret på et relativt højt informationsniveau 4, men deres placerings- og formegenskaber er på det laveste informationsniveau.

I forbindelse med funktionsudbud på vand-, afløbs- og varmesystemer

(F+G) er i eksemplet i Figur 15 illustreret, hvordan alene funktionskravene

(A2+A4) er specificeret for disse systemer. Som det ses af figuren er de øv-

rige systemer udbudt på baggrund af detailprojekteret materiale på et in-

formationsniveau hvor både resultatområdet (B) og funktionskravene (A) er

fastlagt.


Figur 15: Eksempel på anvendelse af leverancespecifikation til specificering af informati-onsniveau i forbindelse med et funktionsudbud på vand-, afløbs- og varmesystemer.

Det er et velkendt problem, at suboptimering dominerer byggebranchen,

og som argumenteret af Kunz og Fischer (2009): “Architects, engineers and

contractors all have a culture and methods that minimize cost. With notable

exceptions, many lack a culture that seeks to maximize value. This culture

follows owner preference, but it also represents a culture that some AEC

players accept in order to minimize their short-term project risks.” giver en

sådan tilgang sjældent et overordnet optimalt forløb eller produkt. En leve-

rancespecifikation som konceptuelt illustreret i Figur 16 med tilhørende

terminer vil være et godt værktøj til at modvirke dette, men vil forudsætte

nogen detaljering. Med et udbygget paradigme for informationsniveauer-

nes indhold vil selv en meget detaljeret aftaleformular være enkel at udfyl-

de.


Figur 16: Eksempel på fleksibel anvendelse af leverancespecifikationen med forskellige informationsniveauer for forskellige bygningsdele og rum i forskellige faser af et projekt.

5.4 Skabeloner på cuneco-serveren

Leverancespecifikationen vist i Figur 10 -

Figur 16 kan implementeres i regneark, på en hjemmeside eller som en del

af et projektstyringsværktøj, og for hvert hovedsystem, delsystem, kompo-

nent eller rum specificeres det aftalte informationsniveau for den pågæl-

dende informationsleverance.

Inf. niv Aktør Inf. niv Aktør Inf. niv Aktør Inf. niv Aktør

INST

AL.

SYS

TEM

INV

ENTA

RSY

ST.

INFR

AST

RU

KTU

R

Fase 1 Fase 2 Fase 3 Fase N

BYG

NIN

GSD

ELE

OG

RU

MR

UM

TER

RÆ

NSY

STEM

VÆ

GSY

STEM

DÆ

KSY

STEM

Inf. niv. B2

Inf. niv. B2

Inf. niv. B2

Inf. niv. B2

Inf. niv. B2

Inf. niv. B3

Inf. niv. B3

Inf. niv. B3

Inf. niv. B3

Inf. niv. B3

Inf. niv. B3

Inf. niv. B3

Inf. niv. B4 Inf. niv. B4

Inf. niv. B4

Inf. niv. B4

Inf. niv. B5

Inf. niv. B4

Inf. niv. B5


Desuden anføres, hvem der er ansvarlig for leverancen, samt om der er

andre, som skal bidrage med oplysninger vedrørende den pågældende byg-

ningsdel eller rum.

Cuneco-serveren vil kunne indeholde skabeloner svarende til best-practice

for forskellige organisationsformer og fasemodeller, så den enkelte projekt-

leder eller bygherre, der er ansvarlig for udarbejdelse af aftaler på et byg-

geprojekt, kan komme let i gang med anvendelse af metoden. Tilsvarende

etableres standarder for indholdet i de enkelte informationsniveauer for

delsystemer, rum og udvalgte views.

5.5 Leverancespecifikation i et agilt projektforløb eller partnering

Hvis aftaleforholdene på et byggeprojekt baseres på en agil samarbejdsme-

tode såsom Scrum, kan leverancespecifikationen også anvendes.

Her vil der for hvert sprint af 1 uge til 1 måneds varighed blive aftalt, hvilke

informationer, der udarbejdes, og af hvilket team. Aftaleformularen udfyl-

des således ikke for hele projektet ved indgåelse af kontrakt mellem projek-

tets aktører, men derimod løbende ved opstart af hvert sprint. Metoden til

indgåelse af aftaler understøtter på tilsvarende vis også effektivt projekter,

hvor partnering anvendes som samarbejdsform.

Leverancespecifikationen vil i agile projektforløb udvikles dynamisk og som

illustreret med grå i Figur 17 udfyldes kun felter for de bygningsdele, som

behandles i det pågældende sprint.


Figur 17: Eksempel på leverancespecifikation for et byggeprojekt baseret på den agile samarbejdsmetode Scrum. På det viste stadie er sprint 1-3 gennemført og denne aftale vedrører sprint 4

I forbindelse med det daglige/regelmæssige Scrum-møde inden for hvert

sprint opdateres et informationsniveau statusskema, hvilket giver alle pro-

jektets aktører mulighed for at følge fremdriften af projektet som vist på

Figur 18. Det kan umiddelbart lyde som ofte at afholde daglige møder, men

dette er et vigtig element i Scrum-metoden og med til at sikre fremdrift,

fjerne barrierer og mindske risici i projektet.

Inden for bl.a. softwareudvikling er agile metoder som Scrum udbredte, og det er hensigten, at informationsniveaumetoden skal give mulighed for også at anvende dem i byggebranchen. Det ligger imidlertid uden for ram-

Inf. niv. Master Team Inf. niv. Master Team Inf. niv. Master Team Inf. niv. Master Team

Sprint 3 Sprint 4

BYG

NIN

GSD

ELE

OG

RU

MR

UM

TER

RÆ

NSY

STEM

VÆ

GSY

STEM

DÆ

KSY

STEM

INST

AL.

SYS

TEM

INV

ENTA

RSY

ST.

INFR

AST

RU

KTU

R

Sprint 1 Sprint 2

Figur 18: Eksempel på statusoversigt for et projekt styret ved hjælp af samarbejdsmetoden Scrum. Kilde: billede fra Wikipedia.


merne af dette projekt at fastlægge, hvornår agile udviklingsmetoder med fordel kan anvendes samt give yderligere vejledning i implementering af metoderne, se Schwaber and Sutherland (2011).

5.6 Processpecifikation baseret på informationsniveauer

En af styrkerne ved informationsniveaumetoden er, at den ikke kun kan

anvendes til specifikation af informationsleverancer for bygningsdele og

rum men også til specifikation af leverancer fra processer. I dette afsnit

gives nogle eksempler på specifikation af processer baseret på informati-

onsniveauer.

I Figur 19 er vist hvordan en tidsplanlægningsproces kan gennemføres på 6

informationsniveauer.

Figur 19: Eksempel på hvordan leverancer fra en tidsplanlægningsproces kan specificeres på 6 informationsniveauer. Ændringer fra et informationsniveau til det næste er vist med blå skrift.

På samme måde kan specifikation af processen mængdeudtræk også base-

res på informationsniveaumetoden. Dette er illustreret for bygningsdelen

stribefundament i Figur 20. I cunecos projekter omhandlende opmålings-

regler bliver dette beskrevet og specificeret yderligere. Det anbefales at

starte fastlæggelsen af processen mængdeudtræk med specifikation af

opmålingsregler for delsystemer, og derefter for komponenter, hvis dette

viser sig nødvendigt.


Figur 20: Eksempel på anvendelse af informationsniveaumetoden til specifikation af opmå-lingsregler for bygningsdele. Her illustreret for et stribefundament.

5.7 Informationsniveauer i relation til aftaleforhold

En byggesags aftaleforhold reguleres typisk af en eller flere kontrakter ba-

seret på AB 92, ABT 93 eller ABR 89, og som bilag til kontrakten beskrives i

en ydelsesbeskrivelse den konkrete ydelse eller løsning, som leveres. For

rådgivningsydelserne kan ydelsesbeskrivelsen f.eks. baseres på DANSKE

ARK/FRI’s standarder, og for udførelsen af byggeprojekter kan ydelsesbe-

skrivelsen være baseret på bips’ beskrivelsesværktøj B.1000.

Leverancespecifikationen og informationsniveaudefinitionerne er udviklet

med henblik på at udgøre et bilag til disse ydelsesbeskrivelser og skal som

tidligere beskrevet danne grundlag for at udarbejde entydige aftaler om

leverancer.

I projekter, hvor f.eks. bygherre stiller krav til de projekterende om anven-

delse af IKT (informations- og kommunikationsteknologi), herunder byg-

ningsmodellering, er dette beskrevet i et selvstændigt bilag til ydelsesbe-

skrivelsen. I IKT-ydelsesbeskrivelsen kan der med fordel refereres til leve-

rancespecifikationen med henblik på afklaring af informationsniveau i byg-

ningsmodellerne.


Konklusion 6

I denne rapport er beskrevet en metode og struktur for anvendelse af in-

formationsniveauer i byggebranchen. Der er søgt skabt et vigtigt grundlag

for udarbejdelse af mere entydige aftaler i byggebranchen og klarere græn-

seflader mellem dens aktører. Dette er gjort med udviklingen af nye leve-

rancespecifikationer understøttet af informationsniveaudefinitioner, der

kan anvendes i såvel traditionelle projektforløb som mere agile samarbejds-

former.

Projektet har dermed bidraget med en ny metode til at specificere bran-

chens ikke-formaliserede antagelser om, hvem der leverer hvilken informa-

tion hvornår til hvad og i hvilket omfang. Dette forventes desuden at for-

bedre byggebranchens muligheder for genbrug af viden på tværs af aktører.

Det er endvidere ambitionen, at den udviklede metode vil understøtte sy-

stematisk brug af bygningsmodellering både i projekteringen og samarbej-

det med leverandører om indholdet i bygningsobjekter samt sikre, at byg-

ningsmodellering kan anvendes som et produktionsværktøj. Selvom meto-

den givet også med fordel kan benyttes i et traditionelt ”analogt” byggepro-

jekt, ses den store styrke i understøttelsen af bygningsmodellering og ned-

brydning af de traditionelle grænseflader mellem projektering og udførelse.

Dette ses som afgørende for at fremme branchens produktivitetsudvikling.

Kvaliteten, successen og værdien af informationsniveaumetoden skal nu

skabes gennem praktisk afprøvning, implementering i virkelige projekter og

videre tilpasning og udvikling baseret på erfaringerne fra den praktiske

brug.


Litteraturfortegnelse 7

AIA (2008): Document E202 – 2008, Building Information Modelling Proto-

col Exhibit, The American Institute of Architects.

bips (2005): bips Publikation A113 / 2005 - Fordeling af projekterings-

ydelser og ansvar ved leverance og montage af elementer af beton

og letklinkerbeton, 3. udgave, 1. oplag, Byggecentrum.

bips (2006): DBK 2006 Vejledning, Begrebsmodel, klassifikations- og refe-

rencesystem, Det Digitale Byggeri, bips.

bips (2008a): bips C102, CAD-manual 2008, anvisning.

bips (2008b): bips F103, objektstruktur 2008 – revision A.

Gasevic D., Djuric, D., Devedzic, V. (2006). Model Driven Architecture and

Ontology Development, Springer-Verlag Berlin Heidelberg, 311 pp.

Gruber, Tom (1993). A translation approach to portable ontology specifica-

tions, Knowledge Acquisition 5, pp. 199-220.

ISO (2001): ISO 12006-2:2001(E). Building construction – Organisation of

information about construction works – Part 2: Framework for classifi-

cation of information.

ISO (2009): ISO/FDIS 29481-1:2009(E). Building information modelling —

Information delivery manual — Part 1: Methodology and format.

Kiviniemi, A. (2005): Requirements Management Interface to Building

Product Models, CIFE Technical Report #161, Stanford University.

Kiviniemi, A. et al. (2007): Senate Properties: BIM Requirements 2007, Vol-

ume 1: General part, VTT Technical Research Centre of Finland

Kunz, J. and Fischer, M. (2009). Virtual Design and Construction: Themes,

Case Studies and Implementation Suggestions, CIFE Working Paper

#097, Version 9, Stanford University.

Liebich, T., Adachi, Y., Forester, J., Hyvarinen, J., Karstila,K., Wix, J. (2006):

International Alliance for Interoperability, Industry Foundation Classes,

IFC2x Edition 3

Mindtools (2012): Brainstorming Generating many radical, creative ideas,

tilgængelig online: http://www.mindtools.com/brainstm.html

Noy, N. F., McGuinness, D.L. (2001). Ontology Development 101: A Guide to

Creating Your First Ontology. Stanford University, 25 pp.

OCCS (2006): OmniClass – A strategy for Classifying the Built Environment.

Table 32 – Services.

Sandberg, J. (2006): Brainstorming Works Best if People Scramble For Ideas

on Their Own, Wall Street Journal, tilgængelig online:

http://online.wsj.com/article/SB115015518018078348.html

Schwaber, K. and Sutherland, J. (2011): The Scrum Guide – The Definite

Guide to Scrum: The Rules of the Game.

Sutton, R. (2006): Eight Tips for Better Brainstorming, Blomber Busines

Week, tilgængelig online:

http://www.businessweek.com/innovate/content/jul2006/id20060726

_517774.htm

http://www.mindtools.com/brainstm.html


Sørensen, K.B. (2009): Virtual Models Linked with Physical Components in

Construction, DCE Thesis, Aalborg University. Tilgængelig online:

http://vbn.aau.dk/files/55290157/Virtual_Models_Linked_with_Physic

al_Components_in_Construction.pdf

Vico Software (2012): Model Progression Specification: On-line artikel på:

http://www.vicosoftware.com/model-progression-specification

W3C (2007): Web Ontology Language (OWL), W3C, Semantic Web,

tilgængelig online: http://www.w3.org/2004/OWL/#papers


Bilag A Udviklingsmetode

A.1 Indledning

I dette bilag beskrives metoderne, der ligger bag udviklingen af informati-

onsniveaumetoden, der er beskrevet i rapporten, samt det videre arbejde

med udvikling af indhold til metoden.

Projektet ”Metode og struktur for informationsniveauer” er en del af det

samlede Cuneco Classification System (CCS). Målet med CCS er at skabe et

fælles sprog, for udveksling af informationer, som øger produktiviteten for

alle aktører i byggebranchen.

Udviklingen af fælles sprog betegnes også ontologiudvikling, og defineres

som ”eksplicit specifikation af koncepter og relationen i mellem dem” (Gru-

ber, 1993). Inspirationen til udviklingsmetoderne benyttet i dette projekt

udspringer derfor af litteratur omhandlende ontologiudvikling.

Det er afgørende, at der anvendes en fælles udviklingsmetoder, for at sikre

et godt udviklingsforløb for dette og fremtidige informationsniveauprojek-

ter på tværs af fagområder, at der anvendes en fælles udviklingsmetode.

Udfordringen er imidlertid, at der ikke eksisterer en enkelt bedste metode

til sådanne projekter omhandlende formalisering af koncepter og deres

relationer, bl.a. fordi, der ikke kun findes én korrekt måde at definere dem

på (Gasevic et al., 2006). Noy & McGuinness (2001) beskriver en enkel me-

tode til udvikling af ontologier, hvilket på mange områder omfatter de

samme udfordringer og problemstillinger, som udviklingen af informations-

niveauer. Metoden udmærker sig ved at være systematisk, velafprøvet og

forholdsvis enkel at gå til. På denne baggrund vurderes den som anvendelig

til udviklingen af informationsniveauer. Som et led i en iterativ udviklings-

proces har metoden været anvendt og er blevet prototypetestet samt til-

passet af projektdeltagerene i forbindelse med udviklingen denne metode-

beskrivelse.

Udviklingsmetoden består af følgende steps her tilpasset udviklingen af

informationsniveauer for byggebranchen:

1. Fastlæg og beskriv gyldighedsområdet samt formålet med hvert in-

formationsniveau 2. Overvej at genbruge eksisterende klassifikationsstrukturer, meto-

der og specifikationer 3. Oplist vigtige termer, der skal indeholdes i definitionerne 4. Beskriv de overordnede definitioner af informationsniveauer inden-

for gyldighedsområdet 5. Definer forekomster af bygningsdelstyper pr. informationsniveau 6. Definer informationsniveauer for delsystemer eller grupper af

komponenter


7. Definer egenskabsdata for hvert informationsniveau 8. Definer restriktioner for egenskaber såsom tilladelige værdier samt

relationer og krav på tværs af fagområder 9. Test ved at skabe konkrete datasæt

I det følgende beskrives metodens anvendelse gennem en række eksem-

pler. Det er afgørende de udviklede informationsniveaudefinitioners succes,

at der i efterfølgende projekter sikres en operativ definition af indholdet i

de enkelte informationsniveauer.

Det er ligeledes vigtigt at forstå, at det stadig kræver viden, kreativitet samt

praktisk indsigt at udvikle informationsniveauer, der virker. Den eneste

måde at afgøre anvendeligheden af det endelige resultat er ved at evaluere

det gennem praktisk brug. Så derfor sikrer metoden alene ikke et godt re-

sultat, men skal ses som en hjælp til at guide processen med udviklingen af

informationsniveauer. Inden et tilfredsstillende resultat opnås, kan der

være behov for mange iterative gennemløb af de 9 steps i udviklingsmeto-

den.

A.2 Step 1 - Fastlæg og beskriv gyldighedsområdet

Det anbefales at starte udviklingen af informationsniveauer med at fast-

lægge og beskrive det gyldighedsområde, som informationsniveauerne skal

være gældende for. Dette omfatter besvarelsen af nogle grundlæggende

spørgsmål:

Hvilket område skal informationsniveauerne defineres for?

Hvad skal de bruges til?

Hvilken type problemstillinger skal informationsniveauerne løse?

Hvem skal bruge dem?

Besvarelsen af disse spørgsmål kan variere i takt med udviklingen af infor-

mationsniveauerne, men det vil alligevel være en hjælp til afgrænsning og

præcisering af de udviklede definitioner eksplicit at formulere et gyldig-

hedsområde.

Eksempel

Som et eksempel kan gyldighedsområdet fastlægges til resultatområdets 4

grupper af egenskabsdata: produkt-, placerings-, formegenskaber og græn-

sefladegenskaber for bygningsobjekter, det vil sige rum og bygningsdele.

Formålet og dermed anvendelsen kan fastlægges for de 6 informationsni-

veauer som herunder:

Informationsniveau Formål

1 Anskueliggøre

Kommunikere

Evaluere

Koordinere

Ideer og løsninger Ideer og løsninger Ideer og løsninger Ideer og løsninger

2 Anskueliggøre

Kommunikere

Løsningsforlag projektniveau



Evaluere

Koordinere



3 Anskueliggøre

Kommunikere

Evaluere

Koordinere

Løsningsforlag systemniveau




4 Anskueliggøre

Kommunikere

Evaluere

Koordinere

Bygbare løsninger

Montageforslag

Bygbare løsninger

Montageforslag

Bygbare løsninger

Montageforslag

Grænseflader

Tolerancer

5 Anskueliggøre

Kommunikere

Evaluere

Koordinere

Bygbare detailløsninger

Fremstillingsmetode


Fremstillingsmetode


Fremstillingsmetode

Grænseflader

Tolerancer

6 Anskueliggøre

Kommunikere

Evaluere

Koordinere


Fremstillingsmetode

Datagrundlag for automatisk

produktion

Datagrundlag for fremstil-

lingsmetode

Grænseflader

Tolerancer

De problemstillinger, som ønskes løst, kunne være udfordringer med afkla-

ring afgrænseflader mellem projektets aktører, og de primære brugere vil

være bygherrer, projekterende og udførende i byggeprocessen.

En måde at fastlægge gyldighedsområdet er også at fastlægge en række

kompetenceafklarende spørgsmål, som skal kunne besvares ud fra anven-

delsen af de definerede informationsniveauer. Disse spørgsmål vil være

nyttige at anvende i en første evaluering af de udviklede informationsni-

veauer.

Dette kunne være spørgsmål som:

Hvilke produktegenskaber for vinduer skal leveres af en arkitekt i

informationsniveau 3?

Hvem har ansvaret for tegning/modellering af udsparinger?

Hvem leverer grundlag for funktionskrav til facaderne og på hvilket informationsniveau?

Hvilke bygningsdele er specificeret i informationsniveau 2?

Hvilket informationsniveau skal et projektmateriale være på for at kunne anvendes som udbudsgrundlag i et funktionsudbud?


Hvis informationsniveaudefinitionerne efter endt udvikling kan besvare en

sådan liste af kompetenceafklarende spørgsmål inden for gyldighedsområ-

det, indikerer det, at definitionerne er anvendelige, og hvis ikke er informa-

tionsniveaudefinitionsarbejdet ikke færdigt.

A.3 Step 2 - Overvej at genbruge eksisterende klassifika-tionsstrukturer, metoder og specifikationer

Frem for at udvikle indholdet og systematikken i informationsniveauerne

fra bunden vil det næsten altid kunne svare sig at hente inspiration andre

steder. Det kan f.eks. være fra klassifikationssystemer, ydelsesbeskrivelser

eller internationale standarder.

Til dette projekt er der bl.a. hentet inspiration fra en række bips, buil-

dingSMART- og AIA-publikationer og -arbejdsmetoder:

bips CAD-manual 2008 (bips, 2008a)

AIA E202–2008 – BIM Protocol Document (AIA, 2008)

Bips objektstruktur 2008 (bips, 2008b)

bips A113 - Fordeling af projekteringsydelser og ansvar ved leve-rance og montage af elementer af beton og letklinkerbeton (bips, 2005)

DBK 2006 (bips, 2006)

Building information modelling — Information delivery manual — Part 1: Methodology and format (ISO, 2009)

Specifikationen for IFC2x Edition 3 (Liebich et al., 2006)

OmniClass (OCCS, 2006):

Desuden er andre relaterede internationale initiativer blevet afdækket og

anvendt, såsom det amerikanske Model Progression Specifikation (Vico

Software, 2012), Senate Property's BIM specification (Kiviniemi et al., 2007)

samt forskningsrapport om kravspecifikation (Kiviniemi, 2005) m.fl.

Dette har bidraget til indholdet i metoden såvel som indholdet i informati-

onsniveauerne. I den videre udvikling vil det ligeledes være vigtigt at af-

dække relevant baggrundsmateriale inden for det gyldighedsområde, som

fastlægges i step 1.

A.4 Step 3 - Oplist vigtige termer

Efter at grundlaget nu er på plads fra step 2, og gyldighedsområdet er fast-

lagt i step 1, er næste skridt at opliste vigtige termer, der skal være inde-

holdt og understøttet af informationsniveauerne. Dette er nyttigt for på et

tidligt tidspunkt at kunne diskutere eller forklare de emner, som skal kunne

indeholdes i informationsniveauerne, hvilke bygningsdele og egenskabsda-

ta, det drejer sig, om samt hvad de skal bruges til.

Denne oplistning af termer kan med fordel gennemføres som en brainstor-

ming-session blandt projektdeltagerne i den gruppe, som fastlægger infor-


mationsniveauerne inden for et givent gyldighedsområde. Der findes flere

metoder og gode råd vedrørende gennemførelse af en god brainstorming-

session, se f.eks. (Mindtools, 2012; Sandberg, 2006; Sutton 2006).

Nedenstående Figur 22 viser et kort eksempel på begyndelsen af en brain-storming omkring det overordnede indhold i informationsniveauerne, og kan anvendes som inspiration til at brainstorme videre fra:

Resultatet af brainstormingen vil fungere som en vigtig tjekliste for, om det

fra starten ønskede indhold og omfang kan rummes i de informationsni-

veaudefinitioner, som bliver fastlagt i de efterfølgende step.

Dette arbejde må ikke undervurderes. En mulig succes for informationsni-

veaumetoden kræver en terminologi, der på den ene side er tilstrækkelig

omfattende og entydig til, at den kan udnyttes som aftalegrundlag i bran-

chen. Omvendt må termerne ikke fremstå kunstige for branchens aktører.

A.5 Step 4 - Beskriv de overordnede definitioner af in-formationsniveauer inden for gyldighedsområdet

Grundlaget for informationsniveaudefinitionerne er nu på plads. Det næste

skridt er overordnet at fastlægge indholdet i de 6 informationsniveauer for

de fire grupper af egenskabsdata udvalgt som gyldighedsområde i step 1.

Dette er afgørende for, at informationsniveauerne for forskellige bygnings-

objekter får en fælles referenceramme, så der på tværs af fagområder op-

nås et afstemt indhold i den efterfølgende mere detaljerede udspecificering

af informationsniveauerne.

Dette kan gribes an ved at gennemgå listen af termer fra step 3 og fordele

dem inden for de 6 informationsniveauer. Før alle kategorier og informati-

onsniveauer er udfyldt, vil der typisk være behov for en række iterationer.

Udvikles informationsniveaudefinitioner inden for grupper af egenskabsda-

ta eller processer opstilles på tilsvarende vis 6 informationsniveauer. Det

kan f.eks. omhandle afklaring af udførelsesmæssige forhold, tidsplanlæg-

ning eller kvalitetssikring m.v.

Figur 21: Eksempel på begyndelsen af brainstorming session om termer relevante for informa-tionsniveauer.


Det er her værd at bemærke, at både det første og sidste informationsni-

veau udgør yderpunkter med henholdsvis det lavteste omfang af informati-

oner og det største omfang og detaljeringsniveau, hvorfor det i mange pro-

jekter vil være de fire midterste informationsniveauer, som vil være af inte-

resse.

I tabellen herunder er illustreret med et eksempel på, hvordab informati-

onsniveauer kan fastlægges på et overordnet niveau for bygningsobjekter

generelt. Som eksempel bruges informationsniveau 3. Funktionskrav om-

handler, som navnet beskriver, de krav, der stilles til bygningsobjekter, og

de øvrige fire områder fastlægger omfang, konkretisering og detaljering af

informationer for bygningsobjekters egenskaber.

Område Informationsniveau 3

Funktionskrav Funktion

Forsyning

Performance

Areal & Volumen

Eksisterende forhold

Kvalitetssikringskrav

Udførelsesforhold

Kvalitetssikringskrav

Sikkerhed

Driftskrav

Grænseflader

Certificering

Sikkerhed & sundhed

Primære bygningsd. | Niv 3

CCS

Infrastruktur | specifik

Hovedsystemniveau

Rum | Zone | Brutto | Netto

Hovedsystemniveau

Hovedsystemniveau

Hovedsystemniveau

Hovedsystemniveau

Hovedsystemniveau

Hovedsystemniveau

Hovedsystemniveau

Hovedsystemniveau

Hovedsystemniveau

Produktegenska-

ber

Bygningsdelstype

Rumtype

Materialer

Udstyr

Inventar

Udførelsesforhold

Specifikation | Niv 3 CCS

Funktion og zone

Delsystemniveau

Type | Armaturer

Type | Fast inventar

Hovedsystemniveau

Placerings-

egenskaber

Bygning

Rum

Bygningsdele

Mål

Relation til modulsystem

Eksakt lokalisering og oriente-

ring

Eksakt placering | Niv 3 CCS

Detailmål | Delsystemniveau Formegenskaber Bygning

Rum

Bygningsdele

Sammensatte BD

Komplekse tværsnit

Armatur og udstyr

Fast inventar

Specifik ydre geometri

Eksakt form

Eksakt facon og profil | Niv 3

CCS

Solid repræsentation

Omsluttende tværsnit

Symbolsk repræsentation

Symbolsk repræsentation

Grænseflade-

egenskaber

Samlinger

Udsparinger

Tolerancer

Primære bygningsd. | Niv 3

CCS For hovedføringsveje

Systemniveau


Ambitionen med ovenstående eksempel er ikke, at præsentere et sæt fær-

digt udviklede informationsniveauer, men derimod at eksemplificere hvor-

dan metoden er tænkt anvendt i efterfølgende projekter.

A.6 Step 5 - Definer forekomster af bygningsdelstyper pr. informationsniveau

De overordnede informationsniveauer vil ikke i alle tilfælde være tilstræk-

kelige til at løse de problemstillinger, som blev fastlagt under step 1. Det

næste skridt er at fastlægge hvilke bygningsdele, der forekommer på de

enkelte informationsniveauer. Dette kan med fordel gøres i et skema som

vist på Figur 23. Eksemplet er udarbejdet for VVS bygningsdele og som illu-

streret anvendes farvekodning til at indikere om en bygningsdel er inde-

holdt i projektmaterialet på et givent informationsniveau. Nogle bygnings-

dele vil ikke eksplicit være repræsenteret i informationsniveau 1 og 2, hvor

mange informationer hovedsageligt vil være repræsenteret for bygningen

som helhed eller på rumniveau.

Som illustreret for f.eks. rør i informationsniveau 3 kan der i skemaet også

angives, at kun rør over en hvis dimension er indeholdt i det pågældende

informationsniveau.


A.7 Step 6 - Definer informationsniveauer for delsyste-mer eller grupper af komponenter

Der findes i princippet uendeligt mange bygningsdele, og for ikke at skulle

definere informationsniveauer for dem alle og for at undgå at skulle genta-

ge mange ensartede definitioner udarbejdes informationsniveau definitio-

nerne på delsystemer eller grupper af komponenter med sammenfaldende

Figur 22: Eksempel på fastlæggelse af forekomster af bygningsdele pr. informationsniveau.


egenskabsdata. Dette gør arbejdet med specifikation og vedligeholdelse af

informationsniveauer overkommeligt og definitionerne overskuelige.

Figur 23: Informationsniveaudefinition 1-3 for delsystemet vinduesparti.

Figur 24: Informationsniveaudefinition 4-6 for delsystemet vinduesparti.


Fastlæggelse af egenskabsdata, samt hvilke egenskabsdata, der skal inde-

holdes i informationsniveauerne, kan blive en omfattende opgave at gen-

nemføre. Derfor kan det være hensigtsmæssigt i første omgang at gennem-

føre informationsniveaudefinitionen til og med step 6 og herfra springe til

step 9 – ”Test ved at skabe konkrete datasæt”.

Informationsniveaudefinitionerne til og med step 6 vil give den danske byg-

gebranche et vigtigt grundlag for afklaring af omfang, konkretisering og

detaljering af informationer, der skal indgå i en leverance. Det kan vise sig

hensigtsmæssigt at evaluere resultatet af informationsniveaudefinitionerne

til step 6 gennem praktisk anvendelse i nogle projekter inden yderligere

specificering foretages.

Step 7 og 8 er medtaget for at betone og facilitere det store potentiale sy-

stematisk brug af CCS giver for en langt mere effektiv produktion i fremti-

den. Det er forfatternes forhåbning, at specielt leverandører vil bidrage til

at tydeliggøre på hvilken form og med hvilket indhold et projekt skal levere

informationer for at muliggøre størst mulig automatisk produktion. De be-

skrevne step er endvidere udarbejdet med henblik på, at et projekt benyt-

ter leverandørdefinerede objekter som input i en bygningsmodel, og der-

med bør specificeres, hvilke informationer leverandøren behøver fastlagt

for sin produktion af bygningsdelen.

A.8 Step 7 - Definer egenskabsdata for hvert informati-onsniveau

Skemaet, der er vist i Figur 26 anvendes til at fastlægge hvilke egenskabsda-

ta, der er indeholdt i hvert informationsniveau. Her anføres i de blå felter

om en given egenskab er skitseret eller specificeret på hvert informations-

niveau. Egenskabsdata markeret med en * angiver, at de er obligatoriske,

de øvrige egenskabsdata er, med mindre anden aftale indgås, valgfrie.

Som ved definering af informationsniveauer for delsystemer i step 6 er

egenskabsdataene ikke indeholdt i alle informationsniveauer, hvilket indi-

keres med de grå felter. Det er desuden vigtigt, at der er overensstemmelse

mellem skemaerne for egenskabsdata og definitionerne af informationsni-

veauer for delsystemer.

Omfanget af egenskabsdata pr. bygningsdelstype fastlægges af cunecos

egenskabsdataprojekt med udgangspunkt i relevant baggrundsmateriale

fastlagt under step 2 for det pågældende gyldighedsområde.

Egenskabsdatakortet vist i Figur 26 er fastlagt med udgangspunkt i de egen-

skabsdata, der er indeholdt i specifikationen af et vindue i IFC 2x3. IFC spe-

cifikationen vil for mange bygningsdele være tilstrækkelig som udgangs-

punkt for en egenskabsdataliste, og anbefales brugt som udgangspunkt, ind

til cunecos udviklingsprojekt omhandlende egenskabsdata er færdigt. Obli-

gatoriske egenskabsdata markeres i skemaet med en *.


A.9 Step 8 - Definer restriktioner for egenskaber, såsom tilladelige værdier samt relationer og krav på tværs af fagområder

For at kunne automatisere dataanalyse og datahåndteringsprocesser er det

væsentligt at få kortlagt sammenhængen mellem individuelle egenskabsda-

ta og deres tilladelige værdier. Dette er som illustreret i Figur 27 en omfat-

tende opgave, der stiger proportionalt med antallet af egenskabsdata. I

skemaet er som eksempel med kryds eller beskrivende tekst angivet hvilke

egenskabsdata der kræves fastlagt, inden en given egenskab kan specifice-

res. Tilsvarende angives hvilke egenskaber, der påvirker andre.

Et færdigudviklet step 8 er ikke en forudsætning for at komme i gang med

at anvende informationsniveaumetoden, men det vil dog som minimum

være hensigtsmæssigt at overveje relationerne mellem informationsni-

veauer ved udviklingen af best practice templates for leverancespecifikati-

oner.

Figur 25: Eksempel på skema til fastlæggelse af egenskabsdata pr. informationsniveau. Egenskabsdata for et vindue er anført i eksemplet. Obligatoriske egenskabsdata er markeret med en *.


Skemaet kan med fordel udbygges med beskrivelse af relationen mellem

egenskabsdataene samt definition i Web Ontology Language (OWL) eller

lignende sprog egnet til videnrepræsentation. For en nærmere introduktion

til OWL se W3C (2007). Dette vil bl.a. give mulighed for at gennemføre au-

tomatiske ræsonnementer i forbindelse med projektopfølgning eller auto-

matisere kvalitetssikrings- og valideringsprocesser.

For hver egenskab bør der også fastlægges relevante intervaller for tillade-

lige værdier eller tilladelige variationer i informationsniveauer på tværs af

egenskabsdata. Dette er ligeledes nyttigt i forbindelse med kvalitetssikring

og opfølgning på validiteten af afleverede informationer.

Der kan f.eks. opstilles betingelser om, at der for at levere informationer

om installationstekniske bygningsdele på informationsniveau 4 skal forefin-

des funktionskrav minimum på informationsniveau 3.

A.10 Step 9 - Test ved at skabe konkrete datasæt

Som det sidste og vigtigste step i udviklingen af succesfulde informationsni-

veaudefinitioner udføres løbende praktiske afprøvninger og evalueringer af

de fastlagte informationsniveaudefinitioner. Dette gøres ved at udfylde

leverancespecifikationer og tilhørende informationsniveaudefinitioner for

konkrete bygningsobjekter og anvende dem i praktiske informationsudveks-

linger mellem forskellige aktører i byggebranchen. Desuden tegnes og 3D-

modelleres bygningsobjekterne i de forskellige informationsniveauer.

Der evalueres på resultatet af disse informationsudvekslinger, og dette

anvendes i efterfølgende iterationer af udviklingen.

I Figur 27 herunder er vist et af de tidlige eksempler på arbejdsgruppens skitse af et vindue på fire informationsniveauer. Tilsvarende er tidligere i rapporten i Tabel 1 og Tabel 2 vist en søjle i 6 forskellige informationsni-veauer. Beskrivelsen skal ses som en eksemplificering og er ikke en fyldest-gørende beskrivelse af tilstrækkelige informationer pr. informationsniveau.

Figur 26: Eksempel på egenskabsdata relationsskema.


Figur 27: Tidlig afprøvning af specificering af fire informationsniveauer for et vindue.

A.11 Opsummering af udviklingsmetode

Det er gennem en successiv udviklingsmetode i 9 step beskrevet, hvordan

informationsniveauerne fastlægges, og der er givet en række anbefalinger

til, hvordan der opnås en brugbar metode. Efter at have læst, fulgt og brugt

reglerne og vejledninger beskrevet gennem denne rapport, er der en ting,

det er vigtigt at huske: ”Der findes ikke én enkelt rigtig informationsniveau-

definition for et gyldighedsområde.” At skabe gode informationsniveau-

definitioner er en kreativ proces, og ikke to definitioner fastlagt af forskelli-

ge personer vil give det samme resultat. Derfor er det vigtigt i et fælles pro-

jekt for den danske byggebranche som cuneco, at få fastlagt en de facto

standard, der kan bruges i de fleste projekter og samarbejdsformer.


Bilag B – Termer og definitioner

Agil systemudviklingsmetode: Er en fællesbetegnelse for en række soft-

wareudviklingsmetodikker, hvor vægten ligger på løbende at levere værdi

til kunden gennem iterativ udvikling. Dvs. måder at planlægge og kontrolle-

re softwareudvikling, hvor man hurtigt kan levere en ny version af soft-

waren, når der kommer ændringsønsker fra slutbrugerne. Extreme Pro-

gramming og Scrum er eksempler på agile metodikker, mens vandfaldsmo-

dellen er modsætningen til agile metoder (Wikipedia).

Bygningsobjekt: Objekt relevant for byggebranchen (oversat efter ISO

12006-2), f.eks. et rum, en plads eller en bygningsdel.

Bygningsdel: En fast (dvs. ikke flydende eller på gasform) materiel del af en

bygning, der har en fysisk afgrænsning (oversat efter ISO 12006-2, construc-

tion entity part).

Data: Faktuel information (såsom målbarbare værdier eller statistik) brugt

som grundlag for ræsonnement, diskussion, eller beregning (oversat efter

The Merriam-Webster Dictionary).

Delsystem: Bygningsdel med selvstændig egenfunktion som udgøres af en

samling af indbyrdes tilpassede komponenter og eventuelle andre delsy-

stemer.

Domæne (engelsk domain): En sfære af viden, indflydelse eller aktivitet

(oversat efter The Merriam-Webster Dictionary).

Egenskab: En kvalitet eller et karaktertræk ved en ting (objekt) eller en ind-

virkning et objekt kan have på et andet eller dets betydning (oversat efter

Merriam-Webster Learner’s Dictionary).

Egenskabsdata: Data om egenskaber ved objekter.

Egenskabsdatasæt: Gruppering af egenskabsdata.

Hovedsystem: Bygningsdel med selvstændig egenfunktion betragtet som

en samlet helhed af delsystemer og/eller komponenter.

Information: Fakta eller detaljer om et emne (oversat efter Merriam-

Webster Learner’s Dictionary).

Informationsniveau: Omfang, konkretiserings- og detaljeringsniveau for

informationer om bygningsobjekter.

http://da.wikipedia.org/wiki/Scrum


Klasse (engelsk: class): En gruppe, sæt, eller slags (objekt) med fælles egen-

skaber (oversat efter The Merriam-Webster Dictionary).

Komponent: Bygningsdel med selvstændig egenfunktion som kan samles til

større helheder.

Ontologi: Eksplicit specifikation af koncepter og relationen i mellem dem

(Gruber, 1993).

Objekt (fysisk). Noget der kan opfattes af en eller flere sanser, specielt

syns- eller følesanser, en materiel genstand (Oversat efter The Free Dicti-

onary by Farlex).

Objekt (digitalt): En datastruktur i objekt-orienteret programmering (eller

bygningsmodellering), som kan indeholde funktioner, data, variable og an-

dre datastrukturer (Oversat efter The Merriam-Webster Dictionary).

System: En gruppe af samvirkende, sammenhørende eller indbyrdes af-

hængige elementer (objekter), der former en kompleks helhed (Oversat

efter The Free Dictonary By Farlex).

metode og struktur for informati- onsniveauer

Documents