Coins ontwikkeling- en Toepassingsfase



Dovnload 63.37 Kb.
Datum22.07.2016
Grootte63.37 Kb.

Hoofdpagina


COINS Ontwikkeling- en Toepassingsfase

Documentatie van COINS Engineering Methode (CEM) en COINS Bouw Informatie Model (CBIM).


Werk in uitvoering!

  1. Inleiding

  2. Uitgangspunten

  3. COINS Engineering Methode - CEM

    1. Introductie Systems Engineering

    2. Systems Engineering - proces overzicht

    3. De toestand van een bouwdeel

    4. Verantwoordelijkheden en informatie

    5. Termen en definities

  4. COINS Bouw Informatie Model - CBIM

    1. Functional Requirements

    2. C-BIM definitie

    3. Tool Mockup

  5. Praktijkproject RSS/Lunetten - aansluiting IT-partner

  6. Casus Kippenhok

  7. Achtergrond documentatie

  8. Link naar wiki van onderzoeksfase

Inleiding


COINS heeft de ambitie bij te dragen aan procesvernieuwing in de bouw. Het streven is om het bouwproces te verbeteren door slim gebruik van de informatie van 3D-bouwobjecten. In het COINS-programma wordt een aansluiting gemaakt op vier ontwikkelingen die buitengewoon belangrijk zijn voor de bouwsector. Deze ontwikkelingen zijn: system engineering, objectbenadering, 3D-modelleren en procesintegratie. COINS maakt deze aansluiting door sectorbrede afspraken beschikbaar te maken over de informatie van bouwobjecten en de daaraan gerelateerde procedures. In 2007 zal een aanzet voor deze afspraken beschikbaar gemaakt worden ten behoeve van de thema’s functioneel specificeren en kostenramingen.

Deze wiki bevat de beschrijving van de COINS Engineering Methode (CEM) en COINS Bouw Informatie Model (CBIM) zoals deze zich ontwikkelen tijdens de Ontwikkel- en Toepassingsfase van het COINS-programma. De status van de inhoud is "Werk in uitvoering".


COINS Engineering Methode - CEM


De COINS Engineering Methode (CEM) is een verzameling samenhangende afspraken over werkwijze en inrichting van het proces van de totstandkoming van bouwwerken. Bij de samenstelling van de afspraken wordt zoveel mogelijk gebruik gemaakt van beschikbare en geaccepteerde methodieken en standaarden. Methodieken die voor de CEM van belang zijn, betreffen o.a.:

  • Systems engineering

  • VISI systematiek

Een belangrijk uitgangspunt voor de CEM wordt gevormd door de methodiek van Systems Engineering. Als referentie voor deze methodiek maken we gebruik van System Engineering Fundamentals SEF01 [1] - Department of Defense System Management College January 2001. Om eenvoudig de relatie naar naar dat document wordt in dit document vooral het Engelstalige begrippenkader gebruikt. De keuze voor de toepassing van de methodiek van systems engineering staat niet op zichzelf; recent hebben Rijkswaterstaat en ProRail, in samenwerking met brancheorganisaties, een Leidraad Systems Engineering voor de Bouwsector [2] uitgebracht.

De VISI systematiek is een onderdeel van de communicatiestandaard VISI[3]. Deze standaard wordt in de bouwsector gebruikt voor de inrichting van managementcommunicatie. Voor de CEM maken we gebruik van de volgende onderdelen van VISI:



  • De rol of actor: het ontwerp-/bouwproces wordt uitgevoerd door bedrijven of organisaties die één of meerdere rollen vervullen; informatieoverdracht vindt plaats tussen rollen; het rolbegrip wordt gebruikt om de verantwoordelijkheid m.b.t. informatie vast te leggen.

  • Transactie: tussen rollen wordt informatieovergedragen; de afspraken over het proces en de inhoud van informatieoverdracht worden vastgelegd in een transactie.

Een verdere toelichting op de CEM is opgenomen in de volgende hoofdstukken:

  1. Introductie CEM

  2. Systems Engineering - proces overzicht

  3. De toestand van een bouwdeel

  4. Verantwoordelijkheden en informatie

  5. Termen en definities

Introductie Systems Engineering

Inhoud


[Niet tonen]

  • 1 Overzicht Systems Engineering

  • 2 Development phasing

  • 3 Het systems engineering process

  • 4 Life Cycle Integration

  • 5 Eisen aan informatieverwerking

[bewerken]

Overzicht Systems Engineering


In de documentatie van systems engineering zien we dat deze methodiek bewerkstelligd wordt door de integratie van drie belangrijke activiteiten, te weten:

  • Development phasing dat het ontwerpproces beheerst en baselines aanbiedt voor de coordinatie van ontwerpinspanningen

  • Het systems engineering process dat een structuur biedt voor het aanpakken van ontwerpproblemen

  • Life Cycle Integratie dat de probleemeigenaar in het ontwerpproces betrekt en waarborgt dat een goed en juiste product ontwikkeld wordt dat waardevol is tijdens de gehele levensduur.

[bewerken]


Development phasing


De ontwikkeling van een systeem doorloopt gewoonlijk een aantal fasen of niveaus van ontwikkeling. Een verdeling kan bijvoorbeeld zijn:

  • Concept studie

  • Systeem definitie

  • Voorontwerp

  • Detailontwerp

In principe is deze fasering vrij te kiezen en is afhankelijk van de aard van een te ontwikkelen bouwwerk. Deze fasering wordt geïdentificeerd met behulp van het begrip 'toestand'. Bij de voorbereiding van een project worden de van belang zijnde toestanden vastgesteld.

Het system engineering proces wordt toegepast op ieder niveau van ontwikkeling, één niveau tegelijk, leidend tot beschrijvingen die gewoonlijk 'Configuration baselines' genoemd worden. Dit resulteert in een serie van configuration baselines, één voor ieder ontwikkelingsniveau (toestand).

Een substantiële ontwikkeling op een bepaald niveau in de systeem hiërarchie dient niet te gebeuren voordat vastgesteld is dat de configuration baseline op een hoger niveau compleet is, stabiel is, en gecontroleerd. In de figuur hierboven is het ontwikkelingsstadium met een grijze balk aangeduid en het stabiele stadium met een zwarte balk.

[bewerken]


Het systems engineering process


In de volgende figuur zijn de fundamentele activiteiten van system engineering afgebeeld. Dit betreft Requirement Analysis, Functional Analysis and Allocation, en Design Synthesis. Deze activiteiten worden in balans gehouden door technieken en gereedschappen die gezamenlijk System Analysis and Control genoemd worden. De genoemde activiteiten zullen in deze wiki verder uitgewerkt worden, inclusief de daarmee samenhangende informatieve aspecten.

Gedurende het systems engineering process ontstaan beschrijvingen waarmee het toekomstig systeem wordt vastgelegd en kan worden begrepen. In het algemeen worden drie universele beschrijvingen onderkend om de belangrijke aspecten van het systeem vast te leggen:



  • Functional architecture

  • Physical architecture

  • System architecture.

Deze architectures zijn noodzakelijke onderdelen voor ondersteuning van het systems engineering process.

De Functional architecture is een beschrijving van de 'allocated functional and performance requirements'. De Physical Architecture is gericht op de beschrijving van het product en hoe het is opgedeeld in subsystemen en componenten. De System architecture beschrijft alle producten (inclusief services) die nodig zijn om het systeem te laten bestaan, en beschrijft daarom alle processen die nodig zijn voor ontwikkeling, productie, in bedrijfstelling, beheer, training etc.

Vooalsnog zullen we ons concentreren op het bouwwerk zelf en daarom de nadruk leggen op de Functional architecture en Physical architecture.

[bewerken]


Life Cycle Integration


Life cycle integration wordt bereikt door integrale ontwikkeling, dat wil zeggen dat alle behoeften die voortkomen uit de levenscyclus, in het ontwikkelproces worden meegenomen. Eén van de manieren om dit te bereiken is door de inzet van Integrated Product Teams (IPTs). Dit onderwerp zal hier verder niet uitgewerkt worden.

Life cycle functions zijn de karakteristieke acties (toestanden) die verbonden zijn aan de system life cycle. In het algemeen worden de volgende acht activiteiten onderscheiden: ontwikkeling, productie, bouw, inbedrijfstelling, operation, beheer en onderhoud, sloop, training en verification. Deze acties dekken de levencyclus af van de "wieg tot het graf". Voor COINS zullen we met het toestandsbegrip vooral richten op de toestand van het bouwwerk zelf.

[bewerken]

Eisen aan informatieverwerking


Kijken we terug op de inhoud van dit hoofdstuk, dan kunnen we enkele wensen t.a.v. informatieverwerking formuleren. Een informatiesysteem gebaseerd op CEM moet in staat zijn om:

  • Vast te leggen welke baselines voorzien worden voor een bouwwerk X en aan welke toestanden die baselines gekoppeld zijn

  • Te rapporteren welke baselines beschikbaar zijn

  • Te rapporteren wat de status is van een baseline

  • Een rapportage te geven van alle informatie die behoort tot een baseline

  • De informatie van het bouwwerk vast te leggen, in het bijzonder de Functional architecture en Physical architecture.

Systems Engineering - proces overzicht

Inhoud


[Niet tonen]

  • 1 Het proces

  • 2 Systems Engineering Process Inputs

  • 3 Requirements Analysis

  • 4 Functional Analysis/Allocation

  • 5 Requirements Loop

  • 6 Design Synthesis

  • 7 Design Loop

  • 8 Verification

  • 9 System Analysis and Control

  • 10 Systems Engineering Process Output

  • 11 Eisen aan informatieverwerking

[bewerken]

Het proces


In het vorige hoofdstuk hebben we de hoofdactiviteiten van het systems engineeering proces beschreven. In dit hoofdstuk gaan daar wat dieper op in en proberen we vast te leggen welke aspecten in de scope van CEM zullen gaan vallen. In het volgende plaatje is een meer gedetailleerd beeld gegeven.



Het Systems Engineering Proces ref.SEF01

Het Systems Engineering Process (SEP) is een iteratief en recursief probleemoplossingsproces. Het transformeert behoeften en eisen in een set van product en proces beschrijvingen, genereert informatie voor besluitvorming en genereert input voor het volgende niveau van ontwikkeling. Het proces wordt sequentieel uitgevoerd, één niveau tegelijkertijd, terwijl bij ieder niveau van ontwikkeling meer detail en definitie toegevoegd wordt. De onderdelen van het proces zijn: inputs en outputs; requirements analysis; functional analysis and allocation; requirements loop; synthesis; design loop; verification; en system analysis and control.

[bewerken]


Systems Engineering Process Inputs


De inputs bestaan vooral uit de behoeften van de probleemeigenaar, zijn doelstellingen, eisen en projectrandvoorwaarden. De inputs kunnen ook bestaan uit, maar zijn niet beperkt tot, de resultaten van een vorige toepassing van het systems engineering process, zijnde een configuration baseline.

[bewerken]


Requirements Analysis


De eerste stap van het Systems Engineering Process is het analyseren van de inputs. Requirements analysis wordt toegepast om functionele en performance eisen te ontwikkelen; dat wil zeggen: eisen van de probleemhebber worden vertaald in een set eisen die vastleggen wat het systeem moet doen en hoe goed het moet presteren. De systems engineer moet ervoor zorgen dat de eisen begrijpelijk zijn, ondubbelzinnig, compleet en specifiek.

Requirements analysis moet duidelijk maken en vastleggen van de functionele eisen en de ontwerp-randvoorwaarden/beperkingen. Functionele eisen definieren kwantiteit (hoeveel), kwaliteit (hoe goed), prestatie (hoe ver), tijdvoorwaarden (wanner en hoe lang), en beschikbaarheid (hoe vaak). Ontwerp-randvoorwaarden/beperkingen definieren de factoren die de ontwerpvrijheid beperken, zoals omgevingscondities of -limieten, of klantspecifieke of wettelijke standaarden.

[bewerken]

Functional Analysis/Allocation


Het doel van deze systems engineering activiteit is om de functionele, prestatie en overige eisen te vertalen naar een samenhangende beschrijving van functies die weer een vertrekpunt vormt voor de volgende activiteit 'design synthesis' waarin de technische/fysieke oplossing totstandkomt.

Functional analysis vindt plaats door hoger-gelegen functies, op basis van de resultaten van de requirements analysis te verdelen in lager-gelegen functies. De prestatie eisen die verbonden waren met de hoger-gelegen functies worden toegewezen aan de lager gelegen functies. Het resultaat is een beschrijving van het product in termen van wat het logisch doet en in termen van vereiste prestaties. Deze beschrijving wordt vaak de functional architecture van het product genoemd.



Functional analysis and allocation biedt een beter begrip van wat een systeem moet gaan doen, op welke manier dat kan gebeuren, en in bepaalde mate, de prioriteiten en conflicten die samenhangen met de lager-gelegen functies. Het biedt informatie die essentieel is om tot een optimale technische/fysieke oplossing te komen. Hulpmiddelen die gebruikt worden bij functional analysis and allocation zijn Functional Flow Block Diagrams, Time line analysis en de Requirements Allocation Sheet. Voor de toepassing bij bouwwerken zullen naar de twee eerste gereedschappen beperkt toegepast worden. De derde, de Requirement Allocation Sheet is ook bij bouwwerken een wezenlijk hulpmiddel.

[bewerken]

Requirements Loop


Het uitvoeren van de functional analysis and allocation resulteert in een beter begrip van de eisen en zou kunnen leiden tot herbeschouwing van de requirements analysis. Iedere geïdentificeerde functie moet teruggeleid kunnen worden tot een eis. Dit iteratieve proces van opnieuw bekijken van de eisen als gevolg van de functional analysis and allocation wordt betiteld als de 'requirments loop'.

[bewerken]


Design Synthesis


Design synthesis is het proces waarin de definitie van een product ontstaat in fysieke/technische vorm. Het resultaat wordt veelal de physical architecture genoemd. Ieder onderdeel moet verbonden zijn met tenminste één functie, en ieder onderdeel mag meerdere functies ondersteunen. De physical architecture is de basis voor het genereren van specificaties en baselines.

[bewerken]


Design Loop


De design loop komt overeen met de requirements loop die hiervoor is beschreven. De design loop is het proces van opnieuw beschouwen van de functional architecture om te verifiëren of het fysieke/technische ontwerp de vereiste functies aan kan op het gewenste niveau. De design loop geeft gelegenheid om opnieuw in ogenschouw te nemen hoe het systeem aan zijn doelstellingen zal voldoen, en dit helpt om het ontwerp te optimaliseren

[bewerken]


Verification


Voor iedere toepassing van het systems engineering process zal de fysieke/technische oplossing vergeleken worden met de eisen. Dit deel van het proces wordt de verification loop genoemd, of kortweg verification. Baseline documentatie die ontwikkeld is gedurende het systems engineering process moet de methoden beschrijven van verificatie van iedere requirement. Aangewezen methoden van verificatie zijn o.a.: onderzoek, demonstratie, simulatie, en testen.

[bewerken]


System Analysis and Control


System analysis and control heeft betrekking op activiteiten van technisch management die nodig zijn om voortgang te meten, het evalueren en selecteren van alternatieven, en het documenteren van beslissingen. Voor wat betreft system analysis zullen wij ons op termijn richten op de mogelijkheden om trade-off studies te doen. Voor wat betreft Control zullen we ons vooral richten op de mogelijkheden om configuration management uit te voeren. In zijn algemeenheid betekent dit, dat we in staat moeten zijn om een beschrijving te leveren van:

  • Het bouwwerk dat naar verwachting gerealiseerd moet worden

  • het bouwwerk dat geleverd is (as-built)

  • De modificaties die uitgevoerd zijn na oplevering.

Naast de beschrijving van het bouwwerk behoort ook de documentatie die behoort bij de afhandeling van een wijzigingsvoorstel tot het configuratie management. In het engels wordt gesproken over een Engineering Change Proposal of kortweg ECP. De afhandeling van een wijzigingsvoorstel heeft het karakter van berichtuitwisseling en besluitvorming. Gezien dit karakter ligt hier een aansluiting op de communicatiestandaaard VISI voor de hand.

[bewerken]


Systems Engineering Process Output


De output van het proces is afhankelijk van het niveau van ontwikkeling. De output bevat de decision database en de configuration baseline die specificaties bevat die uitgewerkt zijn overeenkomstig het niveau van de baseline. In het algemeen gesteld is het alle informatie waarmee de product configuratie of processen die nodig zijn om dat product te ontwikkelen, beschreven en beheerst kunnen worden.

[bewerken]


Eisen aan informatieverwerking


Kijken we terug op de inhoud van dit hoofdstuk, dan kunnen we enkele wensen t.a.v. informatieverwerking formuleren. Een informatiesysteem gebaseerd op de CEM moet in staat zijn om:

  • De eisen vast te leggen die behoren bij een bepaald niveau van baseline

  • Functies te definiëren op een bepaald niveau van baseline als resultaat van een verdeling van functies op een hoger gelegen niveau

  • Prestatie-eisen die verbonden waren met hoger gelegen functies moeten toegewezen kunnen worden aan lager gelegen functies

  • De logische relaties vast te leggen, die aanwezig zijn tussen functies

  • Een rapportage te geven van een tabel waarin de relatie tussen eisen en functies beschreven wordt (requirements allocation sheet)

  • De definitie van een product in fysieke/technische vorm vast te leggen (physical architecture)

  • De relatie vast te leggen tussen een fysiek onderdeel en één of meer functies

  • Een rapportage te geven van de relatie tussen de fysieke onderdelen en functies (functional/physical matrix)

  • Te rapporteren over de verbinding tussen eisen en fysiek onderdelen

  • De besluiten vast te leggen die genomen zijn bij de totstandkoming van een baseline

  • Documentatie te leveren over voorgestelde en uitgevoerde wijzigingen.

De toestand van een bouwdeel




Een toestandsovergang ontstaat door een besluit

Een bouwdeel (fysiek object, functievervuller, technische oplossing)doorloopt een Product Life Cycle, van ontwerp tot aan sloop. Waar een bouwdeel zich bevindt in het proces wordt vastgelegd door de Toestand (~status). Tijdens de voorbereiding van een bouwproject wordt bepaald welke toestanden van belang zijn om bij te houden. Door deze keuze wordt het proces gefaseerd. Het volgende lijstje is een voorbeeld van mogelijke toestanden:


  • Conceptueel ontwerp/In bewerking

  • Conceptueel ontwerp/Goedgekeurd

  • Conceptueel ontwerp/In wijziging

  • Vrijgegeven voor Technisch ontwerp

  • Technisch ontwerp/In bewerking

  • Technisch ontwerp/Goedgekeurd

  • Technisch ontwerp/In wijziging

  • Vrijgegeven voor inkoop

Toestandsovergangen ontstaan door een besluit of een verzoek van een bepaalde rol. Het hier aangegeven schema laat zien hoe de toestandsovergangen ontstaan. Zo'n schema noemen we een toestandsdiagram.

Toestanden vertonen twee aspecten:



  • de fase van de levenscyclus van een fysiek object

  • een fase binnen de levenscyclus die veel te maken hebben met goedkeuren en vrijgeven

Verantwoordelijkheden en informatie




De organisatie van een bouwproject afgebeeld in een interactiediagram

Voor een efficiënte uitvoering van het project is nodig dat duidelijk is wie verantwoordelijk is voor welke informatie. Deze verantwoordelijkheid wordt gekoppeld aan rollen. Tijdens de voorbereiding van een project wordt bepaald welke rollen nodig zijn om het project uit te voeren. Bij de uitwerking van de projectorganisatie worden rollen toegewezen aan organisaties.

Informatieoverdracht vindt plaats tussen rollen. Rollen zijn onderling verbonden door middel van transacties. De afspraken over informatieoverdracht tussen twee rollen worden vastgelegd in de transactie die deze twee rollen verbindt. Zaken die vastgelegd worden zijn o.a.:



  • Welke essentiële informatie-onderdelen geleverd en beschikbaargesteld moet worden (De ontwerper van de installatie wil graag het ontwerp van de betonconstructie on-line tot zijn/haar beschikking hebben)

  • Bij welke toestand van de objecten de verantwoordelijkheid aanvangt en bij welke toestand van de objecten de verantwoordelijkheid eindigt (na goedkeuring van het ontwerp van de betonconstructie en vrijgave voor fabricage gaat de verantwoordelijkheid voor de informatie van de objecten over naar de rol die verantwoordelijkheid draagt voor de fabricage)

  • Met welke rollen/Informatie-onderdelen afgestemd dient te worden

In internationaal verband is er een standaardisatieontwikkeling die IDM genoemd wordt (Information Delivery Manual - ISO TC 59/SC 13/WG 8). IDM heeft de ambitie om tot een standaard te komen voor het proces van informatieoverdracht. Vanuit COINS proberen we aansluiting te krijgen op de ontwikkeling van IDM.

Termen en definities


BL Baseline Het system engineering proces wordt toegepast op ieder niveau van ontwikkeling, één niveau tegelijk, leidend tot beschrijvingen die gewoonlijk 'Configuration baselines' genoemd worden.

CAD Computer-Aided Design

CAE Computer-Aided Engineering

CAM Computer-Aided Manufacturing

CASE Computer-Aided Systems Engineering

CATIA Computer-Aided Three-Dimensional Interactive Application

CCB Configuration Control Board

CCR Contract Change Request

CDR Critical Design Review

CDRL Contract Data Requirement List

CDS Concept Design Sheet

CE Concept Exploration

CI Configuration Item

CM Configuration Management

CM Control Manager

CSCI Computer Software Configuration Item

DDR Detail Design Review

DID Data Item Description

DoD Department of Defense

DT Developmental Testing

DTC Design To Cost

DT&E Developmental Test and Evaluation

EC Engineering Change

ECP Engineering Change Proposal

EDI Electronic Data Interchange

EIA IS 632 Electronic Industries Association Interim Standard 632, on Systems Engineering

EIA IS-649 Electronic Industries Association Interim Standard 649, on Configuration Management

FEO Field Engineering Order

FFBD Functional Flow Block Diagram

FMECA Failure Modes, Effects, and Criticality Analysis

FOT&E Follow-On Operational Test and Evaluation

FQR Formal Qualification Review

GFE Government Furnished Equipment

GFM Government Furnished Material

ICD Interface Control Documentation

ICWG Interface Control Working Group

IDE Integrated Digital Environment

IDEF Integration Definition Function

IDEF0 Integrated Definition for Function Modeling

IDEF1x Integration Definition for Information Modeling

IEEE Institute of Electrical and Electronics Engineers

IEEE/EIA 12207 IEEE/EIA Standard 12207, Software Life Cycle Processes

IEEE P1220 IEEE Draft Standard 1220, Application and Management of the Systems Engineering Process

IFB Invitation for Bid

IIPT Integrating Integrated Product Teams

IMS Integrated Master Schedule

IOC Initial Operational Capability

IOT&E Initial Operational Test and Evaluation

IPPD Integrated Product and Process Development

IPR In-Progress/Process Review

IPT Integrated Product Teams

KPPs Key Performance Parameters

LRU Line-Replaceable Unit

M&S Modeling and Stimulation

MNS Mission Need Statement

MOE Measure of Effectiveness

MOP Measure of Performance

MOS Measure of Suitability

MS Milestone

MTTR Mean Time To Repair

NDI Non-Developmental Item

NIST National Institute of Standards and Technology

NRTS Not Repairable This Station

OA Operational Assessment

OIPT Overarching Integrated Product Teams

OMB Office of Management and Budget

OPS Operations

ORD Operational Requirements Document

OSD Office of the Secretary of Defense

OT&E Operational Test and Evaluation

PAR Production Approval Reviews

PDR Preliminary Design Review

PDRR Program Definition and Risk Reduction

PM Program Manager

PME Program/Project Manager – Electronics

PMO Program Management Office

PMT Program Management Team

PPBS Planning, Programming and Budgeting System

PRR Production Readiness Review

QA Quality Assurance

QFD Quality Function Deployment

R&D Research and Development

RAS Requirements Allocation Sheets

RCS Radar Cross Section

RDT&E Research, Development, Test and Evaluation

RFP Request for Proposal

S&T Science and Technology

SBA Simulation Based Acquisition

SBD Schematic Block Diagram

SD&E System Development and Demonstration

SDefR System Definition Review (as referred to in IEEE P1220)

SDR System Design Review

SE Systems Engineering

Section L Instructions to Offerors (Portion of Uniform Contract Format)

Section M Evaluation Criteria (Portion of Uniform Contract Format)

SEDS Systems Engineering Detail Schedule

SEMS Systems Engineering Master Schedule

SEP Systems Engineering Process

SFR System Functional Review

SI Software Item

SI&T System Integration and Test

SOO Statement of Objectives

SOW Statement of Work

SPEC Specification

SSA Source Selection Authority

SSAC Source Selection Advisory Council

SSEB Source Selection Evaluation Board

SSP Source Selection Plan

SSR Software Specification Review

SRR System Requirements Review

SRU Shop-Replaceable Unit

STD Standard

SVR System Verification Review

S/W Software

T&E Test and Evaluation

TDP Technical Data Package

TEMP Test and Evaluation Master Plan

TLS Timeline Analysis Sheet

TOC Team Operating Contract

TPM Technical Performance Measurement

TPWG Test Planning Work Group

TRR Test Readiness Review

VV&A Verfication, Validation, and Accreditation

WIPT Working-Level Integrated Product Team

[bewerken]

Specifieke Nederlandse termen


Afleiden Het afleiden van functies of eisen vanuit een bovenliggend detailniveau.

Alloceren Toewijzen van de gewenste functie of eisen aan één of meerdere objecten die deze functie vervullen.

Baseline Formeel “bevroren” status van een product die dient als referentie voor verdere werkzaamheden.

Belanghebbende (= Stakeholder) Een partij die een recht heeft in of belang heeft bij een systeem.

Beschikbaarheid (= Availability) Het vermogen van een product in een toestand te zijn om de vereiste functie onder bepaalde omstandigheid op een bepaald moment of gedurende een bepaald tijdsinterval uit te voeren, ervan uitgaande dat de vereiste externe hulpbronnen zijn verschaft. [EN50126]

B&I Beheer & Instandhouding (ProRail)

BS Bovenkant Spoor

Component Een samenwerkende combinatie van elementen bedoeld om in uitvoering van een gespecificeerde functie een bepaald doel te realiseren, maar die op zichzelf geen klantbehoefte vervult.

Configuratie Functionele en materiële eigenschappen van een product, zoals omschreven in technische documentatie en gerealiseerd in het product. [ISO 10007]

CUR Centrum voor Uniforme Regelgeving

DWA Droogweerafvoer (riool)

GJZ Grondverwerving en Juridische Zaken (ProRail)

MTTR Mean Time To repair

NS Nederlandse Spoorwegen

NTB Nader te bepalen

OVS Ontwerpvoorschriften Spoorwegen

PPT Publiek- en privaatrechtelijke toestemmingen

Primaire constructie Constructie of constructieonderdeel waarvan falen directe consequenties heeft voor het functioneren van OH4 (zoals draagconstructie).

ProRail Beheerder van de toekomstige infrastructuur.

PVE Programma van eisen

PVR Profiel van Vrije Ruimte

RIB Railinfrabeheer (ProRail)

RLN Richtlijn

Secundaire constructie Constructie of constructieonderdeel waarvan falen geen directe consequenties voor het functioneren van OH4 (zoals relingen op kunstwerken).

TAO Treindienst Aantastende Onregelmatigheid

TEV Tractie-energievoorziening



TVP Treinvrije periode



De database wordt beschermd door het auteursrecht ©opleid.info 2017
stuur bericht

    Hoofdpagina