ИСКУСТВА

Home > ИСКУСТВА

ИСКУСТВА

Једна од претпоставки формирања Групе ТИМ била је да искуство које су стекли инжењери током радног века не буде изгубљено. Једноставно без тог искуства многи послови би морали да се започињу из почетка. А млади инжењери би морали да савладавају азбуку струке уместо да се оспособљавају кроз сарадњу са искуснима. Проблемима са искуством допринео је период транзиције, који код нас предуго траје. У том периоду нестајањем многобројних привредних субјеката у оквиру којих је постојала критична маса знања. А то значи и искуства. Са нестајањем предузећа многи искусни инжењери су остајали без посла. И уместо да другима преносе своје искуство водили су битку за егзистенцију. Треба додати да је у поменутом периоду дошло до технолошког бума у готово свим гранама технике. То је додатно створило јаз у погледу знања и искуства код млађе генерације у односу на свет.

Овај текст не треба схватити као ламент на судбином и искусних и младих инжењера. Већ као начин да се покуша наћи начин да се ситуација поправи. Тако да се искусни инжењери и даље осећају друштвено корисним. А млади инжењери буду у прилици да добију информације које ће премостити технолошки јаз у коме су се образовале. Ово је посебно значајно ако се има у виду да образовање често иде ка модерним инжењерским знањима. А при томе се често пренебрегавају фундаментална знања из струке, чије незнање често доводи до проблема у пракси. Потреба да се прати технолошки напредак често води у стихијски приступ у практиковању инжењерских струка. Што се огледа у израженом одсуству документовања урађених послова. Или често техничка документација не одговара реализованом пројекту. То има јасне последице на реализацију и касније одржавање реализованих система. Али не треба заборавити да је техничка документација један од битних фактора стварања критичне масе знања.

Техничка документација

Често се може чути цитирање Катона Старијег – „Ceterum censeo Carthaginem esse delendam“. Искусни инжењери знају шта им је у пракси значила докумнтација о системима на које се њихов рад наслањао. Она помало личи на Картагину, коју једно за свагда треба освојити. Релативно лака доступност информацијама, посебно коришћењем Интернета ствара слику да се понешто везано за документовање пројеката може и прескочити. Полазећи од претпоставке – „Има то на Интернету“ млади инжењери често мисле да и сами не морају баш све да представе окружењу. Нажалост пракса је често отрежњујућа. Јер често на Интернету нема баш онога што нам је потрено. А лако се заборави и понешто од онога што смо сами урадили. Поготову ако нисмо забележили детаље везане за сопствено решење.

Истовремено Интернет је много допринео олакшавању инжењерских послова. Пре свега кроз доступност информација о компонентама и уређајима који се при пројектовању користе. Такође, не треба занемарити ни могућност коришћења готових пројектних решења. Међутим, и у таквим ситацијама техничка документација може да умеша своје прсте. Документација која се у таквим случајевима може наћи на Интернету често је непотпуна. А може изазвати недоумице. Свако ко је користио такве информације на Интернету био је у прилици да се упозна са проблемима њиховог квалитета.

Све ово додатно указује на значај техничке документације за успех инжењерског посла. С једне стране њен утицај на ефикасност пројектантског посла. А са друге стране ефикасност коришћења реализованог уређаја или система. У принципу не може да се утиче на туђу техничку документацију. То може да уради наручилац посла кроз спецификацију захтева за реализацију пројекта. Овде ће се дати оријентациони пример структуре техничке документације која прати реализацију типичног инжењерског пројекта.

Структура техничке документације

Недостатак конкретног примера техничке документације може заменити и приказ како би она начелно требало да изгледа. Поред уобичајених уводних напомена којима се опис уређаја представља кориснику следе поглавља:

    1. Технички захтеви – у овом поглављу треба дати спецификацију уређаја или система који се описује. Након тога треба корисника упознати са функционалним захтевима према којима је систем реализован. Такође, треба изнети и нефункционалне захтеве, као што су перформансе, поузданост, скалабилност, итд.
    2. Пројекат и структура система – пре свега потребно је изложити структуру система. У складу са тим треба приказати неопходне блок дијаграме и дијаграме тога унутар реализованог система. На крају треба дати опис главних компонената система и везе које постоје међу њима.
    3. Реализација – детаљан приказ реализације система. То подразумева детаљан приказ начина реализације, коришћених алата и технологија. При томе треба дати примере конкретних решења, која су карактеристична за систем.
    4. Тестирање – начин и план тестирања укључујући и конкретне тестне случајеве. У склопу тога треба дати резултате тестирања, као и коришћене алате за тестирање.
    5. Одржавање – упутства за одржавање система. Мере сигурности којих се треба придржавати. Поступци за ажурирање и надградњу система.
    6. Корисничка документација – кориснички приручници, упутства за инсталацију и конфигурисање система.
    7. Референце – списак коришћене литературе и других ресурса. То подразумева и линкове на додатне изворе информација.
    8. Прилози – информације које додатно описују систем, као што су листе делова, додатни дијаграми, итд.

Leave a Reply

Your email address will not be published. Required fields are marked *