Konceptualus sistemos projektavimas

1. Konceptualus sistemos projektavimas

2. Atliekant poreikių analizę reaguojant į konkretų trūkumą, kokio tipo informaciją jūs apimtumėte? Apibūdinkite procesą kurį jūs naudotumėte formuodami būtiną informaciją. Sistemos kūrimo procesas prasideda nuo poreikių nustatymo naujiems sistemos komponentams ar naujoms patobulintoms galimybėms. Poreikių nustatymas turėtų būti grindžiamas esamų problemų suvokimu. Analizuojant vartotojų poreikius, reikia išanalizuoti esamą sistemos būseną, suvokti jos trūkumus ir privalumus. Esant kažkokiam sistemos trūkumui, informaciją reikia rinkti priklausomai nuo to trūkumo prigimties. Pvz. esant mažam sistemos našumui ar didelėms atminties sąnaudoms, pirminis sprendimas būtų sistemos analizė naudojant matavimams skirtą programinę įrangą (OptimizeIt, Jtest), kurių pagalba nustatytume taip vadinamuosius “karštus taškus” - vietas, kuriose sistema užtrunka ilgiausiai, daugiausiai kartų kviečiamos funkcijos ir t.t., taip pat sistemos dalis naudojančias didžiausią atminties kiekį. Sekantys žingsniai būtų - sistemos analizė ir architektūriniai bei įgyvendinimo sprendimų korekcija ir pakeitimų įvertinimas.

3. Koks yra pagrindinis įgyvendinamumo analizės tikslas? Kokie turėtų būti priimti sprendimai užbaigiant analizę? Įgyvendinamumo analizės tikslas: • nustatyti galimus sistemos projektavimo metodus • įvertinti labiausiai tinkamus metodus pagal tokius kriterijus kaip: • našumas • efektyvumas • palaikomumas • ekonominiai kriterijai ir kita • rekomenduoti tinkamą veiksmų eigą (scenarijų). Šiuo atžvilgiu gali būti daug įvairių alternatyvų, tačiau jų skaičius turi būti kiek įmanoma sumažintas iki keleto galimų atitinkamai derinant su turimais ištekliais (personalas, medžiagos ir pinigai). Užbaigiant analizę, turi būti pateikti konkretūs problemų sprendimo būdai.

4. Apibūdinkite QFD požiūrį ir kaip jis turėtų būti taikomas siekiant padėti nustatyti reikalavimus kuriamai sistemai. Vienas iš būdų, palengvinanti vartotojo ir kūrėjo bendravimo procesą yra naudojantis QFD metodiką. QFD paremtas komandiniu požiūriu, kuris padeda užtikrinti kad „vartotojo balsas“ atsispindėtų galutiniame projekte. QFD tikslas yra nustatyti būtinus reikalavimus ir paversti juos į techninius sprendimus. Vartotojo reikalavimai yra kategorizuojami kaip atributai, kurie yra vėliau pasveriami remiantis jų svarba. QFD metodas leidžia kūrėjų komandai suprasti vartotojo lūkesčius, priverčia vartotoją išskirti prioritetinius savo norus, ir įgalina santykinai palyginti vieną kūrimo požiūri su kitu. Kiekvienas užsakovo atributas yra patenkinamas techniniu sprendimu.

5. Kodėl yra svarbu apibrėžti sistemos operacinius reikalavimus? Kokio informacija yra sukaupiama? Operacinių reikalavimų formuluotės yra sistemos kūrimo pagrindas. Sistemos operaciniai reikalavimai apibūdina: • operacinį paskirstymą • misijos profilį arba scenarijus • veikimą ir su juo susijusius parametrus • naudojimo reikalavimus • efektyvumo reikalavimus • operacinį gyvavimo ciklą (GC) • aplinką

6. Kodėl svarbu apibrėžti tikslius paskirties scenarijus (ar ope-racinius profilius) sistemos operacinių reikalavimų kontekste ? Apibrėžiant sistemos paskirtį svarbu žinoti kokias tikslias funkcijas ji turės atlikti siekiant patenkinti visus kliento poreikius. Tai galima apibrėžti eile operacinių profilių iliustruojant dinaminius aspektus reikalingus atlikti numatytai sistemos misijai. Kiekvienas vartotojo reikalavimas turi turėti jį apibūdinantį scenarijų. Kadangi reikalavimai rašomi užsakovui suprantama kalba, todėl dėl kalbos semantinių ypatybių gali atsirasti dviprasmybės. Scenarijus apibūdina kokie konkretūs veiksmai atitinka konkretų vartotojo reikalavimą.

7. Kokia informacija turėtų būti sukaupta sistemos palaikymo koncepcijoje? Kaip ji vystoma, ir kuriuo sistemos gyvavimo ciklo momentu turėtų būti suformuota? Palaikymo koncepcija plėtojama nuo sistemos operacinių reikalavimų apibrėžimo ir įtraukią visą eilę įvairių veiksmų. Palaikymo koncepcija paprastai apima informaciją apie: • palaikymo lygius • inventoriaus taisymo strategijas • organizacinę atsakomybę • logistinius palaikymo elementus • efektyvumo reikalavimus • aplinką Palaikymo koncepcija suteikia pagrindą palaikymo ir priežiūros reikalavimų įgyvendinimui sistemos projektavime. Labai svarbu, kad sistemos palaikymo ir aprūpinimo koncepcija būtų suformuota konceptualaus projektavimo fazėje.

8. Kaip sistemos operaciniai reikalavimai įtakoja palaikymo koncepciją ? Sistemos operaciniai reikalavimai labai glaudžiai susiję su sistemos palaikymo ir aprūpinimo reikalavimais. • Operacinis paskirstymas įtakoja logistinį palaikymą, t.y. jei sistema paskirstyta įvairiose srityse, kokiu būdu bus užtikrinta atsarginių sistemos dalių tiekimas, kaip ir kur bus apmokomas personalas ir pan. • Taip pat efektyvumo reikalavimai glaudžiai susiję tarpusavyje. Kiek sistema efektyviai dirbs priklauso nuo to, kiek efektyviai bus atliekamas aptarnavimas, keičiamos sugedusios dalys ir pan. • Nuo sistemos eksploatavimo aplinkos taip pat priklauso ir palaikymo galimybės bei reikalingi tam resursai. • Taip pat numatant sistemos gyvavimo ciklą, turi būti užtikrintas sistemos palaikymas viso gyvavimo ciklo metu.

9. Kaip palaikymo koncepcija veikia sistemos/produkto projektavimą? Pateikit pavyzdžių. Palaikymo koncepcija nurodo gaires kaip sistema turėtų būti kuriama siekiant, kad būtų įmanoma ją vėliau aptarnauti. Priklausomai nuo numatytos sistemos palaikymo strategijos, atitinkamai turi būti kuriamos jos sudedamosios dalys, kaip pavyzdžiui: atsarginių dalių tipas, testavimo įrangos patikimumas ir t.t. Pavyzdžiui, priimtos inventoriaus taisymo strategijos tiesiogiai Įtakoja kuriamos sistemos atsarginių dalių konstrukciją bei pačios sistemos projektavimą atsižvelgiant į tų dalių panaudojimo galimybes.

10. Pasirinkite kokią nors sistemą ir suformuokite jai operacinius reikalavimus. Remiantis gautais rezultatais apibrėžkite palaikymo koncepciją. Atvaizduokite reikalingus operacinius ir palaikymo srautus, nustatykite taisymo strategijas, ir atitinkamai pritaikykite kiekybinius efektyvumo faktorius.

11. Spręsdami, derėtų ar ne nurodyti dviejų ar trijų lygių priežiūros koncepciją, į kokius veiksnius jūs atsižvelgtumėt? Priežiūros lygiai – korekcinis ir profilaktinis palaikymas gali būti atliktas pačios sistemos toje vietoje kur ji naudojama, tarpininko ar paties gamintojo. Palaikymo lygis priklauso nuo funkcijų lygio ir nuo kiekvienai sričiai skirtų užduočių. Priklausomai nuo sistemos paskirties ir prigimties galimi nuo dviejų iki keturių palaikymo lygiai. Palaikymą galima klasifikuoti į tris grupes: organizacijos, tarpininkų, gamintojo. Renkantis naudoti dviejų ar trijų lygų palaikymą, reiktų atsižvelgti į: • kiek dažnai reikalinga profilaktinė priežiūra • sistemos sudėtingumą • ją besinaudojančio personalo įgūdžius • ar sistema plačiai paskirstyta • kokio sudėtingumo ir tikslumo reikalauja sistemos palaikymas

12. Priežiūros koncepcijos kūrimo esmė yra tame, kad visi priežiūros lygiai yra sukurti bendru pagrindu. Kodėl? Priežiūros koncepcija yra pagrindas nustatant priežiūros ir palaikymo reikalavimus sistemos projektavime. Norint pilnumoje atlikti visus sistemos kūrimo tikslus, yra būtina visus sistemos aspektus kurti bendru pagrindu nuo pat sistemos kūrimo pradžios. Visi sistemos elementai tūri būti sukurti vieningai (vienu pagrindu) siekiant užtikrinti sistemos palaikymą visu jos gyvavimo ciklo metu.

13. Kodėl yra svarbus techninių sistemos našumo matavimų (TPM) įvertinimo parengimas ? Iš operacinių reikalavimų ir priežiūros bei palaikymo koncepcijos, išsivystė kokybinių ir kiekybinių kriterijų kūrimas. Kiekybiniai faktoriai arba metrikos asocijuojamos su sistemų vystymu. Šios metrikos arba techniniai sistemos našumo matavimai (TPM) Lemia projektavimo sąlygojamų parametrų identifikavimą (DDP). Tai yra būtina sąlyga siekiant nustatyti atitinkamas projekto akcento sritis, identifikuoti projektui reikalingų sąnaudų kriterijus, ir nustatyti galimą riziką, jei minėti kriterijai būtų neįvykdyti. TPM apima: • sistemos pralaidumą • energijos sąnaudas • sistemos masę • sistemos prieinamumą ir kita

14. Sistemos parametras Reikalavimai parametrui (metrika) Dabartinės sistemos parametrų reikšmės Santykinė parametro svarba (vartotojo pažiūriu) (%) Proceso trukmė (dienomis) 30 dienų (Maksimumas) 45 dienų (Sistema M) 10 Greitis (km/h) 100 km/h (Minimumas) 115 km/h (Sistema B) 32 Prieinamumas (Operacinis) 98.8% (Minimumas) 98.9 % (Sistema H) 21 Išmatavimai (m) Ilgis: 3 m Plotis: 2m Aukštis: 1m (Maksimumas) Ilgis: 2,5 m Plotis: 3m Aukštis: 1m (Sistema M) 17 Žmogiškieji faktoriai Mažiau nei 1 % klaidų tikimybė per metus 2% per metus (Sistema B) 5 Svoris (kg) 300kg (Maksimumas) 320kg (Sistema H) 6 Eksploatuojamumas 200km (Minimumas) 150km (Sistema H) 9 100 Apibūdinkite žingsnius kuriuos atliktumėte formuojant tokią informaciją 1. Pav. Techninės MBH sistemos charakteristikos

15. Apibūdinkite žingsnius kuriuos atliktumėte formuojant tokią informaciją • Vartotojo poreikių nustatymas (atributai) • Poreikių kategorizavimas (išskirti svarbius ir mažiau svarbius) • Esamos sistemos analizė ir jos techninis įvertinimas (inžineriniai projektavimo matai – greitis, užduotys, masė ir t.t) • Ryšių tarp posistemių nustatymas

16. Kaip jūs panaudotumėte duotą informaciją (1 pav.) sistemos projektavimo procese. ? Kaip matyti iš vartotojo poreikių, svarbiausią dėmesį kuriant sistemą reikėtų skirti greičio parametrui. Kitas pagal svarbą parametras tai sistemos prieinamumas, t.y. sistema turi būti pasiekiama vartotojo min 98.8% jos darbo laiko. Mažiausiai svarbūs parametrai – sistemos svoris bei žmogiškieji faktoriai. Turima informaciją galima panaudoti testuojant sukurtą naują sistemą, ar ji atitinka vartotojo reikalavimus (greitis, svoris ir t.t.). Kuriant priežiūros koncepciją turėtume atsižvelgti į sistemos eksploatuojamumo parametrą.

17. Ką reiškia funkcinė analizė? Kokiam tikslui ji reikalinga? Kada sistemos gyvavimo cikle ji atliekama? Ar funkcinė analizė gali būti atlikta bet kokiai sistemai? Funkcinė analizė – tai iteracinis procesas kurio metu sisteminiai reikalavimai yra pervedami į detalius projekto kriterijus, kartu identifikuojant specifinių resursų poreikius posistemėse. Pradedama nuo abstrakčių vartotojo poreikių ir einama toliau link reikalavimų techniniai įrangai, programiniai įrangai, žmonėms, sistemos galimybėms, duomenims ir t.t. Funkcinės analizės tikslas – identifikuoti sistemos resursus ir komponentus. Rezultatas atvaizduojamas kaip sistemos funkcionalumo dalinis apibrėžimas. Funkcinė analizė atliekama reikalavimų analizės metu. Kuriant bet kokią sistemą yra atliekama sistemos reikalavimų analizė, tuo pačiu atliekama ir funkcinė analizė.

18. Kaip funkcinė analizė veda prie konkrečių resursų reikalavimų apibrėžimo tokių kaip techninė įranga, programinė įranga, žmonės, duomenys? Trumpai apibūdinkite žingsnius. Koks yra blokų numeravimo tikslas (2pav.) Reikalavimai konkretiems resursams yra nustatomi posistemėse ir žemesniuose lygiuose. Pradedant nuo vartotojų poreikių einama link technikos, programinės įrangos, žmonių duomenų ir t.t. bei jų kombinacijų identifikavimo. • Identifikuojamos sistemos funkcijos (kurias ji turi atlikti) • Sudaromos blokinės funkcinių srautų diagramos (pav 2). Jos sudaro tam tikrus funkcijų lygius (top lygis ir posistemės). Jos sudaromos tam, kad aprašyti sistemos struktūrą funkcinėmis priklausomybėmis. Padeda atvaizduoti funkcijų struktūra bei pagrindines jų sąsajas. • Sekantis žingsnis – funkcinis paskirstymas. Panašios funkcijos grupuojamos į pogrupius, kurie nusako pagrindines posistemes ir žemo lygio elementus. Šiame žingsnyje ir yra funkcijos verčiamos konkrečiais resursų reikalavimais. Blokų numeracija skirta “top-down” priklausomybei tarp reikalavimų žymėti (vėliau “bottom-up” resursų atrinkimui šių reikalavimų požiūriu).

19. Reikalavimai sistemai Sistemos Top lygio funkcijos 1.0 2.0 3.0 4.0 Funkcija A Funkcija B Funkcija C Funkcija D 5.0 6.0 Funkcija E Funkcija F Antrojo lygio funkcijos Į antrąjį funkcijų lygį 5.1 5.3 5.5 Į trečiąjį funkcijų lygį 2. Pav. Sistemos f-nis išskirstymas

20. Koks yra paskirstymo tikslas? Kokio gylio paskirstymas turėtų būti atliktas sistemos hierarchinėje struktūroje? Kaip tai įtakoja sistemos projektavimą? • Turint aukščiausio lygio sistemos funkcinį aprašą, tolimesnis žingsnis yra sugrupuoti (paskirstyti) artimas funkcijas į loginius pogrupius, nustatant pagrindines posistemes ir visos sistemos žemesnių lygių elementus. • Funkcinio paskirstymo tikslas - nustatyti specifinius reikalavimus resursams posistemių lygmenyje ir žemiau. • Kuo sistema labiau paskirstyta, tuo geriau galima identifikuoti bendrus posistemių resursus. • F-nė dekompozicija turi nemažą įtaką sistemos projektavime, nes jos atlikimo metu sąvokos ”KAS” turi būti atliekama sistemos yra keičiamos į “KAIP” tai turi būti atliekama.

21. Trumpai apibūdinkite sintezę, analizę ir įvertinimą. Kaip jie susiję ? • Sintezė - tai projektavimas. Sintezė naudojama preliminarių koncepcijų vystymui ir įvairių sistemos komponentų ryšių nustatymui. • Analizė - tai procesas kurio metu nustatomos problemos, tikslai, taisyklės, įmanomos alternatyvos, įmanomi problemos sprendimo būdai. • Turint susintezuotą sistemos konfigūraciją, reikia įvertinti jos charakteristikas naudojantis prieš tai nustatytų reikalavimų požiūriu. Šie trys procesai glaudžiai susiję tarpusavyje. Atlikus analizę, pereiname prie sintezės (projektavimo). Turėdami sistemos konfigūracijos projektą, jį įvertiname. Jei reikia vėl grįžtame prie analizės. Tai iteracinis procesas.

22. Paaiškinkite ką reiškia “projektavimo sąlygojami parametrai” (DDP). Kaip jie apibrėžiami? Projektavimo sąlygojamus parametrus lemia techniniai sistemos našumo matavimai. Tai parametrai kurie tiesiogiai priklauso nuo kuriamos sistemos, t.y. kokios bus sudedamosios sistemos dalys, kur bus naudojama sistema, ir pan. Šie parametrai apima: • patikimumą • išplečiamumą • palaikomumą • suderinamumą • produktyvumą. Visi šie parametrai yra paveldimi sistemos projektavime. Kartais blogas sistemos projektas yra koreguojamas kuris reikalauja nemažai inžinerinių pastangų. Siekiant sumažinti koregavimo sąnaudas reikėtų DDP parametrus apžvelgti kuo anksčiau.

23. Koks yra formalios projekto apžvalgos tikslas?Apibūdinkite keletą modelio apžvalgos privalumų? Pateikite keletą neigiamų aspektų. • Formali projekto apžvalga koordinuoja veiklą (įskaitant susitikimus ar aibę susitikimų) siekiant patenkinti projekto inžinerinius poreikius Formalios projektavimo apžvalgos paskirtis: • Formalizuotas pasiūlytosios sistemos/posistemės patikrinimas turimų specifikacijų atžvilgiu • Suteikia bendras gaires visam projekto personalui • Vartotojo sąsajos problemų sprendimas • Sistemos elementų suderinamumo užtikrinimas • Projektavimo sprendimų formalizuotas aprašymas

24. Koks yra formalios projekto apžvalgos tikslas?Apibūdinkite keletą modelio apžvalgos privalumų? Pateikite keletą neigiamų aspektų. • Formali apžvalga yra puiki bendravimo priemonė, užtikrinanti geresnį tarpusavio supratimą tarp projektuotojų ir palaikymo personalo. • Veiksmai, atliekami po formalių projekto apžvalgų, gali sukelti betvarkę jau suplanuotoje darbotvarkėje. Priimti pasiūlymai apžvalgos metu, gali taip pat sukelti planavimo problemų. Apžvalgos naudoja vidinius kompanijos resursus (pinigus, laiką).

25. Pabaiga

26. Gamyba ir/arba konstravimas Konceptualus projektavimas Detalus projektavimas Preliminarus projektas Sistemos lygis Funkcinis išeities taškas Paskirstymo išeities taškas Produkto išeities taškas 0.0 0.1 2.3 Techninės įrangos GC Reikalavimų analizė 0.2 Grįžtamasis ryšys ir kontrolė Funkcinė analizė Tarpusavio sąveika 0.3 Reikalavimų paskirstymas Programinės įrangos GC Įvertinimas (Sistemos integracija ir testavimas) 0.4 Grįžtamasis ryšys ir kontrolė Kompromisų paieškos 0.5 Tarpusavio sąveika Sintezė 0.6 Žmogiškųjų išteklių integravimo GC Vertinimai 0.7 A tipo specifikacija Grįžtamasis ryšys ir kontrolė 0.8 Grįžtamasis ryšys Projekto peržiūra Kaip funkcinė analizė veda prie konkrečių resursų reikalavimų apibrėžimo tokių kaip techninė įranga, programinė įranga, žmonės, duomenys? Trumpai apibūdinkite žingsnius.

27. Techninės įrangos gyvavimo ciklas (GC) Iš 0.25 Iš 1.1 Iš 2.1 0.251 2.2512 1.2511 2.2513 Funkcinė grupė A Tech. įranga Detalus projektavimas ir kūrimas (Įranga, dalys, moduliai ir kt.) Preliminarus sistemos projektav. Įrangos testavimas Prototipas Grįžtamasis ryšys ir kontrolė Tarpusavio sąveika Programinės įrangos gyvavimo ciklas (GC)

28. Techninės įrangos GC Programinės įrangos GC Tarpusavio sąveika Iš 0.25 Iš 1.1 Iš 2.1 0.252 2.2524 2.2525 1.2521 2.2526 2.2522 2.2523 Funkcinė grupė B Progr. įranga Kodavimas ir CSU testavimas CSC integravimas ir testavimas Progr. Įrangos reikalavimų analizė CSCI testavimas Preliminarus sistemos projektav. Detalusis projektav. Grįžtamasis ryšys ir kontrolė Tarpusavio sąveika Žmogiškųjų išteklių integravimo GC

29. Programinės įrangos GC Tarpusavio sąveika Žmogiškųjų išteklių integravimo GC Iš 0.25 Iš 1.1 Iš 2.1 0.253 2.2532 1.2531 2.2533 Funkcinė grupė C Žmonės Detalus projektavimas ir kūrimas (Analizė, personalo poreikiai, apmokymas) Preliminarus sistemos projektav. Personalo testavimas Grįžtamasis ryšys ir kontrolė