S istem ų Inžinerijos Planavimas Ir Organizavimas

1. SistemųInžinerijos Planavimas Ir Organizavimas Papildymas

2. Kada gyvavimo cikle turėtų būti pradėtas sistemų inžinerijos planavimas? Kodėl tai svarbu? Sistemų inžinerijos planavimas turi būti pradėtas anksti gyvavimo cikle, užbaigiamas konceptualaus (abstraktaus) projektavimo fazėje ir plėtojamas, vystant SEMP. Technologinė sistemų inžinerijos dalis negali būti realizuota be gero pirminio planavimo, tinkamos organizacinės aplinkos įvedimo ir toliau sekančio valdymo, kuris yra būtinas efektyviam ir tinkamam programos įgyvendinimui.

3. Koks yra SEMP tikslas? Kada gyvavimo cikle jis turėtų būti vystomas? Kaip jis susijęs su: (a) PMP; (b) patikimumo (reliability) programos planu; (c) TEMP; (d) ILSP; (e) TQM planu; (f) konfigūracijos valdymo planu? SEMP (Sistemos Inžinerijos Valdymo Plano) tikslai– pateikti struktūrą, strategijas ir procedūras tam, kad skatinti įvairių sistemos projektavimui ir vystymui reikalingų su inžinerija susietų darbų integraciją. SEMP vystomas konceptualaus (abstraktaus) projektavimo fazėje. SEMP tiesiogiai palaiko programos valdymo planą (PMP), kuris laikomas duotos programos ar projekto viršutiniu valdymo dokumentu. SEMP siekia integruoti individualius su projektavimu susijusius programos planus (pvz., patikimumo programos planas, palaikomumo (maintainability) programos planas ir t.t.) bei skatinti būtinas komunikavimo nuorodas su kitais viršutinio lygio planavimo dokumentais (pvz., konfigūracijos valdymo planu, tikrinimo ir įvertinimo pagrindiniu planu (TEMP), visiškos kokybės užtikrinimo planu (TQM) ir kt.) Žr. 18.1 pav.

4. 18.1 pav. Programos planai ir specifikacijos

5. Kaip SEMP yra susijęs su sistemos reikalavimu (system specification) (tipo A)? Žr. 18.1 pav. Kritiniai programos dokumentai – tai kombinacija specifikacijų ir planų, kurie kartu su sistemos specifikacija (tipo A) apima visus techninius reikalavimus sistemai kaip esybei ir sistemos inžinerijos valdymo plano, kuriame kreipiamas dėmesys valdymo poreikiams.

6. Identifikuoti ir aprašyti darbus, kurie turėtų būti įtraukti į sistemos inžinerijos programą. (1) • Atlikti poreikių analizę ir vadovauti įgyvendinamumo tyrimo studijoms. • Nustatyti sistemos operacinius reikalavimus, patikimumo (maintenance) sąvoką, nustatyti ir išdėstyti pagal svarbą techninius matus. • 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.

7. Identifikuoti ir aprašyti darbus, kurie turėtų būti įtraukti į sistemos inžinerijos programą. (2) • Patikrinti ir apžvelgti sistemos tikrinimo ir įvertinimo darbus. • Suderinti ir apžvelgti visus formalių projektų pakeitimus tobulinimui. • Inicijuoti ir nustatyti būtinus nenutrūkstamo ryšio darbus per gamybos, naudojimo ir palaikymo, bei pasitraukimo ir daiktinio perdavimo fazes.

8. Koks yra WBS tikslas? Koks yra skirtumas tarp SWBS ir CWBS? Koks yra skirtumas tarp CWBS ir CBS? WBS(Work Breakdown Structure) yra į gaminį orientuotos šeimos medis, kuris veda prie identifikavimo duotos programos užbaigimui reikalingų atlikti funkcijų, veiklų, uždavinių, darbo paketų. Jis parodo ir aprašo vystomą, gaminamą, naudojamą ir palaikomą sistemą (ar produktą), ir aprašo visus atliekamus darbo elementus. WBS vaizduoja organizavimą darbų paketų, reikalingų programos planavimui, biudžeto sudarymui, užsakymams ir ataskaitoms. SWBS(Summary WBS) – tai platus darbų klasifikavimas, vedantis prie vienos ar daugiau detalesnių darbų išskirstymo schemų, skirtų konkrečioms užduotims, pvz., CWBS(Contract WBS).

9. Kas turėtų būti įtraukta į SOW? Perspėjimai, ruošiant SOW. (1) Į SOW (Statement of Work – trumpas darbo išdėstymas) turėtų būti įtraukta: • Užduočių, kurios turi būti atliktos, glausta santrauka. • Pradinių reikalavimų, kylančių iš kitų užduočių, nustatymas. • Nuorodos į reikalavimus (kad įtraukti Sistemos A reikalavimą), standartus, procedūras, kitus susijusius dokumentus, būtinus nustatytos srities darbo atlikimui. • Specialių rezultatų, kurie bus gauti, aprašymas.

10. Kas turėtų būti įtraukta į SOW? Perspėjimai, ruošiant SOW. (2) Rekomendacijos, ruošiant SOW: • SOW turėtų būti santykinai trumpas ir konkretus (neviršyti dviejų puslapių). • Turi būti dedamos visos pastangos, siekiant išvengti dviprasmiškumo ir skaitančiojo klaidingo supratimo. • Reikalavimai turi būti aprašomi pakankamai smulkiai (bet ne pernelyg smulkiai) tam, kad užtikrinti aiškumą abiejų - praktinių taikymų ir galimų legalių interpretacijų. • Reikia vengti bereikalingo pakartojimo ir įtraukimo šalutinės medžiagos ir rekalavimų. • Nekartoti detalizuotų specifikacijų ir reikalavimų, kurie jau yra numatyti taikomojoje nurodomoje dokumentacijoje.

11. Jeigu jums būtų pavesta valdyti sistemos inžinerijos programą, kurį darbų planavimo metodą pasirinktumėte, siekdami maksimalaus įmanomo savo būsenos nustatymo matomumo? Kodėl? Galimi įvairūs darbų planavimo (scheduling) metodai – juostinės diagramos, esminių etapų (milestones) diagramos, programos tinklai, Gantto diagramos ar jų kombinacijos. Aš pasirinkčiau programos tinklą, kadangi jame vaizdžiai atvaizduojama ne tik programos darbams atlikti reikalingi laikai, bet ir darbo pradžią įtakojantys ir darbo rezultatus naudojantys darbai bei kritinis kelias. Žr. 18.8 pav.

12. 18.8 pav. Programos tinklas (program summary network)

13. Nustatykite keletą pagrindinių sistemų inžinerijos orgnizavimo tikslų. Maksimalus tikslas – siekti efektyviausio žmonių, medžiagų ir piniginių resursų panaudojimo, dėka sprendimų priėmimo įvedimo ir komunikavimo procesų, sukurtų atlikti specialiems tikslams. Sistemų inžinerijos tikslų įgyvendinimas labai priklauso nuo tinkamo rinkinio resursų, gerų komunikacijų įvedimo ir gerų dalyvaujančiųjų visuomeninių savybių.

14. Turėdami omeny sistemų inžineriją, aprašykite keletą privalumų ir trūkumų grynai funkcinės organizacijos struktūros; grynai projektinės organizacijos struktūros; ir matricinės organizacijos struktūros. Funkcinė organizacijos struktūra leidžia lengviau valdyti homogenines panašių fukcijų ir personalo su panašiomia kvalifikacija grupes. Taigi sumažinamas duplikavimas. Tačiau didelėms operacijoms tai nėra būtina dėl nepraktiškos atsakomybės centralizacijos. Grynai projektinė organizacija turi privalumų, kalbant apie atsiliepimą konkrečiam vartotojui, bet gali būti dubliavimo kompanijos viduje dėl resursų duplikavimo per keletą projektinių linijų. Matricinė organizacijos struktūra leidžia paskirstyti resursus pagal funkcionalinę struktūrą, bet tiesioginis įsitraukimas į kasdieninius projekų darbus gali būti nuslopintas, kadangi sistemų inžinerijos darbas nėra dalis projekto organizavimo.

15. Jeigu jūs rūpintumės sistemų inžinerijos organizacijos darbuotojų paieška, kokio tipo individus jūs samdytumėte? Apibrėžkite kvalifikacijos ir patiries lūkesčius, asmenines savybes, specialius sugebėjimus. Bet kurios sistemos projektavime ir vystyme esminis tikslas yra nustatyti komandinį traktavimą, su atitinkamomis komunikacijomis, suteikiant galimybę visur taikyti konkuruojančius inžinerijos metodus. Todėl aš samdyčiau plataus pasirengimo darbuotojus, kurie gali specializuotis konkrečioje srityje. Jie turėtų būti kiek įmanoma universalesni tam, kad apžvelgtų visą sistemą ir joje veikiančius ryšius, mokėti dirbti komandoje, tačiau gerai nusimanyti ir kurioje nors konkrečioje srityje.

16. Kaip sistemų inžinerijos vadovas, kokio tipo organizacinę aplinką stengtumėtės sukurti tam, kad efektyviai įgyventinti jūsų tiklslus? Tinkama organizacinė aplinka turi būti kuriama tokia, kad 1. Leistų įgyvendinti sistemos inžinerijos reikalavimus ir 2. Palengvintų šių reikalavimų efektyvų įgyvendinimą. Aš stengčiausi sukurti tokią organizacinę aplinką, kurioje sistemų inžinerijos konkretūs darbai būtų atliekami projektinėse grupėse, tam, kad pasiekti maksimalios atskaitomybės už konkretų darbą, tačiau panašaus pobūdžio projektus turėtų rengti tos pačios grupės tam, kad išvengti lėšų dubliavimo. Be to, tarp grupių turi veikti gerai sutvarkyti komunikaciniai ryšiai, kad būtų galima koordinuoti atskirų projektinių grupių veiksmus.

17. Koks IPPD koncepcijos tikslas? Kas yra IPT ir kokie jo tikslai? Integruotas produkto ir procesų vystymas (IPPD) – tai valdymo technologija, kuri tuo pat metu integruoja visus esminius perpratimo darbus, naudodama multidisciplinarias komandas tam, kad optimizuoti projektavimo, gaminimo ir palaikomumo (supportability) procesus. Integruota produkto komanda (IPT), susidedanti iš tinkamų disciplinų individų, gali tirti specifinį projekto segmentą, kokios nors kilusios problemos sprendimą ir t.t. Tikslas yra sukurti komandą kvalifikuotų individų, kurie gali efektyviai dirbti kartu, spręsdami duotą problemą.

18. Žr. į 18.17 pav. Įsivaizduokite, kad jūs paskirtas sistemų inžinerijos organizacijos vadovu ir komunikavimo procesai, atvaizdojmi taškuota linija, nefunkcionuoja tinkamai. Kokie būtų jūsų žingsniai, sustiprinant šiuos komunikavimo ryšius? • Nustatyti trūkumų priežastis. Galimas sprendimas – susirinkimas, kuriame dalyvauja projekto ir visų grupių vadovai. • Jei tai esminis trūkumas, peržiūrėti sistemos inžinerijos pirminę dokumentaciją (tiek technologiniu, tiek valdymo požiūriu). • Jei tai neesminis trūkumas, parinkti tinkamus žmones, kurie, vadovaudamiesi pirminiais sistemos projektavimo dokumentais bei atsižvelgdami į jau nuveiktus darbus, ištirtų ir pašalintų trūkumus.

19. 18.17 pav. Pagrindiniai sistemų inžinerijos komunikacijų ryšiai