SISTEM Ų INŽINERIJOS PLANAVIMAS IR ORGANIZAVIMAS

1. SISTEMŲ INŽINERIJOS PLANAVIMAS IR ORGANIZAVIMAS

2. Sistemų inžinerijos valdymas Sistemų inžinerijos valdymas – planavimas, organizavimas, aprūpinimas kadrais; procesų projektavimas, plėtojimas, testavimas; sistemos sukūrimas, tikrinimas ir kontrolė. Sistemų inžinerijos valdymo tikslas yra pateikti teisingą elementą teisingoje vietoje teisingu laiku ir su mažiausiom žmogiškųjų ir fizinių išteklių išlaidom.

3. Sistemų inžinerijos planavimas Sėkmingas sistemų inžinerijos programos reikalavimų įvykdymas priklauso nuo : • taikomo aukštyn-žemyn būdo sistemos vystyme, • ankstesnės integracijos projektavimo ir susijusių pagalbinių darbų, • reikalavimų pristatymo visos sistemos gyvavimo ciklo terminais, • būtinų reikalavimų ir nuo pradžios planuojamos dokumentacijos skleidimo. Programos dokumentacija - specifikacijų ir planų derinys su sistemos specifikacija (tipo A), kuri apima bendrus techninius reikalavimus sistemai kaip sistemų inžinerijos valdymo planui.

4. Sistemų inžinerijos valdymo planas (SEMP) SEMP yra raktinis valdymo dokumentas, apimantis darbus ir svarbius etapus, būtinus įvykdyti tikslams. SEMP tiesiogiai pateikia programos valdymo planą (PMP), kuris sudaromas duotos programos ar projekto valdymo dokumento viršuje. SEMP tikslai– pateikti struktūrą, strategijas ir procedūras, kad skatinti įvairių inžineriškai susietų darbų, reikalingų sistemos projektavimui ir vystymui, susijungimą.

7. SISTEMŲ INŽINERIJOS VALDYMO PLANAS(Pagrindai, EIA Inžinerijos Standartas 632, “Sistemų Inžinerija”) 1. Antraštinis puslapis, turinys, taikomi dokumentai 2. Sistemų inžinerijos procesas 2.1 Sistemų inžinerijos proceso planavimas – svarbesni rezultatai iš proceso, proceso įėjimų, techninių tikslų, darbo gedimo struktūros (WBS), mokymo, standartų ir procedūrų, išteklių paskirstymo, apribojimų, darbo įgaliojimo, patikrinimo planavimo, rangovo/tiekėjo techninių pastangų. 2.2 Reikalavimų analizė – patikimumas ir palaikymas, išlikimas, elektromagnetinis suderinamumas, žmogaus inžinerija, saugumas, produktyvumas, gaminio palaikymas, tikrinimas ir įvertinimas, integruota diagnostika, kilnojamumas, infrastruktūros palaikymas, kitos funkcionalumo sritys. 2.3 Funkcinė analizė ir paskyrimas – būdai, metodai, procedūrų įrankiai. 2.4 Sintezė – faktorių, priklausomumo būdai ir metodai, poveikių pasirinkimo naudojimas. 2.5 Sistemų analizė ir kontrolė – būdas, metodai, procedūros ir įrankiai (verslo studijos, sistemų kainos-efektyvumo analizė, rizikos vadyba, formos vadyba, sąsajos vadyba, duomenų vadyba, SE pagrindinis tvarkaraštis, techniniai atlikimo matmenys, subrangovo/tiekėjo kontrolė, reikalavimų susekamumas). 3. Pereinamosios kritiškos technologijos – veiklos, pavojai ir technologijų parinkimo ir perėjimo prie kitų technologijų kriterijus. 4. Sistemų inžinerijos bandymų - organizavimo integracija ir projektavimo disciplinų ir susijusių veiklų integracija (konkurencinė inžinerija). 5. Įgyvendinimo uždaviniai – technologijų patikrinimas (verifikavimas), proceso išmėginimas, pramoninės inžinerijos tikrinimo gaminiai, vystymosi tikrinimas ir įvertinimas, generavimas ir programinės įrangos pakartotinis naudojimas, patvirtinantis inžinerinis ir problemos sprendimo palaikymas, kitų sistemų inžineriniai įgyvendinimo uždaviniai. 6. Papildomos sistemų inžinerijos veiklos – ilgo-žingsnio (long-lead) elementai, inžinerijos įrankiai, kainos projektavimas, reikšmių inžinerija, sistemų integracija, kiti metodai ir kontrolės. 7. Pastabos ir priedai.

8. Trumpas darbo išdėstymas (SOW) SOW yra darbo pasakojamasis aprašymas, reikalingas duotam projektui. Tai: 1. užduočių santrauka, kurios turi būti įvykdytos; 2. pradinių reikalavimų nustatymas iš kitų užduočių; 3. nuorodos taikomiems reikalavimams (apimant Sistemos A reikalavimą), standartams, procedūroms ir susijusiai dokumentacijai, kas būtina darbo užsibrėžtos srities užbaigimui; (Šios nuorodos turėtų būti nustatomos kaip reikalavimai dokumentacijos medyje.) 4. specialių gautų rezultatų aprašymas. (Jame turi būti gautos aparatūros, programinės įrangos, projekto duomenys, ataskaitos ar susijusi dokumentacija, pateiktas pristatymo tvarkaraštis.) Bendrosios rekomendacijos ruošiant SOW: 1. SOW turi būti santykinai trumpas (neviršyti dviejų puslapių), ir turi būti parašytas aiškiai ir tiksliai. 2. Kiekvienas bandymas turi būti padarytas išvengiant dviprasmiškumo, ir klaidingo supratimo galimybės skaitytojui. 3. Reikalavimai turi būti aprašomi pakankamai smulkiai, kad garantuoti aiškumą, derinant praktinius taikymus ir galimas legalias interpretacijas; ne perdaug ar per smulkiai apibūdinti. 4. Išvengti nereikalingo pasikartojimo ir pašalinių dalykų ir reikalavimų sujungimo. 5. Nekartoti smulkių sąlygų ir reikalavimų, kurie jau yra numatyti taikomoje rekomendacijų dokumentacijoje. 6. Neturi būti neatsakytų klausimų, nes SOW bus skaitomas skirtingų specialybių žmonių (pvz., inžinierių, apskaitininkų, sutarčių vadybininkų, tvarkaraščio sudarytojų, teisininkų).

9. Sistemų inžinerijos programos uždaviniai • Atlikti reikiamą analizę ir vadovauti įgyvendinamumo tyrimo studijoms. • Pažymėti sistemos operacinius reikalavimus, patikimumo sąvoką, ir suteikti pirmenybę techniniams atlikimo matams. • Atlikti funkcionalinę analizę sistemos lygyje ir paskirti reikalavimus sekančiam žemesniam lygiui. • Paruošti Tipo A sistemos specifikaciją. • Paruošti tikrinimo ir įvertinimo pagrindinį planą. • Paruošti sistemų inžinerijos valdymo planą (SEMP). • Atlikti sintezę, analizę ir įvertinimą. • Planuoti, suderinti ir vadovauti formaliems projektų apžvalgos susitikimams. • Patikrinti ir apžvelgti sistemos tikrinimo ir įvertinimo darbus. • Suderinti ir apžvelgti visus formalių projektų pakeitimus tobulinimui. • Priimti ir sudaryti būtinus nenutrūkstamo ryšio darbus per visą gamybą, panaudojimą ir palaikymą, ir pasitraukimo ir daiktinio perdavimo fazes. Tikslas yra nustatyti uždavinius, kurie yra orientuoti į sistemą ir kritiniai, kad sutikti su jau aprašytais reikalavimais. Bendri tikslai yra garantuoti, kad • reikalavimai sistemai būtų iš pat pradžių gerai apibrėžti; • būtų “integruojamos” atitinkamos charakteristikos; • sistema patvirtintų pradžioje nusakytus reikalavimus.

10. Darbų gedimo struktūra (WBS)WBS yra į gaminį orientuotos šeimos medis, kuris leidžia funkcijų, veiklų, uždavinių, darbo paketųnustatymą, kuris atliktų duotos programos užbaigimą. Jis parodo, kad sistema (ar produktas) bus vystoma, gaminama, naudojama ir palaikoma, ir aprašo visus darbo elementus, kurie bus vykdomi. WBS vaizduoja darbų paketų, reikalingų programos planavimo, biudžeto sudarymo, užsakovų ir atsiskaitymų organizaciją.

11. Darbų planavimas

12. Programos tinklas

13. Programos tinklo darbų sąrašas A Atlikti reikiamą analizę, vadovauti tinkamumo studijoms, ir užbaigti sistemų analizę (operaciniai reikalavimai, palaikymo koncepcija, ir funkcinis sistemos žymėjimas) B Vadovauti išankstiniam planavimui, atlikti pradines valdymo funkcijas ir užbaigti Sistemų inžinerijos Valdymo planą (SEMP). C Paruošti Sistemos specifikaciją (A tipo). D Tobulinti sistemos-lygio techninius reikalavimus įtraukimui į SEMP. E Paruošti sistemos-lygio projektavimo duomenis ir pagalbines medžiagas Abstrakčiai Projektavimo Apžvalgai. F Vadovauti funkcinei analizei ir visos sistemos reikalavimų paskirstymui posistemės lygiui ir žemiau (jei reikia). G Tobulinti būtiną ir susijusią organizacinę infrastruktūrą reikiamos programos projekto darbų užbaigimo paruošimui. H Paaiškinti rezultatus iš Abstrakčios Projektavimo Apžvalgos atitinkamiems projektavimo darbams (t.y. patvirtinti projektavimo duomenys, rekomendacijos įvykdymui/ pataisymui). I Paaiškinti rezultatus iš funkcinės analizės ir paskirstymo darbo į specialius projektavimo kriterijus, reikalingus kaip įėjimas į projektavimo integravimo procesą. J Atlikti parengiamąjį projektavimą ir susijusius projektavimo integravimo darbus. K Paaiškinti rezultatus iš sistemos lygio projektavimo į specialius reikalavimus posistemės lygiuose ir žemiau. Paruošti Tobulinimo, Proceso, Gamybos ar Duomenų specifikacijas, jei reikia. L Vadovauti būtinam planavimui ir paruošti Sistemos Projektavimo Apžvalgą. M Paaiškinti reikalavimus, esančius specialaus projektavimo kriterijaus įvairiose taikomosiose specifikacijose, reikalingose kaip įėjimas į projektavimo integravimo procesą. N Paruošti projektavimo duomenis ir pagalbines medžiagas (kaip parengiamojo programavimo rezultatą) Sistemos Projektavimo Apžvalgai. O Atlikti parengiamąjį projektavimą ir susijusius projektavimo integravimo darbus.

14. Programos tinklo darbų sąrašas (tęsinys) P Paaiškinti rezultatus iš Sistemų Projektavimo Apžvalgos atitinkamiems projektavimo darbams (t.y. patvirtinti projektavimo duomenys, rekomendacijos įvykdymui / pataisymui). Q Nustatyti atitinkamus sistemos komponenčių tiekėjus, skirti būtinus specifikacijos reikalavimus per sutartis, ir kontroliuojamus tiekėjų darbus. R Vadovauti būtinam planavimui ir paruošti Įrengimų / Programinės įrangos/ Komponenčių Projektavimo Apžvalgas (čia gali būti individualių projektavimo apžvalgų, apimančių skirtingas sistemos komponentes). S Pateikti smulkius projektavimo duomenis palaikyti tiekėjo operacijoms. T Tobulinti prototipo modelį, su susijusiu palaikymu, ruošiant sistemos tikrinimą ir įvertinimą. U Paruošti projektavimo duomenis ir palaikymo medžiagas (kaip smulkaus projektavimo rezultatą) Įrengimams / Programinei įrangai/ Komponenčių Projektavimo Apžvalgoms. V Paaiškinti rezultatus iš Įrengimų / Programinės įrangos/ Komponenčių Projektavimo Apžvalgų Susijungimui į prototipinius modelius kaip tinkama. Prototipinis modelis, kuris bus panaudotas tikrinime ir įvertinime, turi atspindėti vėliausią projektavimo konfigūraciją. W Pateikti tiekėjo komponentes su palaikymo duomenimis sistemos prototipo tobulinimui, panaudotam tikrinimo ir įvertinimo darbuose. X Pasiruošti ir vadovauti Sistemos tikrinimui ir įvertinimui. Y Pateikti testavimo duomenis ir logistikos palaikymą, iš įvairių tiekėjų visoje sistemos tikrinimo ir įvertinimo fazėje. Tikrinimo duomenys reikalingi apsaugoti individualius testus, tvarkytus tiekėjų galimybėmis, ir logistikos palaikymas yra būtinas palaikyti sistemos testavimo darbus. Z Vadovauti būtinam planavimui ir paruošti Kritinę Projektavimo Apžvalgą. AA Patikrinti rezultatai, kitokio projektavimo patikrinimo ar rekomendacijų įvykdymui / pataisymui forma, yra pateikti kaip įėjimas į Kritinę Projektavimo Apžvalgą. BB Paruošti sistemos tikrinimo ir įvertinimo ataskaitą. CC Paaiškinti rezultatus iš Kritinės Projektavimo Apžvalgos susijungimui į galutinę sistemos konfigūraciją prieš įeinant į programos Gamybos ar Konstrukcijos fazę.

15. Projektavimo kainos Programos uždaviniams WBS pateikia struktūrą, kur yra padarytos kainų projekcijos ir formuojami biudžetai projektams. Veiklos – kainos funkcija

16. Sistemų inžinerijos organizavimas Pradinis sistemų inžinerijos planavimasprasideda nuo abstraktaus projektavimo ankstyvų fazių, ir vystosi per SEMP vystymąsi. Kad įvykdyti šį planą sėkmingai, reikia organizacinės struktūros, kuri padės taikyti sistemų inžinerijos principus ir sąvokas programoms. Organizacinės struktūros rūpinasi, kad būtų atliktos funkcijos ir rezultatai priklausytų nuo įgyvendintų tikslų, resursų taikymo, ryšių ir darbinių ryšių tarp individualių dalyvių, personalo motyvacijos ir daugelio kitų faktorių. Galutinis tikslas yra efektyviai dirbti ir efektyviai panaudoti žmonių, medžiagų ir piniginių resursus, darant sprendimą ir nustatant ryšių procesus, sukurtus atlikti specialiems tikslams. Uždavinių unikalumas ir dauguma skirtingų sąsajų padeda jos vystymuisi. • Organizacinės struktūros vystymasis • Vartotojo, gamintojo ir tiekėjo santykiai • Gamintojo organizacija ir funkcijos

17. Organizacinės struktūros vystymasis Pradinis žingsnisorganizacinės struktūros vystyme yra apibrėžti tikslus visai kompanijai/agentūrai/institucijai, kartu su funkcijomis ir uždaviniais, kurie turi būti išspręsti. Priklausomai nuo programų sudėtingumo ir dydžio, struktūra gali būti visas funkcinis modelis, projekto orientacija, matricinis būdas ar jų derinys. Pirminis tikslas yra garantuoti tinkamą sistemos-lygio reikalavimų vystymąsi. Šie darbai, surinkti tiekėjo/vartotojo, yra nukreipti į sistemą kaip visumą. Yra svarbus personalo parinkimas. Kai programa pereina į parengiamojo ir smulkaus projektavimo ir vystymosi fazes, personalo skaičius gali augti. Organizacinė struktūra gali pereiti iš visos projektavimo konfigūracijos į maišytą funkcinio-projektavimo ar matricų būdą. Kai sistema ir jos elementai įeina į gamybos/konstrukcijos fazę, organizacinė struktūra gali pereiti dar kartą.

18. Vartotojo, gamintojo ir tiekėjo santykiai

19. Gamintojo organizacija ir funkcijos Pagrindinis statymo blokas yra funkcinis būdas.Tikslas yra atlikti panašų darbą vienoje organizacinėje komponentėje. Visoje funkcionalinėje struktūroje, visas inžinerinis darbas yra vieno vadovo atsakomybė, visas gamybos bandymas yra kito vadovo atsakomybė, ir t.t. Keletas organizacinių grupių atliks to paties tipo darbą visiems vykstantiems projektams konkurentinėje bazėje. Dalinė funkcinė organizacija apima pagrindinio darbo paketų nustatymą. Organizacija atsakinga už šių uždavinių atlikimą. Šio būdo pageidauja mažos firmos ir agentūros, kai lengva vadovauti panašių funkcijų ir panašios kvalifikacijos personalo grupei. Didelėm daugiaprodukcinėm firmom, visas funkcinis būdas yra organizuojamas individualių projektų terminais, su aplinkui įdiegta drausminančia veikla.

20. Dalinė funkcinė organizacija

21. Supaprastinta projekto organizacija

22. Matricinė organizacija

23. Tipinė projekto – personalo organizacija

24. Pagrindinės sistemų inžinerijos ryšių jungtys (gamintojo organizacija)

25. Pagrindinio projekto sąsajos reikalavimų aprašas

26. IPPD Gynybos departamentas priėmė Integruoto produkto ir proceso tobulinimo - IPPD koncepciją 1990 metais. IPPD gali būti apibūdinamas kaip “valdymo technika, kuri tuo pat metu integruoja visus pagrindinio perpratimo darbus per daugiadisciplinių komandų naudojimą, kad optimizuoti projektavimo, gamybos ir palaikymo procesus. Būdina IPPD koncepcija yra integruotų gamybos komandų (IPTs) kūrimas, kad tiksliai pažymėti ir gerai-aprašyti uždavinius. IPT gali būti įkurta, kad ištirti specialią projektavimo dalį, rasti sprendinį keletui neišspręstų problemų, atlikti projektavimo darbus, kurie turi didelį poveikį TMP pirmumui, … Tikslas yra sukurti kvalifikuotų individų komandą, kurie gali efektyviai dirbti kartu, spręsti problemą atsižvelgiant į duotus reikalavimus. IPT’os yra dažnai įkuriamos programos vadovo. Tipiniai komandos nariai pagal patyrimą gali būti įgalioti padaryti sprendimus vietoje kai būtina, gali būti iniciatyvūs komandos dalyvavime, ir būti apsisprendę problemą perleisti. Programos vadovas privalo aiškiai apibrėžti tikslus komandai, lūkesčius rezultatuose, ir komandos nariai turi palaikyti bendravimą. IPT ilgaamžiškumas priklausys nuo uždavinio prigimties ir komandos efektyvumo progresuojant, aptariant jo tikslą. Kai komanda tampaneefektyvi vykdant tikslus, ji gali būti išformuota.

27. Funkcinė organizacija su IPPD/IPT darbais

28. Reziumė Sistemų inžinerijos planavimas yra vykdomas abstrakčioje projektavimo fazėje ir baigiasi SEMP tobulinimu. Duodamas bazinis planas. Jis yra būtinas įkurti organizacinį būdą, kuris leis tinkamą šio plano įvykdymą.