APLIKAČNÍ SOFTWARE PRO ODHAD SPOLEHLIVOSTI A PRO HODNOCENÍ RIZIK

Transkript

1 1 INTEGROVANÝ NÁVRH KONSTRUKCÍ A SYSTÉMŮ PRO VÝSTAVBU 1.1 Teoretické základy integrovaného navrhování Rozvoj rizikové a spolehlivostní analýzy jako nástroje kvalifikovaného rozhodování Metody a software pro odhad spolehlivosti a hodnocení technicko-ekonomických rizik APLIKAČNÍ SOFTWARE PRO ODHAD SPOLEHLIVOSTI A PRO HODNOCENÍ RIZIK Dílčí výzkumná zpráva za rok 2005 Řešitelé úkolu: Doc. Ing. Václav Beran, DrSc., FSv ČVUT v Praze Ing. Zita Prostějovská, Ph. D., FSv ČVUT v Praze Ing. Eduard Hromada, FSv ČVUT v Praze Ing. Jana Frková, Ph.D., FSv ČVUT v Praze Ing. Petr Dlask, Ph.D., FSv ČVUT v Praze Datum: Prosinec

2 OBSAH Souhrn.. 3 A. Oblast použití.. 3 B. Metodický a koncepční přístup.. 3 B.1 Metodologie 3 B.2 Teoretický rozbor 4 C. Výsledky řešení. 5 C.1 Vstupní data 5 C.2 Struktura aplikace 6 C.2.1 Aplikační interface 6 C.2.2 Aplikační jádro 6 C.2.3 Výstupní interface 6 C.3 Základ aplikace 7 C.4 Vstupní atributy 7 D. Literatura. 7 E. Přílohy. 9 E.1 Příloha 1: Struktura dialogů aplikace 9-2 -

3 Souhrn Navržení racionální struktury řešení stavební konstrukce (stavebního objektu nebo projektu) je výsledkem řešení racionálního projektového návrhu kombinace vhodných materiálových, organizačních a výrobních vlastností jednotlivých použitých (zabudovaných) konstrukčních prvků. Návrh skladby by měl být podpořen a verifikován technicko-ekonomickým ohodnocením a následným výběrem. Manuální nebo empirická tvorba výpočtů uvedených typů není efektivní. Stejnou typologii propočtu je možné aplikovat pouze na věcně a obsahově identický projekt. Stavební praxe, kladoucí důraz na unikátnost řešení, odsouvá možnost použití již aplikovaných úloh do pozadí. V případě jakýchkoliv (i drobných) změn projektu se výpočtová struktura mění. Výpočtový aparát je možné standardizovat a definovat tak obecná pravidla, podle kterých bude výsledné řešení posuzováno, hodnoceno a měněno. Uvedenou činnost přípravy vstupních dat pro aplikační jádro výpočtu je schopen zajistit navrhovaný softwarový nástroj. A. Oblast použití Inženýrský přístup k výběru racionální skladby navrhovaného projektu je možné aplikovat na mnoha úrovních lidské činnosti. Každý nový projekt by měl podléhat takovému kontrolnímu mechanismu, aby se dařilo eliminovat co nejvíce potenciální nedostatky funkčnosti v budoucím průběhu užívání (LC). Vzhledem k zaměření dílčího výzkumného úkolu se předpokládá aplikace vytvářeného nástroje ve dvou základních projektových fázích 1. projektové řešení, 2. realizační řešení (viz obr. 1). Každé projektové řešení obecně předpokládá dekompozici projektu na jednotlivé konstrukční díly v požadovaném zpracovávaném detailu stavby. Řešení je návazným procesem, který obsahuje definované dílčí prvky a projektant definuje jejich vzájemné kauzální vazby K [Beran a kol., 2002]. B. Metodický a koncepční přístup B.1 Metodologie Zpracování moderní projektové dokumentace probíhá v prostředí výkonných aplikačních CAD systémů. Architektonické a technické prostředky pro zpracování návrhu řešení jsou na vysoké úrovni. Ekonomické hodnocení (procesů A i Q, funkčních částí X i ) je ukončeno na úrovni zjištění objemových parametrů A Q, X a jejich finančního ohodnocení. Nadstavba, která by ohodnocovala kvalitu v i jednotlivých konstrukčních dílů a jejich rizika r i nebývá pro dané - 3 -

4 konkrétní řešení zpracovávána. Kritéria pro takové hodnocení mohou být užitek, náklady, výnosy, ekologie apod. Kvalitativní ohodnocení v i jednotlivých konstrukčních dílů jsou dostupná z projektového zpracování. Agregovaná hodnota U=Σv i, i=1,, n, kde i jsou jednotlivé konstrukční části popisující celý projekt, již není vždy dostupná ani jako statická nebo dynamická veličina. Hodnota vypovídající o rizicích navrhovaného řešení absentuje zcela. Cílem náročných postupů zůstává vyčíslení uvedených veličin s požadovanou vypovídací schopností. B.2 Teoretický rozbor Sestavení aplikačního software ve vazbě na vyhodnocení spolehlivosti a rizik navrhovaného řešení je návrhem akceptování předloženého teoretického postupu. Jeho realizaci musí předcházet rozbor, který bude jednoznačně definovat základní požadavky na vstupní hodnoty, výpočet a výstupy pro praktické použití. Projektový standard Konstrukční řešení Konstrukční detaily Projektové řešení Technologické postupy Kauzální vazby procesů Průběh realizace Normové požadavky Realizační řešení Časové požadavky Obr. 1 Základní projektové fáze. Definice prvků X i jako komponent řešení může být aplikována strukturovanými interakcemi a ij [Dlask, 2005] a následně analyzována jako dynamický model. Zaměření práce je cíleno na rozhodovací procesy, které je možné navrhovat v intencích projektového řízení [Beran a kol., 2002]. Postupy je vhodné doplnit expertním ohodnocením s vazbou na spolehlivost hodnotících výpovědí jednotlivých expertních skupin. Cílem je podpořit postup navrhovaným softwarovým nástrojem. V souvislosti s rozborem vstupů úlohy (dat, ohodnocení) bude softwarový nástroj rozdělen na 3 základní technické bloky, které mezi sebou budou těsným způsobem komunikovat (viz obr. 2). Jedná se o 1. aplikační interface, 2. aplikační jádro, 3. výstupní interface

5 Všechny komunikační vazby mezi bloky softwarové aplikace budou konzistentně realizovány v rámci jediného projektu sestaveného v tabulkovém procesoru MS Excel a to ve volné vazbě na případné zdroje. Jejich potřeba vyplyne z konkrétně zpracovávané úlohy. C. Výsledky řešení C.1 Vstupní data K sestavení navrhovaného SW pro hodnocení technického návrhu nebo realizace projektu je třeba sestavit nutné vstupní údaje. Data mohou mít základní formu numerickou, textovou (verbální) nebo grafickou. Zvláštní formou jsou vstupy logických proměnných, nabývajících hodnot ANO/NE (resp. TRUE/FALSE). Každá forma vstupního údaje musí být poskytnuta implementovanému aplikačnímu jádru. Uvedený postup bude zajišťován navrhovaným aplikačním rozhraním (aplikační interface). Nejjednodušší forma předávání vstupních dat pro výpočtový aparát je přímý zápis hodnot do listů pro zpracováním tabulkovým procesorem. Její nevýhodou je, že zadavatel musí přesně znát strukturu vstupních údajů a jejich pozice. Dalším nedostatkem přímého zadávání je, že pozadí původní výpočtové struktury tabulkového procesoru již musí existovat. Znamená to, v první fázi vytvořit manuálně strukturu vstupních údajů a následně ji vyplnit správnými hodnotami. Se jmenovanou jednoduchostí formy zápisu je logicky spojeno značné nebezpečí zadání chybných hodnot nebo umístění vstupů do nesprávných pozic. - definice struktury úlohy - zadání vstupních údajů - test konzistence dat - správa projektů Aplikační interface - kontrola dat před výpočtem - výpočet úlohy - poskytnutí výsledků - generace výpočtové struktury Aplikační jádro Výstupní interface - separace výsledků - tvorba protokolů - tvorba výstupních sestav - grafické výstupy Obr. 2 Vazby mezi technickými bloky

6 C.2 Struktura aplikace C.2.1 Aplikační interface Výše zmiňované nedostatky přímého zadávání vstupních dat eliminuje do značné míry vytvoření aplikačního rozhraní (viz obr. 2). Zadavatel bude využívat vytvořený systém standardních dialogových oken pro ukládání vstupních údajů. Jedná se o a) hodnoty potřebné pro generování struktury výpočtu při hodnocení nového projektu, b) hodnoty potřebné pro spuštění výpočtu aplikačního jádra, c) hodnoty potřebné pro sestavení aplikačních výstupů pro praktické použití. Zadání vstupních údajů je napojeno na systém verifikace, který slouží zadavateli ke kontrole správnosti zadaných hodnot v rámci definovaných pravidel. Aplikační interface navíc zajišťuje umístění zadávaných vstupů do správných pozic pro spuštění výpočtu aplikačního jádra. C.2.2 Aplikační jádro Výše uvedené členění aplikace je vzájemně interně propojeno dle závislostí uvedených na obr. 2. Za ústřední článek aplikace je možné považovat aplikační jádro, které musí mít vazbu na aplikační interface a současně bude poskytovat potřebné informace pro sestavení výstupních textových a grafických dokumentů. Základními částmi aplikačního jádra jsou a) generátor úlohy, b) řešitel úlohy. Zadáním vstupních dat pro generátor úlohy je systém připraven vytvořit výpočtovou strukturu hodnocení nové úlohy, která bude postupně vyplňována prostřednictvím aplikačního rozhraní. Na generovanou strukturu bude aplikována implementace řešitele, před jehož spuštěním dojde k prověření konzistence vstupních údajů. Experimentálně budou v dílčím výzkumném úkolu řešeny úlohy a) hodnotící, rozhodovací b) popisy procesů a jejich chování v čase. C.2.3 Výstupní interface Při běhu řešitele úlohy jsou postupně zpracovávány vstupní informace a po jejich vyhodnocení jsou sestavována data potřebná pro spuštění výstupního rozhraní. Základními výstupními informace výpočtu jsou číselné hodnoty a verbální popisy výsledků. Nezbytným doplňkem je sestavení grafických výstupů generovaných na základě odeslaných požadavků výstupního rozhraní. Grafické výstupy včetně zdrojových dat mohou být exportovány do nových listů tabulkového procesoru pro jejich následnou uživatelskou editaci

7 C.3 Základ aplikace Ve výchozím popisu struktury aplikace je uplatňován princip superpozice. Předpokládá se, že každý zpracovávaný projekt je možné dekomponovat na jednotlivé funkčně související části sestavené do stromové struktury. Každý uzel a hladina jsou definovány svými atributy popsanými dále. Všechny uzly na každé dekomponované hladině jsou ohodnoceny váhou (významností) kritéria z pozice expertního odhadu zadavatele. Za těmito hodnotami může stát další rozsáhlý výpočet podle známých metod ohodnocení kritérií, který však není součástí navrhované aplikace. Součet všech vah na konkrétní hladině musí být roven jedné. Nejnižší hladina stromové struktury je považována za konečnou rozlišovací schopnost z hlediska dekompozice projektu. Jako taková je vybavena hodnocením vycházejícím z projektového návrhu a rozptylem tohoto hodnocení, představujícím rizika spojená s dosažením projektem navržených hodnotou. C.4 Vstupní atributy Při sestavování stromové struktury aplikace je třeba dodržovat určitá pravidla. Podle nich je následně generátor schopen sestavit výpočtový mechanismus a odstranit tak manuální náročnost při jeho tvorbě. Jednotlivé hladiny jsou uváděny v dialogovém okně generátoru. Jsou zde zapojeny základní editační funkce, které umožňují uzly na jednotlivých hladinách přidávat, upravovat a odstraňovat. V rámci hierarchie jsou definovány tři skupiny uzlů 1. hlavní uzel (Main node) 2. mezilehlé uzly (Middle nodes) 3. základní uzly (Base nodes). Každý uzel má podle tohoto členění určitou definovanou skupinu atributů, které je třeba v rámci generace a zadání vstupních hodnot vyplnit. Hlavní uzel definuje pouze počet svých následníků, pro které se stává předchůdcem a sám o sobě žádného předchůdce nemá. Mezilehlé uzly definují svého předchůdce a současně počet svých následníků. Základní uzly naopak určují pouze svého předchůdce a parametry hodnotící jeho základní vlastnosti. Počet jejich následníků je roven nule. Jak již bylo uvedeno všechny uzly musí být vybaveny významností (váhou) ohodnocenou z pohledu zadavatele. Součet jednotlivých vah na konkrétní hladině musí být roven 1-7 -

8 D. Literatura Haas Š., Hájek Vl.: Systémové plánování a řízení ve stavebnictví. SNTL Praha 1981 Beran, V. a kolektiv (Dlask, P., Schneiderová-Heralová, R. Mosler, J. Berka, V.): Dynamický harmonogram elektronické rozvrhování technicko-ekonomických procesů v řízení malých a středních podniků, ACADEMIA, nakladatelství Akademie věd České republiky, ISBN , Beran, V. a kolektiv: Dynamický harmonogram doprovodné CD, ACADEMIA, nakladatelství Akademie věd České republiky, ISBN , Beran, V., Dlask, P.: Management udržitelného rozvoje regionů, sídel a obcí, 1. vyd. Praha: ACADEMIA, nakladatelství AV ČR, s. ISBN X. Tománková, J.: Doktorská disertační práce FSv, ČVUT v Praze, Dlask, P., Beran, V.: MDM teoretická příručka, 1. vyd. Praha: Vydavatelství ČVUT, s. ISBN

9 E. Přílohy E.1 Struktura dialogů aplikace Následující grafické výstupy ilustrují strukturu návrhu dílčí části aplikace, která bude zpracována v prostředí Visual Basic for Application MS Excel. Jednotlivé bloky jsou ovládány standardními editačními prvky a procedurami (viz obr. 3). V rámci aplikace se předpokládá hierarchická správa uživatelů s přidělenými právy editačních zásahů. Aplikační nabídka možných operací Ověření uživatele Výběr uživatele Informační pole aplikace Obr. 3 Úvodní obrazovka aplikace. Z dalších technických bloků aplikace je uveden Generátor, který je součástí aplikačního jádra nástroje (viz obr. 4). Pomocí něj se budou definovat jednotlivé hladiny stromové struktury, uzly na příslušných hladinách a jejich potomci. Každý uzel je dále doplněn atributy potřebnými pro spuštění výpočtu v rámci Řešitele úlohy. Každá změna vstupních údajů vyžaduje nový výpočet úlohy

10 Definice hladiny dekompozice Definice polohy uzlu kritéria Vytvoření strukturovaného výpočtu Atributy uzlu na definované hladině Obr. 4 Základní struktura generátoru úlohy