Vilniaus universitetas Matematikos ir informatikos fakultetas Program sistem katedra

Kursas:"Program sistem ininerijos vadas" Laboratorini ir kursinio darb reikalavimai

Reng: prof. Albertas aplinskas

Vilnius, 2011

TURINYS1. Bendrieji reikalavimai............................................................................................................................................3 2. Laboratorinis darbas Verslo tiksl ir poreiki specifikacija ...............................................................................4 3. Laboratorinis darbas Koncepcinis verslo modelis ............................................................................................11 4. Laboratorinis darbas Reikalavim specifikacija ..............................................................................................25 5. Laboratorinis darbas Program sistemos eskizinis projektas ...........................................................................30 1 priedas. Lietuvos termin standart LST ISO/IEC 2382 serija-:...........................................................................37 2 priedas. Titulinio lapo pavyzdys...........................................................................................................................38 3 priedas. Darbo anotacijos pavyzdys.......................................................................................................................38

2

1. Bendrieji reikalavimai1.1. Darb sraasEil. Nr. Darbo pavadinimas Apginti iki. ______________________________________________________________________________________ 1. Verslo tiksl ir poreiki specifikacija (laboratorinis darbas) 2008.03.20 2.Koncepcinis verslo modelis (laboratorinis darbas) 2008.04.24 3. Program sistemos reikalavim specifikacija (laboratorinis darbas) 2009.05.29 4. Program sistemos eskizinis projektas (laboratorinis darbas) 2009

1.2. Darb paskirtisImokyti studentus: analizuoti ir specifikuoti vartotoj poreikius, specifikuoti kuriamos program sistemos reikalavimus, konstruoti dalykins srities koncepcinius modelius, specifikuoti program sistem architektr, UML kalbos pagrind, rengti technin dokumentacij, dirbti pagal formalius reikalavimus, dirbti grupse, planuoti grupin darb ir baigti j numatytais terminais, vieai pristatyti darb, argumentuoti priimtus sprendimus. Atliekant laboratorinius darbus, parengiamamos svarbiausiosios vartotoj poreiki specifikacijos, kompiuterizuojamos verslo sistemos koncepcinio modelio, program sistemos reikalavim specifikacijos ir program sistemos koncepcinio projekto dalys.

1.3. Laboratorini darb atlikimo tvarkaStudentai susiskirsto pogrupius po 4 mones (vienas atsakingas u pirm darb, antras u antr, treias u trei darb, ketvirtas u ketvirt darb). Kiekvienam pogrupiui suteikiamas numeris. Atsakingas asmuo vadovauja darbo darymui, taiau jiems pavestas darbo dalis atlieka visi grups nariai. Konkretus kiekvieno studento indlis darb privalo bti apraytas to darbo anotacijoje. Kiekvienas pogrupis pasirenka udavin susijus su buhalterins apskaitos, vadybos, paslaug ar kitos dalykins srities kompiuterizavimu. Udavinys turi bti toks, kad jam sprsti skirtai program sistemai bt galima suformuluoti visas nefunkcini reikalavim ris (naumas, patikimumas, apsauga, teisiniai reikalavimai, interfeiso reikalavimai). iam udaviniui pogrupis rengia keturis dokumentus (Verslo tiksl ir poreiki specifikacija, Koncepcinis verslo modelis, Program sistemos reikalavim specifikacija, Program sistemos eskizinis projektas). Kiekvienas dokumentas pristatomas ir vertinamas paymiu. Pristatymo trukm 10 minui. Pristatinja du mons, klausimai gali bti pateikti visiems grups nariams. Paymis u gebjim pristatyti raomas kiekvienam pristataniajam individualiai. Pats darbas vertinamas, atsivelgiant jo esm, gebjimus apipavidalinti pagal pateiktus reikalavimus, taisykling lietuvi kalb, taisykling termin vartosen. U darb visi grups nariai gauna t pat paym (nuo 0 iki 10 bal). Pavlavus darb apginti daugiau kaip 1 savait, paymys sumainamas 1 balu, pavlavus daugiau kaip 2 savaites 2 balais. Iimtys daromos tik ligos ar kitais ypatingais atvejais. Laboratorini darb neapgynusiems studentams egzamino laikyti neleidiama. U darb ir u pristatymus gaut paymi vidurkis sudaro pus u egzamin raomo paymio (kita pus u atsakymus ratu pateiktus klausimus per egzamin). Paymys u darb skaiiuojamas pagal formul: p=0.8 x esm + 0.1 x dokumentavimas + 0.05 x darbo kalba + 0.05 x terminija-bauda u vlavim (1) Galutinis paymys mogui skaiiuojamas pagal formul q= 0.5( 0.9 x paymi u darbus vidurkis + 0.1 x balai u pristatymus) + 0.5 x paymys u atsakymus bilieto klausimus. (2) Jei darant tolimesnius darbus paaikja, kad reikia keisti jau apgintus darbus, tai galima daryti parengiant nauj darbo versij, taiau gautas paymys dl to nekeiiamas. Nemaiau kaip par prie darbo pristatym darb (MS Word formatu) btina atsisti dstytojui Siuniamo teksto negalima archivuoti. Laiko aprae (subject) reikia nurodyti univrsitet, kurs, grup, pogrupio numer ir darbo numer. Pristatant darb, ispausdinta jo kopija atiduodama dstytojui. Konsultacijos teikiamos ir darbai pristatomi laboratoriniams darbams numatytu laiku..

3

1.4. Darb apipavidalinimasKiekvienas laboratorinis darbas apipavidalinamas atskiru dokumentu, kur sudaro: titulinis lapas, anotacija, turinys, vadas, bendroji dalis, termin odinlis, priedai. Tituliniame lape nurodomi: universitetas, fakultetas, kursas, grup, kuriamos sistemos pavadinimas, dokumento (laboratorinio ar kursinio darbo) pavadinimas, darbus atlikusi student pavards, data . versija (ji keiiama, padarius darbe pakeitimus) Anotacijoje pateikiamas bibliografinis darbo apraas, nurodomas individualus kiekvieno studento indlis atlikt laboratorin darb ir kaip, prireikus, galima susisiekti su grups nariais (kompiuterinio pato adresai bei telefonai) vad sudaro ie poskyriai: Program sistemos pavadinimas Dalykin sritis Problemin sritis Naudotojai Darbo pagrindas Naudoti dokumentai Program sistema privalo turti du pavadinimus: piln (pvz., "Gamyklos sandlio apskaitos sistema") ir trump (pvz. sistema "Sandlys"). Pilnas pavadinimas vartojamas tituliniame lape ir iame poskyryje, trumpas - dokumento tekste. Poskyryje Dalykin sritis apraoma sritis (pvz. buhalterin apskaita), kurioje numatoma naudoti kuriam program sistem. Poskyryje "Problemin sritis" apraomi udaviniai (problema), kuriuos privalo sprsti kuriamoji program sistema. Pokyryje "Naudotojai" nurodoma kokie dalykins srities specialistai (pvz., sandlininkas) naudosis kuriama sistema ir koki kvalifikacij (mokyklinis informatikos kursas, EDL, koledo diplomas, bakalauro diplomas, magistro diplomas, koks nors sertifikatas) informatikos srityje jie privalo turti, kad galt ta sistema tinkamai naudotis. Poskyryje "Darbo pagrindas" nurodoma, kad dokumentas yra parengtas kaip program sistem ininerijos laboratorinis darbas. Poskyryje "Naudoti dokumentai" pateikiami bibliografiniai apraai1 dokument (pvz., buhalterins apskaitos statymas), kuriuos daromos nuorodos darbo tekste. Apraai numeruojami. Darbo tekste nuoroda dokument daroma kvadratiniuose skliausteliuose [] (pvz.,[5]), nurodant to dokumento aprao eils numer. Poskyryje apraomi tik tie dokumentai, kuriuos toliau daromos nuorodos . Cituoti neapraytus dokumentus ar daryti juos nuorodas negalima. Bendrosios darbo dalies struktra kiekvienam dokumentui yra sava. Visuose dokumentuose bendroji dalis yra skaidoma skyrius. Raant darb. rekomenduojama vartoti terminus, teisintus Lietuvos Respublikos termin standartais (r. 1 pried). Su standartais galima susipainti Lietuvos standartizacijos departamento skaitykloje (T.Kosciukos g. 30). Terminai, kurie standartais nra iaikinti arba kurie darbe vartojami kita prasme nei ta, kuri apibrta standarte, privalo bti paaikinti poskyryje "Termin aikinimas". Visos struktrins darbo dalys (skyriai, poskyriai, skyreliai, pastraipos ir kt.) turi bti numeruojamos hierarchine tvarka (pvz, poskyriai numeruojami skyri viduje). Apraant bsim sistem, tekstas raomas liepiamja nuosaka (specifikacija - tai uduotis projektuotojams bei programuotojams, o ne naudotojams skirtas program sistemos apraas)

2. Laboratorinis darbas Verslo tiksl ir poreiki specifikacija2.1. Darbo tikslai ir paskirtisiuo darbu siekiama mokyti studentus: analizuoti versl ir specifikuoti vartotoj poreikius, UML kalbos pagrind, rengti technin dokumentacij, dirbti pagal formalius reikalavimus, dirbti grupse, planuoti grupin darb ir baigti j numatytais terminais, vieai pristatyti darb, argumentuoti priimtus sprendimus.1 Atkreipkite ypating dmes taisykling bibliografini apra daryb. To prireiks ne tik ia, bet ir raant bakalauro bei magistro darbus. 4

Veiklos tiksl ir poreiki specifikacija - tai dokumentas, rengiamas prie priimant sprendim kurti program sistem. Dokumento paskirtis yra isiaikinti, ar usakovo verslo problemas sprsti i ties gali padti kokia nors program sistema, k ta sistema turt daryti (it tyrim pagrindu ir yra raomas vado poskyris Problemin sritis), kaip ja reikt naudotis ir koki konkrei naud ji duot usakovui. Kitaip tariant, dokumento paskirtis yra tikinti usakov, kad planuojam program sistem verta pradti kurti arba, jei sistema kuriama netuirint konkretaus usakovo, tikinti pirkj, kad itoki sistem vert sigyti. Rengdami dokument Veiklos tiksl ir poreiki specifikacija, studentai veikia kaip verslo ininieriai.

2.2. Darbo bendrosios dalies struktraDarbo bendrj dal sudaro ie skyriai: verslo proceso analiz, usakovo poreiki analiz, sistemos naudojimo scenarijus, sistemos gyvendinamumo ir teikiamos naudos analiz, ivados. Atkrepkite dmes, kad kiekvienas skyrius turi bti logikai gaunamas i ankstesni skyri. Visi keturi laboratoriniai darbai sudaro logikai susiet visum ir pirmuosiuose darbuose pateikta mediaga turi bti panaudota kituose darbuose.

2.3. Skyriaus Verslo proceso analiz paskirtis, struktra ir turinysio skyriaus paskirtis isiaikinti verslo problemas, potencialias grsmes bei neinaudotas galimybes, suformuluoti verslo tobulinimo strategij (siek) ir ireikti j strategini bei operacini tiksl mediu. Teorija, reikalinga iam skyriui parayti, pateikta paskait skaidrse (6 tema. Poreiki analiz). Taip pat galima irti A. aplinskas. Program sistem ininerijos pagrindai, (I dalis, 3.1., 3.3.1. poskyriai).2 Skyri sudaro ie poskyriai: 2.1. Verslo proceso apraas 2.2. Iorin verslo proceso analiz 2.3. Vidin verslo proceso analiz 2.4. Verslo tobulinimo strategija 2.5. Strateginiai ir operaciniai tikslai verslo tobulinimo strategijai gyvendinti 2.3.1. Poskyrio Verslo proceso apraas turinys Terminas verslas (angl. bussines) apibdina tai, kuo veriamasi, kitaip tariant, koki nors veikl ar kok nors usimim. Verslas nebtinai turi bti komercinio ar gamybinio pobdio. Pavyzdiui, universitet, mokymo staig ar vyriausybini staig vykdoma veikla taip pat yra verslas. Bet kuris verslas gali bti traktuojamas kaip procesas, kuris konkuruoja rinkoje su kitais panaaus pobdio procesais. Konkurencinje kovoje yra siekiama ilikti ir, jei tai manoma, bti pranaesniu u kitus. Poskyryje Verslo proceso apraas trumpai apibdinamas analizuojamas verslas: jo pobdis, apimtys ir kt. 2.3.2. Poskyrio Iorin verslo proceso analiz turinys Bet kuris verslo procesas turi eig (naudojamus iteklius) ir ieig (veiklos rezultatus). Pavyzdiui, universiteto kaip verslo proceso svarbiausieji itekliai yra abiturientai, svarbiausieji jo veiklos rezultatai absolventai. Kitaip tariant, is verslo procesas abiturientus perdirba absolventus. Tiek naudojami itekliai, tiek ir veiklos rezultatai yra vertinami pagal daugel vertinimo kriterij (pvz. ir abiturientai, ir absolventai gali bti vertinami pagal j paangum), su kiekvienu kriterijumi yra siejamas koks nors kiekybinis ar kokybinis matas (pvz. paangumas gali bti matuojamas balais). Atliekant iorin analiz reikia nustatyti analizuojamo verslo proceso eigos ir ieigos struktr, vertinimo kriterijus ir su jais siejamus proceso efektyvumo matus. Taip pat reikia nustatyti kritines iais matais matuojam dydi reikmes. Kiti du verslo proceso iorins analizs aspektai yra jo reguliavimas ir jo vaizdis. Verslo procesas yra reguliuojamas vairiais juridiniais aktais (pvz. universiteto veikl reguliuoja jo statutes, buhalterins apskaitos statymas, mokslo statymas ir kt.). ie aktai nustato vairius verslo proceso vertinimo kriterijus ir su kiekvienu i j susieja tam tikr kiekybin ar kokybin mat. Panaiai yra ir su verslo proceso vaizdiu. Proces vertina vairios iorins grups (pvz. universitet vertina abiturientai, mokslin visuomen, plaioji visuomen ir kt.), kiekviena i j turi savus vertinimo kriterijus ir sieja su tais kriterijais siejamus tam tikrus kiekybinius ar kokybinius efektyvumo matus. Taip pat turi bti apibrtos kritins iais matais matuojam dydi reikms. Atliekant iorin analiz reikia nustatyti, kokiais juridiniais aktais yra reguliuojama analizuojamo verslo proceso veikla, pagal kokius kriterijus sutinkamai su iais aktais yra vertinamas verslo procesas ir kokie matai yra susieti su iais kriterijais. T pat reikia padaryti ir analizuojant vaizd: nustatyti koki grupi vertinimas yra svarbus, pagal kokius kriterijus jos vertina verslo proces ir kokius matus sieja su tais kriterijais. Poskyr sudaro du skyreliai: analizs rezultatai, problemos, grsms ir neinaudotos galimybs. Pirmjame skyrelyje apraomi:2 Patartina taip pat susipainti su mediaga, pateikta adresais http://www.quickmba.com/strategy/swot/, http://www.businessballs.com/swotanalysisfreetemplate.htm 5

proceso eiga, ieiga, reguliavimas, vaizdio elementai; proceso eigos, ieigos, prisitaikymo reguliavimui ir vaizdio matavimo bdas, vertinimo kriterijai ir kritins matuojam dydi verts; analizs rezultatai, t.y. proceso eigos, ieigos, prisitaikymo reguliavimui ir vaizdio matavimo bei vertinimo rezultatai. Antrajame skyrelyje apraomos iorins analizs metu irykintos verslo problemos, verslo grsms ir neinaudotos galimybs. Problemos ir grsms apraomos pasinaudojant analizs rezultatais. Problema yra tuomet, kuomet pagal matavimo rezultatus atitinkamo dydio vert yra maesn u kritin, o grsm tuomet, kuomet ta vert artima kritinei. 2.3.3. Poskyrio Vidin verslo proceso analiz turinys iame poskyryje verslo problemos ir grsms detalizuojamos, irykinant dl koki vidini verslo prieasi jos kyla. Pavyzdiui, gali paaikti, kad per didel gaminam gamini ar teikiam paslaug kaina atsiranda dl to, kad verslo procese yra perdaug rankini operacij (jas bt galima kompiuterizuoti) ir dl to tenka mokti atlyginimus daug didesniam darbuotoj skaiiui negu reikt i ties. 2.3.4. Poskyrio Verslo tobulinimo strategija turinys iame poskyryje formuluojama verslo tobulinimo strategija (siekis). Bendruoju atveju strategija turi numatyti kokias i iorins analizs metu suformuluot problem bei grsmi bus siekiama paalinti ir kurias i neinaudot verslo galimybi bus siekiama panaudoti. Strategijos parinkimas nra vienareikmis, priklauso nuo usakovo ir verslo ininieriaus poiri. Vienas problemas ar grsmes jie gali laikyti esminmis, kitas ne, gali manyti, kad nauj galimybi panaudojimas sustiprins verslo konkurencin geb arba, kad itaip nevyks. Be to, ir esamas problemas galima sprsti skirtingai. Pavyzdiui, universitetas gali stengtis minimizuoti studij kain ir stengtis pritraukti kuo daugiau abiturent, tikdamasis studij eigoje i j atrinkti geriausius. Kita strategija bt branginti studijas (didinti studento rengimo savikain), priimant nedidel student kiek ir itaip gerinti absolvent kokyb. Apskritai, strategija turi bti suformuluota keliais sakiniais (ne daugiau kaip 5), taiau prie jos gali bti pridta paaikinimas, kodl pasirinkta btent tokia strategija (motyvacija). 2.3.5. Poskyrio Strateginiai ir operaciniai tikslai turinys Verslo strategija detalizuojama, ireikiant j strategini tiksl rinkiniu. Strateginiai tikslai detalizuojami, kiekvien i j ireikiant operacini tiksl rinkiniu. Kitaip tariant, siekiam verslo tiksl visuma sudaro med: Siekis 1-as strateginis tikslas 1.1 operacinis tikslas 1.2 operacinis tikslas 1.M operacinis tikslas 2-as strateginis tikslas 2.1 operacinis tikslas 2.2 operacinis tikslas 2.3 operacinis tikslas .. 3-as strateginis tikslas 3.1 operacinis tikslas 3.2 operacinis tikslas 3.3 operacinis tikslas .. N-as strateginis tikslas N.1 operacinis tikslas N.2 operacinis tikslas N.3 operacinis tikslas .. N.K operacinis tikslas Reikalui esant, ir strateginiai, ir operaciniai tikslai gali bti keleto lygmen. Priminsime, kad strateginiai tikslai nusako paius bendriausius, ilgalaikius usakovo ketinimus, o operaciniai tikslai yra konkretesni, jie turi bti konstruktyvs, terminuoti, matuojami. Ir vieni ir kiti formuluojami vadovaujantis vidins analizs rezultatais.

2.4. Skyriaus Usakovo poreiki analiz paskirtis, struktra ir turinysio skyriaus paskirtis isiaikinti koki kompiuterini resurs (dalykini program, duomen saugykl, duomen bazi ir pan.) reikia praeitame poskyryje apraytiems operaciniams tikslams gyvendinti. Kitaip tariant, tai kuriamos program sistemos paio aukiausio lygmens funkciniai reikalavimai. Kokios technins ar sistemins programins rangos prireiks siekiant operacini tiksl, iame skyriuje neaprainjama. Poreikiai apraomi lentele Nr. Operacinis tikslas . Resursai, reikalingi tikslui gyvendinti Prioritetas .. 6

Stulpelyje Operacinis tikslas nurodomas tikslo numeris tiksl medyje, stulpelyje Prioritetas nurodoma kokia eils tvarka reikt gyvendinti stulpelyje Resursai, reikalingi tikslui gyvendinti apraytas galimybes. Tai pradin mediaga bsimo projekto darb planui sudaryti. Skyriaus pabaigoje, reziumuojant aukiau pateikt lentel, daroma ivada, kad pasirinktjai verslo strategijai gyvendinti reikalinga program sistema su atitinkamomis funkcinmis galimybmis.

2.5. Skyriaus Sistemos naudojimo scenarijus paskirtis, struktra ir turinysio skyriaus paskirtis nustatyti, kaip bus dirbama kompiuterizuojamoje organizacijoje diegus kuriam program sistem ir k reikia padaryti, kad bt galima pradti itaip dirbti. Kitaip tariant, ia specifikuojami paio aukiausio lygmens vartotojo interfeiso ir darbo viet reikalavimai. Skyri sudaro ie poskyriai: Esamoji bkl Scenarijaus apraas Priemons scenarijui gyvendinti 2.5.1. Poskyrio Esamoji bkl turinys io poskyrio turinys priklauso nuo to, kaip yra kuriama sistema: pagal sutart su konkreiu usakovu ar pardavinti rinkoje. Kuriant sistem pagal sutart su konkreiu usakovu, poskyryje apraoma esama kompiuterizavimo bkl usakovo organizacijoje: koki technin ir programinh rang jis naudoja, kas j aptarnauja ir priiri, kokia yra darbuotoj kvalifikacija darbo su kompiuteriais srityje ir pan. Kuriant program sistem tikslu pardavinti j rinkoje, apraomos prielaidos apie kompiuterizavimo bkl t program sistem sigyjanioje organizacijoje. 2.5.2. Poskyrio Scenarijaus apraas turinys iame poskyryje UML sek diagrama (r. paskait skaidres 7 tema. UML.) apraoma, kaip bus dirbama su sistema j diegus. Sistemai ir kiekvienai darbo vietai diagramoje imama atskira objekto gyvavimo atkarpa. Parodomos ne tik tiesiogiai su sistema dirbani asmen darbo vietos, bet ir asmen ruoiani sistemai pateikiamus duomenis ar besinaudojani jos darbo rezultatais darbo vietos. Reikia parodyti taip pat ir sistem aptarnaujani bei priirini asmen darbo vietas. Prie diagramos pridedamas darbo viet apraas, kuriame apraoma kokios technins bei programins rangos reikia toje darbo vietoje ir kokius kvalifikacinius reikalavimus privalo tenkinti joje dirbantis asmuo. 2.5.3. Poskyrio Priemons scenarijui gyvendinti turinys iame poskyryje, lyginant esamos bkls ir darbo viet apraus, nustatoma, k reikia padaryti (sigyti technin bei programin rang, rengti tinklus ar darbo vietas, pasamdyti naujus darbuotojus, apmokyti darbuotojus, sukaupti duomenis duomen bazes ir kt.), kad bt galima pradti dirbti pagal aukiau aprayt scenarij. Technin ir sistemin programin ranga specifikuojama bendrais bruoais, nenurodant konkrei detali, nes jos ia dar negali bti inomos.

2.6. Skyriaus Sistemos gyvendinamumo ir teikiamos naudos analiz paskirtis, struktra ir turinysio skyriaus paskirtis isiaikinti ar reikiam program sistem tikrai manoma sukurti, koki konkrei naud ji duos ir ar j verta kurti. Skyri sudaro ie poskyriai: Operacinis gyvendinamumas Techninis gyvendinamumas Ekonominis gyvendinamumas Juridinis gyvendinamumas Sistemos panaudojimas Sistemos teikiama nauda 2.6.1. Poskyrio Operacinis gyvendinamumas turinys iame poskyryje analizuojami program sistemos diegimo inovaciniai slenksiai (r. A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 29 psl.) ir parodoma, kad jie gali bti paalinti. Kitaip tariant, parodoma kad silomas sistemos naudojimo scenarijus bus priimtinas tiems, kas pagal j dirbs ir kad jie gals pagal scenarij dirbti efektyviai. 2.6.2. Poskyrio Techninis gyvendinamumas turinys iame poskyryje reikia parodyti, kad inoma kaip sistem gyvendinti (pvz. yra panaios sistemos, inomi sistemos sprendiam udavini sprendimo algoritmai ir pan.), kad scenarijuje numatytos technins ir sistemins programins rangos galimum pakaks sistemos veikimui utikrinti ir kad grup yra pajgi (iklaus atitinkamus kursus, kr panaias sistemas, pageidautina pateikti grups nari CV) itoki sistem sukurti 2.6.3. Poskyrio Ekonominis gyvendinamumas turinys iame poskyryje reikia paskaiiuoti projekto kain, scenarijaus diegimo ilaidas, metines eksploatavimo ilaidas, sistemos duodamas metines pajamas, paskaiiuoti per kiek laiko sistema atsipirks ir parodyti, kad usakovas yra pajgus padaryti reikiamas pradines investicijas. 2.6.4. Poskyrio Juridinis gyvendinamumas turinys iame poskyryje reikia parodyti, kad sukuriant sistem nebus paeisti LR Konstitucijos (valdi atskyrimo principas), Asmens duomen apsaugos statymo, Statistikos statymo ar kit LR teiss akt numatyti draudimai.

7

2.6.5. Poskyrio Sistemos panaudojimas turinys iame poskyryje pateikiama UML uduoi diagrama (r. paskait skaidres 7 tema. UML) kurioje parodoma, kas ir kokias uduotis vykdys naudodamasis sistema ir, komentaruose, kaip sistema pads tas uduotis vykdyti. 2.6.6. Poskyrio Sistemos teikiama nauda turinys iame poskyryje pateikiama UML uduoi diagrama (r. paskait skaidres 7 tema. UML) kurioje parodoma, kas ir kokias uduotis vykdys naudodamasis sistema ir, komentaruose, koki konkrei naud (operatyvesn informacij, isamesn informacij ir pan.) kiekvienas agentas i to gaus.

2.7. Skyrius Ivadosiame skyriuje, naudojantis kituose skyriuose pateikta mediaga, parodoma, kad sistem tikrai yra verta kurti.

2.8. Pirmo darbo vertinimo metodika2.8.1. Vertinimas pagal skyrius Skyrius Titulinis Anotacija Turinys 1. vadas Poskyris Skyrelis vertispaymys paymys paymys paymys paymys paymys paymys paymys paymys paymys Analizs rezultatai Problemos, grsms, galimybs paymys paymys paymys paymys paymys paymys Esamoji bkl Scenarijaus apraas Priemons scenarijui gyvendinti Operacinis gyvendinamumas Techninis gyvendinamumas Ekonominis gyvendinamumas Juridinis gyvendinamumas Sistemos panaudojimas Sistemos teikiama nauda paymys paymys paymys paymys paymys paymys paymys paymys paymys paymys paymys paymys paymys

2. Verslo proceso analiz

PS pavadinimas DS PS Naudotojai Darbo pagrindas Naudoti dokumentai Verslo proceso apraas Iorin verslo proceso analiz Vidin verslo proceso analiz Verslo tobulinimo strategija Strateginiai ir operaciniai tikslai

3. Usakovo poreiki analiz 4. Sistemos naudojimo scenarijus

5. Sistemos gyvendinamumo ir teikiamos naudos analiz

6. Ivados Skyri numeracija Termin odynas CV 2.8.2. Darbo tiksl realizavimas analizuoti ir specifikuoti vartotoj poreikius (vertis), UML kalbos pagrind (vertis), rengti technin dokumentacij (vertis), dirbti pagal formalius reikalavimus (vertis), dirbti grupse (vertis), planuoti grupin darb ir baigti j numatytais terminais (vertis), vieai pristatyti darb, argumentuoti priimtus sprendimus (vertis).

8

2.8.3. Darbo klaid vertinimas 1 darbas. Klaid suvestin (Pateiktas vertinimo pagal pogrupius pavyzdys, + paymtos klaidos)

9

Klaidos Dokumentavimo klaidos titulinis anotacija turinys darbo struktra dokument sraas bei nuorodos j CV odynlis diagram kokyb trksta diagram apra puslapiavimas puslapi numeriai skyri numeracija kitos

1 9 +

2 8 + +

3 6 + + + +

4 8 + + +

5 8 + + +

6 6 + + + + + + +

7 9

8 5 + + + +

9 8 + +

10 7 + + +

11 7 + + +

12 7

13 9 +

14 9

+

+

+ + +

+

+ + +

+ + +

+ +

+ +

+ + + +

+ +

+ +

+ + + + +

+ + +

+ + +

+ + +

+ + + +

+ +

+

10

Klaidos Dalykines klaidos dalykin sritis problemin sritis vartotoj kvalifikaciniai reikalavimai verslo iorin analiz apraas eiga ieiga matai kriterijai matavimo rezultatai problemos grsms galimybs vidin analiz strategija tikslai ar verslo terminais ar susieti su problemomis, grsmmis, galimybmis ar nueita iki operacini tiksl poreikiai ar poreikiai ar susieti su tikslais ar prasmingi prioritetai scenarijus esama bkl ar praneimai parametrizuoti ar objektai tipizuoti ar susietas su poreikiais ar apraytos darbo vietos priemoni planas ar isamus ar nepaeisti technins rangos specifikavimo reikalavimai operacinis gyvendinamumas ar atlikta inovacini slenksi analiz techninis gyvendinamumas ekonominis gyvendinamumas juridinis gyvendinamumas sistemos panaudojimas teikiama nauda dokumento dalys blogai siejamos tarpusavyje

1 8 + +

2 9 + + +

3 6 + + + + + + +

4 9 +

5 9

6 6 + +

7 7

8 6 + + +

9 8

10 7

11 8 + + +

12 8 + +

13 9 + +

14 8

+ + + + + + + + +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ + +

+

+

+ +

+ + + + + + +

+ +

+

+ +

+

+

+

+ + + +

+

+

+ + + + + + + + + + + + + +

+ + + + +

+ + + + + +

+ + + + + + + + + +

+ + + + + +

+ + + +

+ + + + +

+

+ + + +

+ +

+ +

+ + +

+ +

+ +

+

+ + + + + +

+ +

+ +

+ + + + + 9 + 10 2 + + 10 10 + + 9 + 10 2 + 10 10 2 + 9 + 10 + + + + 4 + 8 1

+ + + + 8 + + 10 + + + + 4 + 9 2 + + + 9 + 10 1 + + + + + 10 10 2 + + + 9 + 10 2 +

+

+ + + 8 + + 7 1 + 9 + 10 2 10 10 2

Terminai Terminija termin odynas Lietuvi kalba Minusai u vlavim

3. Laboratorinis darbas Koncepcinis verslo modelis3.1. Darbo tikslai ir paskirtisiuo darbu siekiama mokyti studentus: 11

analizuoti ir modeliuoti dalykines sritis, UML kalbos pagrind, rengti technin dokumentacij, dirbti pagal formalius reikalavimus, dirbti grupse planuoti grupin darb ir baigti j numatytais terminais, vieai pristatyti darb, argumentuoti priimtus sprendimus. Realiuose projektuose abu dokumentai Koncepcinis verslo modelis ir Veiklos tiksl ir poreiki specifikacija yra rengiame vienu metu, t.y. atliekant dalykins srities (kompiuterizuojamo verslo proceso) analiz. Abiejuose dokumentuose skirtingais aspektais apraomi analizs rezultatai, jie vienas kit papildo. Dokumentu Koncepcinis verslo modelis yra naudojamasi analizuojant verslo analizs metu nustatyt problem ir grsmi vidines prieastis. ia prasme dokumentas Koncepcinis verslo modelis naudojamas kaip pagalbinis rengiant dokument Veiklos tiksl ir poreiki specifikacija. Taiau is dokumentas yra naudojamas taip pat ir rengiant dokumentus Program sistemos reikalavim specifikacija (3 laboratorinis darbas) ir Program sistemos eskizinis projektas. Taigi, jo naudojimo sfera yra platesn. iame kurse laboratoriniai darbai yra atliekami nuosekliai, vienas po kito. Todl laboratorinis darbas Koncepcinis verslo modelis yra atliekamas po darbo Veiklos tiksl ir poreiki specifikacija. .Dokumento Koncepcinis verslo modelis paskirtis yra isamiai ir pakankamai grietai aprayti, kokias uduotis vykdo dalykinje srityje veikiantys agentai (specialistai, programos, renginiai ir kt.), pagal kokius scenarijus jie dirba vykdytami tas uduotisi, kokie resursai ir kaip yra panaudojami realizuojant scenarijus, ir kokie rezultatai yra gaunami vykdius uduotis. Kitaip tariant, dokumento paskirtis yra pateikti nuosekl ir isam dalykinje srityje vykstanio verslo proceso model, kur bt galima panaudoti irykint verslo problem ir grsmi vidinms prieastims analizuoti, kuriamos program sistemos reikalavimams formuluoti ir jos koncepcinei architektrai projektuoti. Rengdami dokument Koncepcinis verslo modelis, studentai veikia kaip sisteminiai analitikai.

3.2. Darbo bendrosios dalies struktraDarbo bendrosios dalies struktra priklauso ir nuo to, kokie dalykins srities aspektai yra modeliuojami, ir nuo to kokia dalykins srities analizs metodika yra vadovauijamasi. Reikalaujama, kad btinai bt modeliuojami ie dalykins srities (verslo proceso) aspektai: uduotys, uduoi vykdymo scenarijai, dalykins srities statin struktra (esybs, j charakteristikos, ryiai), dalykins srities dinamin struktra (esybi gyvavimo ciklai). Jei grupei atrodo reikalinga, ji gali modeliuoti daugiau dalykins srities aspekt. Rekomenduojama vadovautis metodika, aptariama paskait skaidrse (7 ir 8 skaidrs), o taip pat knygoje A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 277-287 p.p., taiau grup gali pasirinkti ir kuri nors kit metodik. Jei vadovaujamasisiloma metodika ir modeliuojami aukiau ivardinti dalykins srities (verslo proceso) aspektai, tai bendrj dal sudaro ie skyriai: Esmins uduotys ir j vykdymo scenarijai Struktrinis dalykins srities modelis Dinaminis dalykins srities modelis Ivados

3.3. Skyriaus Esmins uduotys ir j vykdymo scenarijai paskirtis, struktra ir turinysUduotys svarbiausioji dalykins srities modeliavimo priemon. Skiriamos esmins ir neesmins verslo uduotys. Esmins uduotys yra sustambintos (apibendrintos) uduotys. Paprastai organizacijose toki uduoi esti nedaug (nedaugiau kaip 5-6). Pavyzdys Draudimo bendrov vykdo ias esmines uduotis: draudimo sutari sudarymas, draudimo sutari nutraukimas, draudimo sutari atnaujinimas (pratsimas), klient pateikt iekini dl draudimo imok nagrinjimas. Visas uduotis, galbt iskyrus sutari nutraukim, inicijuoja bendrovs klientai, t.y. iose verslo transakcijose jie veikia kaip pirminiai agentai. Nagrindama klient pateiktus iekinius, draudimo bendrov naudojasi antrini agent paslaugomis, pavyzdiui, policija turi palidyti autovyki apraus. Vykdant visas esmines uduotis veikia ir kitas antrinis agentas bankas, nes jis tarpininkauja visuose kliento ir draudimo bendrovs vykdomuose tarpusavio finansiniuose atsiskaitymuose. Gali veikti ir kitas antrinis agentas patas, naudojamas draudimo bendrovs susirainjimui su klientais. Yra analizuojamos ir modeliuojamos ne visos esmins uduotys, o tik tos, kurias planuojama kompiterizuoti, t.y. kurios trauktos sistemos panaudojimo diagram pateikt dokumente Veiklos tiksl ir poreiki specifikacija. Pavyzdys Jeigu nagrinjant draudimo bendrovs poreikius, pavyzdiui, buvo nusprsta, kad visos problemos sietinos tik su viena i esmini uduoi, tarkime, iekini nagrinjimu, tai kit uduoi galima ir nemodeliuoti, o i uduot i karto suskaldyti iek tiek smulkesnes uduotis. 12

Verslo modeliavimas pradedamas veiklos diagrama. ioje diagramoje verslas modeliuojamas esmini uduoi ir jomis keiiam verslo objekt terminais. io skyriaus paskirtis sudaryti t uduoi modelius. Atkreipkite dmes, kad iame darbe sudaromas koncepcinis verslo proceso (dalykins srities) modelis, o ne kuriamos program sistemos modelis. Tai reikia, kad uduotys modeliuojamos ne taip, kaip jos bus vykdomos sukrus program sistem (sutinkamai su Veiklos tiksl ir poreiki specifikacijoje patektu scenarijumi, bet taip, kaip jos yra vykdomos analizs metu, t.y. kol planuojamos kurti program sistemos dar nra. Todl kai kurios scenarijuje parodytos uduotys, pavyzdiui, sistemos administravimo uduotys, ia apskritai nenagrinjamos. Skyri sudaro ie poskyriai: Koncepcinis verslo modelis Uduoties .. modelis Antrasis poskyris kartojamas tiek kart, kiek yra esmini uduoi. 3.3.1. Poskyrio Koncepcinis verslo modelis turinys ir struktra iame poskyryje pateikiamas esamos verslo sistemos modelis. Kitaip tariant, is modelis parodo kaip vyksta kompiuterizuojamasis verslo procesas kol dar nra planuojamos kurti program sistemos. Modeliuojami tik planuojami kompiuterizuoti verslo aspektai. Poskyris dalinamas tris skyrelius: bendroji verslo schema, verslo scenarijus, esmins uduotys. Skyrelyje Bendroji verslo schema pateikiama veiklos diagrama UML kalba (r. A. aplinskas. Program sistem ininerijos pagrindai, II dalis, 213-214 p.p.) ir j paaikinantis tekstas. Diagrama turi parodyti kaip vyksta kompiuterizuojamasis verslas, t.y. kokiais vykiais inicijuojamos esmins uduotys, kas atsakingas u j vykdym, kokiais objektais operuojama jas vykdant ir kokie yra vykdymo rezultatai. Kitaip tariant, veiksmo bsenos iuo atveju yra tapatinamos su esminmis uduotimis. Veiklos diagramos pavyzdys:K lien tas Prekybos skyrius Buhalterija

Prayti p aslau os g

Klien to p aren ta g sskaita

Reg istru ota sskaita

Gau ti sskait Mokti

U ild p yti sskait

Ap okm ta sskaita

teikti sskait

U ild p yta sskaita

Rin kti sskaitas

Priminsime, kad UML veiklos diagramose gali bti vartojami ie elementai: bsenos o pradins, o veiksmo, o galins; valdymo operatoriai (nuoseklus jungimas, iakojimas, ak sujungimas); objektai (u veiksm atsakingi objektai, objekt bsenos, objekt srautas); atsakomybs juostos; valdaniosios piktogramos; paketai; pastabos. Pradin bsena - tai bsena, kurioje prasideda diagrama apraoma veikla. Galini bsen gali bti kelios. Kiekvienoje i j modeliuojamoji veikla pasibaigia. Veiksmo bsenos slepia savyje kok nors vidin veiksm ir turi bent vien pereig kit bsen, inicijuojam ireiktiniu bdu nespecifikuoto vidinio veiksmo baigimo vykio (jei pereigos yra slygins, tai gali bti ir kelios pereigos). Veiksmas uduodamas ant veiksmo keiiamo objekto atribut ir ryi. J galima aprayti naturalija kalba, pseudokodu arba kokia nors programavimo kalba. Skyrelyje Verslo scenarijus pateikiama sek diagrama UML kalba (r. paskait skaidres, 7 tema. UML) ir j paaikinantis tekstas ((r. paskait skaidres, 8 tema. Uduoi modeliavimas). i diagrama parodo, kaip komunikuoja dalykins srities agentai, vykdydami esmines uduotis. Praneimai diagramoje traktuojami kaip reikalavimai vykdyti

13

esmines uduotis. Diagram aikinantis tekstas turi formalizuot struktr (r. emiau pateikt pavyzd) ir yra sudarytas i i dali3: scenarijaus pavadinimas, scenarijaus versija verslo sistema, uduotis (siekiamas tikslas), pirminis agentas, antriniai agentai, "prie" slyga, po slyga, scenarijaus ingsni seka, scenarijaus pltiniai, neisprsti klausimai. Verslo scenarijus parodo kokiu bdu dalykins srities agentai pasieks (arba nesugebs pasiekti) norimus tikslus.. Agentai skirstomi pirminius ir antrinius. Pirminis agentas - tai agentas, siekiantis tikslo, kuriam pasiekti reikalinga verslo sistema. Antrinis agentas - tai agentas, kurio pagalba reikalinga verslo sistemai siekiamiems tikslams pasiekti. Tiek pirminiai, tiek ir antriniai agentai yra verslo sistemos iorje. Verslo sistema yra specialus agentas (ne pirminis ir ne antrinis). Agentai, skaitant verslo sistem, turi atsakomybes (jas atitinka veiklos diagramos juostos), kurioms realizuoti jie ir siekia atitinkam tiksl. Atsakomyb nustato, u koki uduoi vykdym yra atsakingas atitinkamas agentas.. Siekdami savo tiksl, agentai vykdo esmines uduotis ios uduotys veiklos diagramoje traktuojamos kaip vykiai arba, kitaip tariant, kaip pirmini agent sveikos su sistema arba sistemos sveikos su antriniais agentais trigeriai, inicijuojantys atitinkamas atsakomybes. Verslo sistemos sveika su pirminiais ir su antriniais agentais vyksta naudojantis ryio kanalais (telefonas, fail mainai, tiesiogin sveika ir pan.). Jei sistema susidoroja su savo atsakomybe, tai pirminis agentas priartja prie jo siekiamo tikslo. Jei sistema nesusidoroja su savo atsakomybe, turi bti vykdoma vadinamoji back up uduotis (tikslo siekiama kitu bdu). Tas pats pasakytina apie sistemos ir antrini agent sveik. Pavyzdys Paprastumo dlei pateikiame tik sek diagram aikinant tekst. Be to, daroma prielaida, kad modeliuojamas tik pateikt iekini modeliavimas ir i esmin uduotis jau yra suskaldyta smulkesnes uduotis. Scenarijus: draudimo imokos Versija: 1.1 Verslo sistema: draudimo bendrov Tikslas: gauti draudim u autovykyje nukentjus automobil Pirminis agentas: pretendentas gauti draudim "Prie" slyga: visi draudimui gauti reikalingi dokumentai yra sutvarkyti, iekinys nepatenkintas Po slyga: iekinys patenkintas (t.y. pretendentas gavo pinigus, draudimo bendrov juos sumokjo) Scenarijus: 1. Pretendentas pateikia bendrovei iekin ir visus reikalingus dokumentus. 2. Draudimo bendrov tikrina pretendento draudimo sutarties galiojim (neskm iame ingsnyje reikia viso tikslo neskm) 3. Draudimo bendrov skiria pareign iekiniui analizuoti. 4. Pareignas analizuoja, ar visos iekinio detals tenkina nustatytus reikalavimus (vyksta pareigno ir policijos sveika). 5. Draudimobendrov imoka iekin. Scenarijus gali bti apraytas ir lentels forma (r. A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 280 p.). Prie ir po slygos gali bti uraomos ir odiais, taiau reikia turti omenyje, kad scenarijus aprao tam tikr verslo transakcij, kuri ir yra specifikuojama iomis slygomis. Todl jos turi bti ireikiamos predikatais, uduotais ant esybi grupi, esybi ar esybi atribut. iuo aveju, slygos gali bti uraytos, pavyzdiui, itaip Sutvarkyti(Draudimui_gauti_reikalingi_dokumentai)=T & Iekinys. Bsena =nepatenkintas; Iekinys. Bsena =patenkintas. Taigi scenarijumi aprayta verslo transakcija keiia objekto Iekinys bsen. I ties, vyksta ir kiti veiksmai: bendrov netenka tam tikros pinig sumos, pervesdama j pretendentui. Taiau tai gali bti parodyta nebtinai iame modelio lygmenyje (t.y. toliau detalizuojant ios uduoties model). 1 scenarijaus ingsnis yra praneimas, inicijuojantis esmin uduot (trigeris). 5 scenarijaus ingsnis taip pat yra paprastas praneimas. 3 ir 4 yra esmins uduoties pouduotys, vykstanios verslo sistemos viduje. Jos turi bti detalizuojamos toliau, iki praneim lygmens. Policija (ir galbt kitos tarnybos, galinios palidyti pretendento pateikt duomen teisingum) yra antrinis agentas. Kaip verslo sistemos antriniai agentai vykdo savo uduotis nagrinti nereikia, nes tai jau yra u verslo proceso (iuo atveju draudimo bendrovs vykdom veiksm) rib. Skyrelyje Esmins uduotys pateikiama uduoi diagrama UML kalba (r. (r. paskait skaidres, 7 tema. UML.) ir j paaikinantis tekstas (r. paskait skaidres, 8 tema. Uduoi modeliavimas). Diagrama parodo esmini3

Jei skyrelyje aprayti keli scenarijai, tokia yra kiekvieno j aprao struktra. 14

uduoi (t.y. scenarijaus ingsni) tarpusavio sryius. Apskritai, diagramoje pasirodo tiktai tie scenarijaus ingsniai, kuriuos reikia toliau detalizuoti. Diagramoje jie traktuojami kaip uduotys ir parodomi j pltiniai (ryys extend) bei j pouduotys (ryys includes). Aikinamj tekst sudaro formalizuoti uduoi apraai (r. emiau pateiktus pavyzdius), sudaryti i i dali: uduoties numeris ir pavadinimas, siekiamas tikslas, uduoties vykdym inicijuojantis vykis (trigeris), uduoties prioritetas, "prie" slygos, skmingos baigties po slygos, neskmingos baigties slygos, uduoties vykdymo sritis, uduoties lygmuo, laiko snaudos uduoiai vykdyti, uduoties vykdymo danis, pirminis agentas ir sveikos su juo kanalas, antriniai agentai ir sveikos su jais kanalai, bendresnioji uduotis, pouduotys, pltiniai, variantai. Viena i rimiausi verslo scenarij modeliavimo problem yra vadinamasis scenarij "sprogimas". Dl pradini duomen vairovs, ypatingj situacij apdorojimo ir kit panaaus pobdio aplinkybi scenarijuje atsiranda labai daug ak, jis tampa labai sudtingu ir neapvelgiamu. "Sprogimui" kontroliuoti naudojami trys mechanizmai: variantai. pouduotys, pltiniai, UML kalba numato specialias konstrukcijas pouduotims ir pltiniams modeliuoti. Variantai modeliuojami panaudojant apibendrinim hierarchijas. Jie naudojami uduotis vykdani agent, pradini duomen ir rezultat vairovei aprayti. Pavyzdys Uduoi diagrama pavyzdyje nepateikta. Ji aprao ankstesniame pavyzdyje naudojam esmini uduoi (j yra penkios, nes tiek buvo scenarijaus ingsni) sryius. Pirmj scenarijaus ingsn atitinkanios uduoties aprae turi atsirasti itokia variant sekcija: Variantai: Pretendentu gali bti: a. fizinis asmuo, b. kita draudimo bendrov, c. biudetin organizacija. Penktj scenarijaus ingsn atitinkanios uduoties aprae turi atsirasti itokia variant sekcija: Variantai: Iekin imokti galima: a. ekiu, b. pavedimu, c. apmokant kit draudimo na, d. iduodant nauj draudimo sutart. Pltinys tai uduotis, ipleianti kit uduot. Kadangi visos uduotys apraomos j vykdymo scenarijais, tai galima sakyti, kad pltin realizuojant scenarij yra daroma nuoroda ipleiamj uduot apraaniame scenarijuje. Pltiniai atsiranda todl, kad agento siekiamas tikslas tam tikrais atvejais gali bti pasiektas tiktai i dalies arba apskritai nepasiektas. Ipleiamj uduot apraantis scenarijus yra skms scenarijus. Jis aprao kaip viskas vyksta skms atveju. Kiti atvejai apraomi pltiniais. Pltiniams aprayti uduoties aprae numatyta speciali sekcija. Pavyzdys Aukiau pateiktame pavyzdyje pirmj scenarijaus ingsn atitinkanti uduotis ipleiama itaip: Pltiniai: a. Pretendento pateikt duomen tikslinimas (jei ko nors trko ar kas nors buvo neaiku). Antrj scenarijaus ingsn atitinkanti uduotis ipleiama itaip: Pltiniai: a. Iekinio atmetimas dl negaliojanios sutarties Treij scenarijaus ingsn atitinkanti uduotis ipleiama itaip: Pltiniai: a. Iekinio tvarkymas, nesant pareigno, kuriam tai bt galima pavesti. Ketvirtj scenarijaus ingsn atitinkanti uduotis ipleiama itaip:: Pltiniai: a. Iekinio tvarkymas, kuomet autovykis netenkina esmini draudimo slyg b. Iekinio tvarkymas, kuomet autovykis neymiai paeidia draudimo slygas 15

Ipleiant uduotis, btina iplsti ir j vykdymo scenarijus. Pltini vykdymo scenarijai apraomi scenarijaus pltini sekcija. Taigi, papildius aukiau pateikt scenarijaus pavyzd pltini sekcija, jis atrodys itaip: Scenarijus: draudimo imokos Versija: 1.1 Verslo sistema: draudimo bendrov Tikslas: gauti draudim u autovykyje nukentjus automobil Pirminis agentas: pretendentas gauti draudim Antriniai agentai: policija "Prie" slyga: visi draudimui gauti reikalingi dokumentai yra sutvarkyti, iekinys nepatenkintas. Po slyga: iekinys patenkintas (t.y. pretendentas gavo pinigus, draudimo bendrov juos sumokjo). Scenarijus: 1. Pretendentas pateikia bendrovei iekin. 2. Draudimo bendrov tikrina pretendento draudimo sutarties galiojim (neskm iame ingsnyje reikia viso tikslo neskm). 3. Draudimo bendrov skiria pareign iekiniui analizuoti. 4. Pareignas analizuoja, ar visos iekinio detals tenkina nustatytus reikalavimus (vyksta pareigno ir antrini agent sveika). 5. Draudimo bendrov imoka iekin Scenarijaus pltiniai 1 ingsnis Pltinys: a Tikslas: patikslinti pretendento pateiktus duomenis Pirminis agentas: draudimo bendrov. Antriniai agentai: pretendentas gauti draudim "Prie" slyga: pretendento pateikti duomenys yra neisams Po slyga: pretendento pateikti duomenys yra isams Pltinio scenarijus: a1. Draudimo bendrov prao pateikti trkstamus duomenis. a2. Iekovas pateikia trkstamus duomenis. 2 ingsnis Pltinys: a Tikslas: atmesti pateikt iekin. Pirminis agentas: draudimo bendrov. Antriniai agentai: nra "Prie" slyga: pretendentas neturi galiojanios draudimo sutarties. Po slyga: pinigai neimokti, pretendentas informuotas apie iekinio atmetim. Pltinio scenarijus: a1.Draudimo bendrov atmeta iekin, informuoja iekov, dokumentuoja atvej ir baigia j nagrinti. 4 ingsnis Pltinys: a Tikslas: atmesti pateikt iekin Pirminis agentas: draudimo bendrov. Antriniai agentai: nra. "Prie" slyga: autovykis netenkina esmini draudimo slyg. Po slyga: pinigai neimokti, pretendentas informuotas apie iekinio atmetim. Pltinio scenarijus: a1.Draudimo bendrov atmeta iekin, informuoja iekov, dokumentuoja atvej ir baigia j nagrinti. Pltinys: b Tikslas: atmesti pateikt iekin. Pirminis agentas: draudimo bendrov. Antriniai agentai: nra. "Prie" slyga: autovykis neymiai paeidia draudimo slygas, imokos suma neaiki. Po slyga: suderinta imokos suma. Pltinio scenarijus: b1. Draudimo bendrov derasi su iekovu dl iekinio sumos. Neisprsti klausimai 3 ingsnis "Prie" slyga: bendrov neturi laisvo pareigno, kuris galt usiimti iekiniu. io atvejo verslo scenarijus nenumato. Kiekvienu konkreiu atveju elgiamasi kitaip (iekinio tvarkymas uvilkinamas, kam nors tenka dirbti virvalandius, bandoma atsirainti ir kt.). Pouduotys aprao tarpinius agent tikslus. Kitaip tariant, jos vedamos siekiant supaprastinti scenarijus. Scenarijai apraomi per pouduotis, po to pouduotys apraomos savais scenarijais ir t.t. Kitaip tariant, pouduotys yra abstrakcijos principo taikymas. Mes konstruojame uduoi hierarchij ir itaip supaprastiname scenarij apra: Kiekvienas scenarijaus ingsnis gali bti traktuojamas kaip pouduotis. Pouduotys uduoda rekursyvi uduoi ir scenarij struktr. 16

Su kiekvienu tikslu siejama pagrindin veiksm seka, alternatyvi veiksm seka ir atkrimo scenarijus. Jei ingsnis patiria neskm, nebtinai neskmingai baigiasi visa uduotis. To galima ivengti panaudojus atkrimo scenarij (pvz., neymiai paeidus draudimo slygas, dalis iekinio gali bti imokta, tarkime, klientui, kur kompanija nori isaugoti, todl pradeda su juo dertis). Su tikslu siejamas scenarij rinkinys. Kiekvienas i j turi savas "prie" slygas ir savus rezultatus. Kiekvienas scenarijaus ingsnis yra arba praneimas (reikalavimas atlikti primityv veiksm), arba pouduotis. Tas pats ingsnis (pouduotis) danai pasirodo dviejuose scenarijuose - skms ir neskms. Jei naudojami atkrimo scenarijai, jis gali pasirodyti ir daugiau scenarij. Taigi, auktesnio lygmens scenarij galima jungti uduot su visais jos vykdymo scenarijais kaip vien ingsn. Daniausiai tikslinga skirti pagrindin scenarij (main course), pagal kur viskas vyksta be komplikacij ir yra pasiekiamas tikslas bei alternatyvius scenarijus, kurie yra skirstomi neskmi (failure scenarios) ir atkrimo scenarijus (recovery scenarios). Pagrindinis scenarijus ir atkrimo scenarijai baigiasi visika arba daline skme. Naudojant pouduotis, uduoi "sprogimas" yra stabdomas, nes pouduotis grupuoja visas potencialiai galimas alternatyvas. itaip kiekviename scenarijaus take vietoje vis galim variant gauname tik du: skms ir neskms akas. Modeliuojant uduotis svarbiomis yra dar dvi jas apibdinanios svokos: uduoties vykdymo sritis ir uduoties lygmuo. Uduoties vykdymo sritis gali bti visa verslo sistema arba kuri nors jos dalis. Tam tikrais atvejais tai gali bti ir platesn sistema, apimanti verslo sistem ir, pavyzdiui, j aptarnaujanias sistemas. inoti kokia yra uduoties vykdymo sritis yra labai svarbu, nes i to galima sprsti, kiek svarbi i uduotis yra analizuojamai verslo sistemai ir kas yra suinteresuotas jos kompiuterizavimu. Pavyzdys Tarkime kokios nors bendrovs vykdomos uduotys siejasi su trim skirtingomis sritimis. Prekes perkanio klijento (pirmino agento) poiriu uduoi vykdymo sritis yra visa bendrov. Bendrovs marketingo skyriaus (pirminio agento) poiriu uduoi vykdymo sritis yra bendrovs informacin sistem proirintis skyrius ir jo tvarkoma programin iranga. Programins rangos apsauga usiimanio administratoriaus (pirminio agento) poiriu uduoi vykdymo sritis yra IS realizuojanti program sistema. Uduotis gali bti vartotojo, sumarinio arba subfunkcijos lygmens. Vartotojo lygmens uduotis vykdoma siekianio reikiam darb atlikti pirminio agento. Tokios uduotys dar yra vadinamos "vartotojo uduotimis" arba "elementariais verslo procesais". itokia uduotis visada siejama su klausimu "Ar js darbo naumas priklauso nuo js iandien atlikto darbo apimties?". Pavyzdiui, parengiamieji darbai paprastai nepriskiriami vartotojo uduotims, nes atsakymas pateikt klausim paprastai yra neigiamas. Transakcij sistemose vartotojo uduotys paprastai sutampa su transakcijomis. Sumarinio lygmens uduotys grupuoja vartotoj uduotis. Pavyzdiui, sumarinio lygmens uduotimi gali bti uduotis "propaguoti bendrovs gaminam produkcij rinkoje". Subfunkcijos lygmens uduotys - tai vartotojo uduoi pouduotys. Kitaip tariant, tai iorinio scenarijaus ingsniai, kuriais vartotojas daniausiai jau nebesidomi. Pavyzdiui, subfunkcijomis daniausiai esti parengiamieji darbai. Jas galima traktuoti ir kaip uduotims atlikti naudojamas pagalbines procedras. Uduoties aprao pavyzdys 5 uduotis: Nupirkti prekes Tikslas: Pirkjas siunia usakym bendrovei ir tikisi i jos gauti prekes bei sskait. Trigeris: Gautas pirkjo usakymas. Prioritetas: 1- as (aukiausias). "Prie" slygos: Yra inomi pirkjas, jo adresas ir kiti reikiami duomenys, bendrov turi prek; pirkjas turi prekei nusipirkti reikiam pinig sum. Skmingos baigties po slygos: Prek tapo pirkjo nuosavybe; bendrov nebeturi tos preks; pirkjo turim pinig kiekis sumajo tiek, kiek kainavo prek; bendrovs turim pinig kiekis padidjo tiek, kiek kainavo prek. Neskmingos baigties slygos: Bendrov neturi praom preki. Pirkjui nepakanka pinig apmokti sskait. Sritis: Bendrov. Lygmuo: Sumarinis tikslas. Laiko snaudos: 5 minuts usakymui priimti, 45 dienos jam vykdyti Danis: 200 usakym per dien Pirminis agentas: Pirkjas arba jo vardu veikiantis tarpininkas. Pirminio agento kanalas: telefonas, failas ,tiesiogin sveika Antriniai agentai: bankas, preki vejas Antrini agent kanalai: telefonas, tiesiogin sveika Bendresn uduotis: Usakov reikal tvarkymas (2 uduotis) Pouduotys: Usakymo vykdymas (15 uduotis) Mokjimo kreditine kortele primimas (44 uduotis) Grinam preki primimas (105 uduotis) Pltiniai a. Usakymo vykdymas, neturint vis usakyt preki (17 uduotis) 17

b. Mokjimo kreditine kortele primimas (13 uduotis) c. Pirkjo grint preki primimas (12 uduotis) Variantai: 1. Pirkjas gali pateikti usakym: telefonu, faksu, upildydamas internete paskelbt form, kompiuteriniu patu. 2. Pirkjas gali apmokti sskait: grynais pinigais, pavedimu, ekiu, kreditine kortele. Informacija apie laiko snaudas, dan ir sveikos kanalus naudojama analizuojant verslo problem priestis. Visos trys poskyryje pateiktos diagramos (veiklos, sek ir uduoi) privalo bti tarpusavyje suderintos, t.y. jose turi bti tos paios esmins uduotys ir tie patys agentai. 3.3.2. Poskyrio Uduoties .. modelis turinys ir struktra itoki poskiri turi bti tiek, kiek yra esmini uduoi. Poskyr sudaro du skyreliai: uduoties realizavimo scenarijus, pouduotys. Kiekviena esmin uduotis apraoma hierarchine pouduoi ir scenarij hierarchija. Taigi, skyreli turinys yra analogikas praeito poskyrio skyreli Verslo scenarijus ir Esmins uduotys turiniui. Skirtumas tiktai toks, kad dabar modeliuojame ne vis versl, o vien esmin uduot. Jei hierarchijos lygmen yra daugiau negu du, tai iame poskyryje atsiranda papildomi skyreliai vadinami Poduoties .. modelis. Kada baigti detalizuoti pouduotis, sprendiama vadovaujantis pouduoties elementarumo kriterijumi. Kitaip tariant, analitikas mano, kad pouduoties realizavimas yra akivaizdus, ji neturi nei pltini, nei variant, nei pouduoi ir gali bti traktuojama kaip reikalavimas atlikti kok nors elementar veiksm.

3.4. Skyriaus Struktrinis dalykins srities modelis paskirtis, struktra ir turinysio skyriaus paskirtis yra sudaryti model, modeliuojant dalykins srities esybes bei j apraomasias, organizacines ir operacines charakteristikas. Priminsime, kad Verslo proceso esybs modeliuojamos klasmis. J apraomosios charakteristikos modeliuojamos atributais J organizacins charakteristikos modeliuojamos arba ryiais, arba ryio atributais. J operacins charakteristikos modeliuojamos metodais (operacijomis). Verslo sistemos (t.y. verslo proces vykdanios sistemos) sudtins dalys modeliuojamos objektais. Skyriuje pateikiamos 2 UML diagramos: esybi, kuriomis manipuliuoja verslo procesas, tarpusavio ryius modeliuojanti koncepcinio lygmens statins struktros diagrama ((r. paskait skaidres, 7 tema. UML.) ir verslo sistemos komponent sryius modeliuojanti objekt diagrama. Prie vienos ir prie kitos yra pridedamas paaikinantis tekstas. Statins struktros diagramoje turi bti parodytos tos ir tik tos klass, atributai ir metodai, kurie ireiktiniu bdu buvo pavaizduoti sek arba uduoi diagramose (kaip agentai, kaip praneim parametrai arba kaip prie ar po slyg argumentai). Jos paaikinant tekst sudaro esybes, paslaugas ir esybi charakteristikas apraanios lentels (r. A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 281-283 p.p.). Be to, kadangi abstraktusis modelis yra teigini bei tvirtinim apie modeliuojam verslo proces (dalykin srit) rinkinys, tai paaikinamame tekste reikia ireiktiniu bdu irayti tuos teiginius. Objekt diagrama formuojama imant uduoi diagramose pavaizduotus agentus ir scenarij diagramose parodytus singuliarinius (vienetinius) objektus. Prie diagramos pridedama t diagram su uduoi ir scenarij diagramomis susiejanti lentel.

3.5. Skyriaus Dinaminis dalykins srities modelis paskirtis, struktra ir turinysio skyriaus paskirtis yra dvejopa: parodyti kaip dalykinje srityje veikiani agent vykdomos uduotys ir kiti ten vykstantys vykiai keiia dalykins srities struktr ir kaip kint pai verslo sistem sudarani objekt bsenos Siekiant pirmojo tikslo, kiekvienai struktriniame modelyje pavaizduotai klasei ir kiekvienam ten pavaizduotam ryiui pateikiama tos klass arba to ryio gyvavimo cikl apraant UML bsen diagrama ((r. paskait skaidres, 7 tema. UML.). Visos jos susiejamos vien diagram, sudarani dinamin verslo proceso (dalykins srities) model. Prie jo pridedamas paaikinantis tekstas. Gyvavimo ciklai formuojami nagrinjant scenarij prie ir po slygas. ios slygos isamiai aprao vis esybi ir ryi leistinas bsenas. Bsenas keiia patys scenarijai (tiksliau, atitinkami j ingsniai). taigi, bsen diagramos ir scenarij prie ir po slygos turi bti tarpusavyje grietai susieti. Ssajos apraomos paaikinamajame tekste pateiktose lentelse (r. A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 286-287 p.p.). Siekiant antrojo tikslo, analogiku bdu konstruojama bsen diagrama verslo sistem apraaniai objekt diagramai.

3.6. Skyriaus Ivados paskirtis, struktra ir turinysiame skyriuje pateikiama: ar pasitvirtino ir kodl pirmjame darbe ikeltos hipotezs apie verslo problem bei grsmi prieastis; kurias i dalykinje srityje vykdom uduoi ir kokiu mastu siloma kompiuterizuoti; 18

kuriuos i dalykinje srityje veikiani agent siloma paversti vidiniais kuriamos program sistemos agentais (programomis, renginiais, programikai realizuotais agentais ir kt.) ir kuriuos palikti jos ioriniais agentais; kurias statins struktros diagramoje parodytas esybes siloma realizuoti atitinkamomis program sistemos klasmis; kurie i dinaminio dalykins srities modelio numatyt vyki (praneim) turi bti pateikiami program sistemai per jos vartotojo ir kitus sveikos su ioriniais agentais interfeisus ir kurie i sistemos generuojam praneim turi bti per sistemos interfeisus pateikiami jos ioriniams agentams.

19

3.7. Antro darbo vertinimo metodika3.7.1. Vertinimas pagal skyrius Skyrius Titulinis Anotacija Turinys 1. vadas Poskyris Skyrelis vertis

2. Esmins uduotys ir j vykdymo scenarijai

PS pavadinimas DS PS Naudotojai Darbo pagrindas Naudoti dokumentai Koncepcinis verslo modelis Uduoties modelis ..

Bendroji verslo schema Verslo scenarijus Esmins uduotys Uduoties realizavimo scenarijus Pouduotys

3. Dalykins srities statin struktra 4. Dalykins srities dinamin struktra 5. Ivados Skyri numeracija Termin odynas 3.7.2. Darbo tiksl realizavimas analizuoti ir modeliuoti versl (vertis), UML kalbos pagrind (vertis), rengti technin dokumentacij (vertis), dirbti pagal formalius reikalavimus (vertis), dirbti grupse (vertis), planuoti grupin darb ir baigti j numatytais terminais (vertis), vieai pristatyti darb, argumentuoti priimtus sprendimus (vertis).

20

3.7.3. Darbo klaid vertinimas 2 darbas. Klaid suvestin

21

Klaidos Dokumentavimo klaidos titulinis anotacija turinys darbo struktra dokument sraas nuorodos j odynlis diagram kokyb trksta diagram apra puslapiavimas puslapi numeriai skyri numeracija kitos

1

2

3

4

5

6

7

bei

22

Klaidos Dalykines klaidos dalykin sritis problemin sritis vartotoj kvalifikaciniai reikalavimai verslo schema ar parodyti objektai ar diagrama esmini uduoi lygmens (ne per daug detali) ar ji prasminga ar diagrama paaikinta verslo scenarijus diagrama verslo sistema, uduotis (siekiamas tikslas), pirminis agentas, antriniai agentai, "prie" slyga, po slyga, scenarijaus ingsni seka, scenarijaus pltiniai, neisprsti klausimai. ar scenarijus realizuoja verslo schem ar jis prasmingas ar jis patvirtina 1 darbe nustatyt problem prieastis (vidin analiz) esmins uduotys diagrama siekiamas tikslas uduoties vykdym inicijuojantis vykis (trigeris) uduoties prioritetas "prie" slygos skmingos baigties po slygos neskmingos baigties slygos uduoties vykdymo sritis uduoties lygmuo laiko snaudos uduoiai vykdyti uduoties vykdymo danis pirminis agentas ir sveikos su juo kanalas antriniai agentai ir sveikos su jais kanalai bendresnioji uduotis pouduotys pltiniai variantai Uduoi modeliai realizavimo scenarijai diagramos verslo sistema, uduotis (siekiamas tikslas), pirminis agentas, antriniai agentai, "prie" slyga,

1

2

3

4

5

6

7

23

Klaidos po slyga, scenarijaus ingsni seka, scenarijaus pltiniai, neisprsti klausimai. ar scenarijus realizuoja uduot ar jis prasmingas pouduotys diagrama siekiamas tikslas uduoties vykdym inicijuojantis vykis (trigeris) uduoties prioritetas "prie" slygos skmingos baigties po slygos neskmingos baigties slygos uduoties vykdymo sritis uduoties lygmuo laiko snaudos uduoiai vykdyti uduoties vykdymo danis pirminis agentas ir sveikos su juo kanalas antriniai agentai ir sveikos su jais kanalai bendresnioji uduotis pouduotys pltiniai variantai statinis modelis ar pateikti ir verslo proceso ir verslo sistemos modeliai ar klass ir atributai gauti i scenarij ir tinkamai su jais susieti ar teisingai sudarytos diagramos ar jos prasmingos (dalykine ir objektins paradigmos prasme) ar ivardinti tvirtinimai ir teiginiai apie dalykin srit ar suprasta objektin paradigma dinaminis modelis ar pateikti ir problemos ir sistemos modeliai ar jie gauti i scenarij ar jie adekvats statiniams modeliams ar teisingai sudarytos diagramos Terminai Terminija termin odynas Lietuvi kalba Minusai u vlavim

1

2

3

4

5

6

7

24

4. Laboratorinis darbas Reikalavim specifikacija4.1. Darbo tikslai ir paskirtisiuo darbu siekiama mokyti studentus: specifikuoti program sistem reikalavimus, struktrizuoti reikalavimus pagal pasirinkt kokybs model, matuoti program sistem kokybs parametrus, UML kalbos pagrind, rengti technin dokumentacij, dirbti pagal formalius reikalavimus, dirbti grupse planuoti grupin darb ir baigti j numatytais terminais, vieai pristatyti darb, argumentuoti priimtus sprendimus. Reikalavim specifikacija yra dokumentas, kuris yra neatskiriama Vykdytojo ir Usakovo sutarties dalis. Joje suformuluoti reikalavimai yra privalomi vykdytojui. Todl dokumentas raomas liepiamja nuosaka. Kiekvienas reikalavimas turi turti unikal numer. Reikalavimai formuluojami ankstesni darb pagrindu, jie turi organikai iplaukti i poreiki specifikacijos ir dalykins srities koncepcinio modelio. Rengdami dokument Reikalavim specifikacija, studentai veikia kaip program sistem ininieriai. Literatra: 1) Paskait skaidrs, 9 tema. Reikalavim ininerija. 2) A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 3.2. poskyris (p.p. 112-136).

4.2. Darbo bendrosios dalies struktraDarbo bendrj dal sudaro ie skyriai: Vartotojo interfeiso reikalavimai funkciniai program sistemos reikalavimai, nefunkciniai program sistemos reikalavimai.

4.3. Skyriaus Vartotojo interfeiso reikalavimai paskirtis, struktra ir turinysSkyriaus paskirtis specifikuoti vartotojo interfeiso reikalavimus. Interfeisas specifikuojamas trim aspektais: prasminiu (kokios uduotys yra formuluojamos), struktriniu (kokia uduoi formulavimo kalba yra vartojama uduotims formuluoti) ir protokolo (kokiu bdu uduotys yra formuluojamos. Skyrelis yra skaidomas ias smulkesnes dalis: dalykins srities metaforos reikalavimai, formuluojamos uduotys, uduoi formulavimo kalbos reikalavimai, uduoi formulavimo bdo (protokolo) reikalavimai, interfeiso darnos ir standartizavimo reikalavimai, praneim formulavimo reikalavimai, interfeiso individualizavimo reikalavimai. 4.3.1. Poskyrio Dalykins srities metaforos reikalavimai paskirtis ir turinys iame poskyryje apraoma, kokia dalykins srities metafora turi bti naudojama uduotims formuluoti. Kitaip tariant, apraomas dalykins srities odynas, vartojamas uduotims formuluoti. Metafora privaloma ne tik projektuojant program sistemos interfeisus, bet ir projektuojant duomen bazes. Ji formuluojama dalykins srities koncepcinio modelio pagrindu. 4.3.2. Poskyrio Formuluojamos uduotys paskirtis ir turinys iame poskyryje, remiantis skyriuje Funkciniai program sistemos reikalavimai pateikta mediaga, apraoma kiek vartotojo interfeis turi bti numatyta program sistemoje ir kokios uduotys turi bti formuluojamos naudojantis kiekvienu i j. Kiekvienai uduoiai isamiai apraoma, kas (komandos, parametrai, duomenys ir kt.) sudaro tos uduoties apra. 4.3.3. Poskyrio Uduoi formulavimo kalbos reikalavimai paskirtis ir turinys iame poskyryje apraoma uduoi formulavimo kalba, t.y. langai, piktogramos, meniu, dialogo langai ir kitos priemons, naudojamos uduotims formuluoti. Kuriamos sistemos lang maketai turi bti pateikti darbo priede. 4.3.4. Poskyrio Uduoi formulavimo bdo (protokolo) reikalavimai paskirtis ir turinys iame poskyryje kiekvienam vartotojo interfeisui pateikiama atitinkama UML sek diagrama, vaizduojanti vartotojo ir sistemos sveik, ir t diagram paaikinantis tekstas. 4.3.5. Poskyrio Interfeiso darnos ir standartizavimo reikalavimai paskirtis ir turinys iame poskyryje apraoma, koki interfeiso standart (pvz., MS Windows) reikia laikytis, gyvendinant vartotojo interfeis, ir kokius papildomus susitarimus reikia priimti, interfeiso vidinei darnai utikrinti. 4.3.6. Poskyrio Praneim formulavimo reikalavimai paskirtis ir turinys iame poskyryje formuluojami reikalavimai, kuriuos turi tenkinti sistemos vartotojui pateikiami reikalavimai. 4.3.7. Poskyrio Interfeiso individualizavimo reikalavimai paskirtis ir turinys iame poskyryje nurodoma, koki parametr reikmes ir kaip turi bti numatyta galimyb keisti, siekiant pritaikyti interfeis individualaus vartotojo poreikiams. 25

4.4. Skyriaus Funkciniai program sistemos reikalavimai paskirtis, struktra ir turinysFunkciniais reikalavimais vadinami reikalavimai, nusakantys k program sistema turi daryti, kitaip tariant, kokias funkcijas ji turi vykdyti, kad galt realizuoti aukiau apraytas uduotis. Reikalavimai formuluojami remiantis UML diagramomis, pateiktomis darbe Koncepcinis verslo modelis. Taiau i diagram nepakanka, nes jose neparodytos sistemai administruoti reikalingos uduotys. Todl reikia vadovautis ir darbo Verslo tiksl ir poreiki specifikacija skyriuje Sistemos naudojimo scenarijus pateikta mediaga. Reikalavimai formuluojami, nurodant: pradinius duomenis ir rezultat bei galbt paaikinant, kokiais veiksmais rezultatas yra gaunamas. vesties ir ivesties duomenys specifikuojami taip, kad programuotojui pakakt informacijos programai rayti, t.y. nurodant konkreius j vaizdavimo formatus. Kit duomen format nurodyti nereikia, tai padarys projektuotojas, rengdamas eskizin program sistemos projekt. Skyri sudaro du poskyriai: dalykiniai reikalavimai, pagalbins sistemos funkcijos. Pirmasis poskyris rengiamas darbo Koncepcinis dalykins srities modelis, antrasis darbo Poreiki specifikacija pagrindu. 4.4.1. Poskyrio Dalykiniai reikalavimai paskirtis ir turinys iame poskyryje apraoma, kokias uduotis, tiesiogiai susijusias su kompiuterizuojama veikla, privalo vykdyti program sistema. ia apraomos tos darbe Koncepcinis dalykins srities modelis apraytos esmins uduotys, kurias numatoma visikai ar i dalies kompiuterizuoti. Uduoi visuma turi tenkinti darbe Verslo tiksl ir poreiki specifikacija suformuluotus poreikius ir utikrinti t naud, kuri buvo numatoma tame darbe. 4.4.2. Poskyrio Pagalbins sistemos funkcijos paskirtis ir turinys iame poskyryje apraoma, kokias uduotis (pagalba, sistemos galimybi demonstravimas, sistemos administravimo uduotys), palengvinanias program sistemos sisavinim, naudojim, aptarnavim bei prieir, privalo vykdyti program sistema. Uduotys turi bti formuluojamos, atsivelgiant program sistemos naudojimo scenarij, aprayt darbe Verslo tiksl ir poreiki specifikacija.

4.5. Skyriaus Nefunkciniai program sistemos reikalavimai paskirtis, struktra ir turinysio skyriaus paskirtis aprayti nefunkcinius program sistemos reikalavimus, t.y. reikalavimus, vienaip ar kitaip ribojanius funkcini sprendim gyvendinimo bdus. Skyri sudaro ie poskyriai: vidini interfeiso reikalavimai, veikimo reikalavimai, diegimo reikalavimai, aptarnavimo ir prieiros reikalavimai, tirauojamumo reikalavimai, apsaugos reikalavimai, juridiniai reikalavimai. 4.5.1. Poskyrio Vidini interfeiso reikalavimai paskirtis, struktra ir turinys io poskyrio paskirtis specifikuoti vidinius program sistemos interfeisus (operacins sistemos, kompiuteri tinklo, duomen bazi, programavimo aplinkos, dokument main). Specifikuojant interfeis, nurodoma kokia informacija per j yra perduodama, kaip ta informacija yra struktrizuota ir pagal kok protokol ji yra perduodama. Poskyr sudaro ie skyreliai: operacins sistemos naudojimo reikalavimai, sveikos su duomen bazmis reikalavimai, dokument main reikalavimai, darbo kompiuteri tinkluose reikalavimai, sveikos su kitomis programomis reikalavimai, programavimo aplinkos reikalavimai. 4.5.1.1. Skyrelio Operacins sistemos naudojimo reikalavimai paskirtis ir turinys iame skyrelyje nurodoma, kokia operacin sistema turi bti panaudota program sistemai realizuoti ir kaip yra ribojama programuotojo laisv naudotis tos operacins sistemos interfeisais (vadinamaisiais API), siekiant utikrinti sistemos perkeliamum kitas platformas ar kitas pageidautinas jos savybes. 4.5.1.2. Skyrelio Sveikos su duomen bazmis reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kokios duomen bazs turi bti sukurtos program sistemoje, kokie duomenys turi bti jose saugomi, kokie turi bti gyvendinti duomen main interfeisai (pvz., SQL, PLSQL, formos ir t.p.), kaip tie mainai turi vykti (pvz., per ODBC). 4.5.1.3. Skyrelio Dokument main reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kokiais dokumentais turi keistis sistema su kitomis program sistemomis, dokument bazmis ar vartotojais ir kokie formatai (rtf, pdf, ps, LATEX ir pan.) ar standartai turi bti nauidojami atliekant tuos mainus. 4.5.1.4. Skyrelio Darbo kompiuteri tinkluose reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kokiuose kompiuteri tinkluose turi veikti program sistema, pagal kokius protokolus ji turi dirbti ir koki kit susitarim reikia laikytis, dirbant tinkle. 26

4.5.1.5. Skyrelio Programavimo aplinkos reikalavimai paskirtis ir turinys iame skyrelyje pateikiami reikalavimai, kokiomis programavimo kalbomis reikia programuoti program sistem, koki standart ar kit susitarim privalu laikytis, kokias programavimo aplinkas leidiama naudoti. 4.5.2. Poskyrio Veikimo reikalavimai paskirtis, struktra ir turinys iame poskyryje apraomi reikalavimai, paeidus kuriuos program sistema praranda pageidaujamas eksploatacines savybes. Poskyr sudaro ie skyreliai: tikslumo reikalavimai, patikimumo reikalavimai, robastikumo reikalavimai, naumo reikalavimai. 4.5.2.1. Skyrelio Tikslumo reikalavimai paskirtis, struktra ir turinys iame skyrelyje pateikiami reikalavimai, nusakantys kuriamos program sistemos skiriamj geb ir leistinus jos darom paklaid dydius. Skyrelis yra skaidomas dvi smulkesnes dalis: vaizdavimo tikslumo reikalavimai, skaiiavim tikslumo reikalavimai. 4.5.2.1.1. Paragrafo Vaizdavimo tikslumo reikalavimai paskirtis ir turinys iame paragrafe nurodoma, kokiu tikslumu turi bti galima vaizduoti program sistemoje jos apdorojamus objektus (skaiius, spalvas, vaizdus, verslo objektus ir kt.). ia pateikiami taip pat duomen klasifikavimo, identifikavimo ir kodavimo reikalavimai. 4.5.2.1.2. Paragrafo Skaiiavim tikslumo reikalavimai paskirtis ir turinys iame paragrafe nurodoma, kokios paklaidos yra leistinos apdorojant program sistemoje joje pavaizduotus objektus. 4.5.2.2. Skyrelio Patikimumo reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kaip turi bti suprantamas kuriamos program sistemos patikimumas, kaip jis turi bti matuojamas ir kokie patikimumo reikalavimai turi bti tenkinami. Formuluojant patikimumo reikalavimus reikia galvoti, ar jie yra suformuluoti taip, kad juos bus galima patikrinti. 4.5.2.3. Skyrelio Robastikumo reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kaip program sistema turi bti apsaugota nuo galimo neigiamo tryki poveikio ir kas turi bti gyvendinta sistemoje dl tryki prarastam funkcionalumui atkurti. 4.5.2.4. Skyrelio Naumo reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kokiais resursais (atmintis, procesoriaus laikas ir t.t.) turi teis naudotis program sistema ir kokie yra jos reaktyvumo reikalavimai. 4.5.3. Poskyrio Diegimo reikalavimai paskirtis, struktra ir turinys io poskyrio paskirtis, aprayti reikalavimus, kurie turi bti gyvendinti program sistemoje, siekiant supaprastinti ir atpiginti jos diegim. Poskyr sudaro ie skyreliai: ruoinio reikalavimai, instaliavimo reikalavimai, pradinio duomen bazi kaupimo reikalavimai, sistemos sisavinamumo reikalavimai. 4.5.3.1. Skyrelio Ruoinio reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kokius reikalavimus privalo tenkinti kuriamosios program sistemos ruoinys (kaip jis turi bti pateiktas, kas jame turi bti rayta ir kt.). 4.5.3.2. Skyrelio Instaliavimo reikalavimai paskirtis ir turinys iame skyrelyje formuluojami interfeiso ir veikimo reikalavimai program sistemos instaliavimo programai. 4.5.3.3. Skyrelio Pradinio duomen bazi kaupimo reikalavimai paskirtis ir turinys iame skyrelyje apraoma, kokios priemons turi bti numatytos program sistemoje pradiniams duomenims jos duomen bazse sukaupti arba perkelti jas i jau esam duomen bazi. 4.5.3.4. Skyrelio Sistemos sisavinamumo reikalavimai paskirtis ir turinys iame skyrelyje pateikiami reikalavimai (papildomai prie reikalavim aprayt poskyriuose Pagalbins sistemos funkcijos ir Interfeiso reikalavimai), kuriuos turi tenkinti program sistema, kad bt galima greiiau imokti ja naudotis. 4.5.4. Poskyrio Aptarnavimo ir prieiros reikalavimai paskirtis, struktra ir turinys iame poskyryje apraomi reikalavimai, kuriuos turi tenkinti program sistema jos aptarnavimui ir prieirai (modernizavimui) palengvinti. 4.5.5. Poskyrio Tirauojamumo reikalavimai paskirtis, struktra ir turinys iame poskyryje apraoma, kokie kuriamosios program sistemos komponentai turi bti sukurti kaip pakartotinai (kitose sistemose) panaudojami komponentai ir kokius standartus ar kitus susitarimus jie turi tenkinti. 4.5.6. Poskyrio Apsaugos reikalavimai paskirtis, struktra ir turinys iame poskyryje apraoma, koks apsaugos modelis turi bti gyvendintas kuriamojoje program sistemoje. 27

4.5.7. Poskyrio Juridiniai reikalavimai paskirtis, struktra ir turinys iame poskyryje apraoma, k reikia gyvendinti program sistemoje, kad bt tenkinami dalykin srit reglamentuojantys teiss aktai (jie turjo bti aprayty Poreiki specifikacijoje), ir k programuotojui draudiama daryti, kad nebt paeisti tais aktais nustatyti reikalavimai.

4.6. Treio darbo vertinimo metodika4.6.1. Vertinimas pagal skyrius Skyrius Titulinis Anotacija Turinys 1. vadas Poskyris Skyrelis vertis

PS pavadinimas DS PS Naudotojai Darbo pagrindas Naudoti dokumentai

2. Vartotojo reikalavimai

interfeiso

3. Funkciniai program sistemos reikalavimai 4. Nefunkciniai program sistemos reikalavimai

Dalykins srities metaforos reikalavimai Formuluojamos uduotys Uduoi formulavimo kalbos reikalavimai Uduoi formulavimo bdo (protokolo) reikalavimai Interfeiso darnos ir standartizavimo reikalavimai Praneim formulavimo reikalavimai Interfeiso individualizavimo reikalavimai Dalykiniai reikalavimai Pagalbins sistemos funkcijos Vidini interfeis reikalavimai,

Veikimo reikalavimai

Diegimo reikalavimai

Operacins sistemos naudojimo reikalavimai Sveikos su duomen bazmis reikalavimai Dokument main reikalavimai Darbo kompiuteri tinkluose reikalavimai Sveikos su kitomis programomis reikalavimai Programavimo aplinkos reikalavimai Operacins sistemos naudojimo reikalavimai Tikslumo reikalavimai Patikimumo reikalavimai Robastikumo reikalavimai Naumo reikalavimai Ruoinio reikalavimai Instaliavimo reikalavimai 28

Skyrius

Poskyris

Skyrelis Pradinio duomen bazi kaupimo reikalavimai Sistemos sisavinamumo reikalavimai

vertis

Aptarnavimo ir prieiros reikalavimai Tirauojamumo reikalavimai Apsaugos reikalavimai Juridiniai reikalavimai 5. Ivados Skyri numeracija Termin odynas 4.6.2. Darbo tiksl realizavimas specifikuoti program sistem reikalavimus (vertis) struktrizuoti reikalavimus pagal pasirinkt kokybs model (vertis) matuoti program sistem kokybs parametrus (vertis) UML kalbos pagrind (vertis) rengti technin dokumentacij (vertis) dirbti pagal formalius reikalavimus (vertis) dirbti grupse (vertis) planuoti grupin darb ir baigti j numatytais terminais (vertis) vieai pristatyti darb, argumentuoti priimtus sprendimus (vertis)10 10 0

29

4.6.3. Darbo klaid vertinimas 3 darbas. Klaid suvestin Klaidos Dokumentavimo klaidos titulinis anotacija turinys darbo struktra dokument sraas bei nuorodos j odynlis diagram kokyb trksta diagram apra puslapiavimas puslapi numeriai skyri numeracija kitos Dalykines klaidos dalykin sritis problemin sritis vartotoj kvalifikaciniai reikalavimai dalykinai reikalavimai pagalbins funkcijos formuluojamos uduotys metafora uduoi formulavimo kalba lang maketai protokolas interfeiso darna ir individualizavimas praneimai OS DB dokument mainai tinklai programavimo aplinka veikimo reikalavimai diegimo reikalavimai aptarnavimo reikalavimai apsaugos reikalavimai juridiniai reikalavimai darbas nesusietas su ankstesniais darbais Nekonkrets reikalavimai Terminija terminija termin odynas Lietuvi kalba Minusai u vlavim

1

2

3

4

5

6

7

0

0

0

0

0

5. Laboratorinis darbas Program sistemos eskizinis projektas5.1. Darbo tikslai ir paskirtisiuo darbu siekiama mokyti studentus: projektuoti program sistemas, UML kalbos pagrind, rengti technin dokumentacij, dirbti pagal formalius reikalavimus, dirbti grupse planuoti grupin darb ir baigti j numatytais terminais, vieai pristatyti darb, argumentuoti priimtus sprendimus. Program sistemos eskizinis projektas yra dokumentas, rengiamas atlikus dalykins srities analiz ir suformulavus program sistemos reikalavimus. Dokumento paskirtis yra stambiu planu (eskizo lygmeniu) aprayti 30

kuriamos program sistemos reikalavim gyvendinimo bd arba, kitaip tariant, aprayti kuriamos program sistemos architektr ir veikim. Toks apraas dar yra vadinamas nuo konkreios kompiuterins platformos nepriklausaniu sistemos aprau. Tai reikia, kad kol kas projektuojama, negalvojant apie tai, kokioje konkreioje kompiuterinje platformoje bus gyvendinta pasirinktoji programos architektra ir jokie kurie nors konkreios platformos ypatumai neturi bti niekaip atspindimi. Yra isamiai ir pakankamai grietai apraoma, kokias uduotis vykdo program sistema, kokius scenarijus ji naudoja toms uduotims vykdyti, kokie resursai ir kaip yra panaudojami realizuojant scenarijus, ir kokie rezultatai yra gaunami vykdius uduotis. Taip pat yra apraoma i koki tip komponent turi bti sudarytakuriamoji program sistema, kaip tie komponentai turi bti jungiami tarpusavyje ir kaip j egzemplioriai turi bti idstyti kompiuteri tinklo mazguose. Kitaip tariant, dokumento paskirtis yra pateikti nuosekl ir isam program sistemos architektrin model, detalizavus kur konkreiai kompiuterinei platformai, jau bt galima rengti konkreias uduotis programuotojams. Nuo platformos nepriklausantis architektrinis modelis yra naudingas dar ir tada,Rengdami dokument Program sistemos eskizinis projektas , studentai veikia kaip program sistem architektai. Jei dokumento Program sistemos eskizinis projektas apimtis gaunasi per didel, studentams leidiama projektuoti sistem atmetant kai kurias dokumente Reikalavim specifikacija apraytas uduotis.

5.2. Darbo bendrosios dalies struktraProgram sistemos eskizin projekt sudaro ie skyriai: program sistemos projektiniai reikalavimai program sistemos koncepcinis modelis, ivados. Pirmieji du skyriai papildo vienas kit ir turi bti rengiami kartu. Kitaip tariant, pokyiai viename i skyri iauklia esminius pokyius kitame skyriuje.

5.3. Skyriaus Program sistemos projektiniai reikalavimai paskirtis, struktra ir turinysDokumente Reikalavim specifikacija suformuluoti reikalavimai yra operacinio pobdio. Kitaip tariant, ji aprao sistem kaip juodj d, taip, kaip j mato ioriniai agentai (usakovai, operatoriai, informacijos vartotojai ir kt.). iame skyriuje operaciniai reikalavimai yra transformuojami projektinius, arba, kitaip tariant, sistema yra apraoma kaip perregimoji d, taip, kaip j regi projektuotojai ir programuotojai, irintys j i vidaus. Tam naudojami reikalavim lokalizavimo ir nuleidimo emyn metodai (r. paskait skaidres, 11 tema. Projektavimas ir testavimas, taip pat A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 3.1 poskyris, p.p. 101-104). Skyri sudaro ie poskyriai: program sistemos dekompozicija, reikalavim lokalizavimo matrica, reikalavim ryio matrica.validation subsystem Customer info subsystem Billing transaction subsystem Accounts

subsystem Date -Time

subsystem C++ Std Library

subsystem Currency

subsystem XML Parser

subsystem Database

Pavyzdys. Sistemos architektros modeliavimas paket diagrama (i diagrama turi bti patalpinta pakete ) Poskyryje Program sistemos dekompozicija pateikiama projektuojamus sistemos komponentus vaizduojanti UML paket diagrama (daroma prielaida, kad kiekvieno sistemos komponento dokumentacija saugoma savarankikame pakete: visos sistemos - ries pakete, posistemi ries paketuose ir t.t.). Pasirinktoji programos architektra nusako i koki aukiausio lygmens komponent turi bti sudaryta sistema. Toliau, pavyzdiui, Kodo-Jodano architektros atveju, dalykinis posistemis yra dekomponuojamas emesnio lygmens komponentus, kiekvienas i kuri realizuoja vien ar kelias uduotis, nors gali atsitikti ir taip, kad vienai uduoiai realizuoti gali prireikti keli komponent. Toliau kiekvienas i t komponent gali bti dekomponuotas emesnio lygio komponentus ir t.t. Hierarchijos gylis yra toks, kokio prireikia, nors daniausiai utenka 2-3 lygmen. Su kiekvienu komponentu susiejami jo funkciniai ir nefunkciniai reikalavimai. Prisiminkite, kad formaliai kol kas yra operuojama UML paketais ir tiktai turime omenyje, jog jie bus realizuojami paketais. Be to, komponentus atitinkani paket viduje dar atsiranda ries paketai, kuriuose talpinamos uduoi, sek, klasi, bsen ir, jei to prireikia, kitos modelio diagramos. 31

Komponent reikalavimai aukiausio lygmens komponentams gaunami, lokalizuojant reikalavim specifikacijoje pateiktus reikalavimus ir juos nuleidus emyn posistemi lygmen. Toliau ie reikalavimai yra lokalizuojami emesnio lygmens komponentuose, nuleidiami j lygmen ir t.t. Atkreipkite dmes tai, kad kiekvienas komponentas vykdo tam tikras uduotis (pouduotis), todl sistemos dekompozicija turi atitikti skyriuje Program sistemos koncepcinis modelis atliekamai uduoi dekompozicijai. Formuluojant reikalavimus, kiekvienas komponentas traktuojamas kaip juodoji d, kurios struktra atskleidiama dekomponuojant j emesnio lygmens komponentus. Dekompozicija atliekama vadovaujantis pasirinktja program sistemos architektra. Rekomenduojama rinktis paskait skaidri 11 temoje (taip pat ir knygoje A. aplinskas. Program sistem ininerijos pagrindai, II dalis, 4.4.3.2.5. poskyryje, p.p. 187-190) aptart Koudo-Jodano architektr, bet galima rinktis ir bet kuri kit architektr. Priklausomai nuo pasirinktos architektros, komponentams yra formuluojami vadinamieji papildomi reikalavimai (r. A. aplinskas. Program sistem ininerijos pagrindai, I dalis, 3.1 poskyris, 101 p.). Be to, kiekvienas komponentas turi savo interfeis (nepainioti jo su vartotojo interfeisu), kurio reikalavimus taip pat reikia specifikuoti.

Kodo-Jodano architektros modeliavimo paket diagrama pavyzdys (interfeisai neparodyti, taiau dalykiniame posistemyje parodyti komponentai, sveikai su vartotojo interfeiso posistemiu organizuoti) Poskyryje Reikalavim lokalizavimo matrica pateikiama skaidrse (11 tema) pateikta reikalavim lokalizavimo matrica. Poskyryje Reikalavim ryio matrica pateikiama skaidrse (11 tema) aptartata reikalavim ryio matrica. Stulpelis Reikalavimo aprobavimo bdas yra neprivalomas. Jei jis pildomas, tai nurodoma kaip numatoma patikrinti reikalavim program sistemos baigiamj bandym metu. Stulpelis Aprobavimo rezultatai nepildomas. Pastaba. Atliekant reikalavim lokalizavim, j nuleidim emyn ir apraant reikalavim aprobavimo bdus, gali paaikti, kad dokumente Reikalavim specifikacija pateikti reikalavimai buvo suformuluoti netinkamai ir juos reikia taisyti. Projektuoti reikia tik dalykin program sistemos dal ir jos duomen baz. Vartotojo interfeiso posistemio (jeigu pasirinktoji program sistemos archotektra j numato) projektuoti nereikia. Juo operuojama kaip juodja d, jo vidin struktra (j sudarantys komponentai) neparodomi, nereikia pateikti ir jo modelio (klasi, sek ir kit diagram).

5.4. Skyriaus Program sistemos koncepcinis modelis paskirtis, struktra ir turinysProgram sistemos sistemos koncepcinis modelis yra gaunamas i dalykins srities koncepcinio modelio, ireikiant j kuriamosios program sistemos terminais ir svokomis. Projektuojant program sistemos koncepcin model yra nusprendiama, kurie dalykins srities koncepcinio modelio elementai turs savo atitikmenis program sistemoje ir kokie tie atitikmenys bus. Priimant sprendimus, btina atsivelgti tai, kad dalykins srities koncepcinis modelis aprao kaip dalykinje srityje yra dirbama, kol nra sukurta program sistema. J sukrus, bus pradta dirbti taip, kaip numato Poreiki specifikacijoje apraytas darbo su sistema scenarijus. Todl, dalykins srities koncepcin model tiesiogiai atvaizduoti program sistemos koncepcin model pavyksta labai retai. Be to, program sistemoje atsiranda objekt, susijusi su nefunkcini program sistemos reikalavim gyvendinimu. Skyri sudaro ie poskyriai: uduotys ir j vykdymo scenarijai, struktrinis program sistemos modelis, dinaminis program sistemos modelis, program sistemos iskirstymas kompiuteri tinkle. io skyriaus paskirtis suprojektuoti program sistem, t.y. kiekvieno komponento vidin struktr ir t komponent tarpusavio ryius. Atkreipkite dmes tai, kad verslo sistemos uduotys ir program sistemos uduotys yra skirtingi dalykai ir kad program sistemos uduotys modeliuojamos taip, kaip jos turi bti vykdomos sutinkamai su Poreiki specifikacijoje patektu scenarijumi. Be to, nepamirkite, kad projektuodami koncepcin program sistemos model, pradedami atidarinti paket diagramoje parodyti paketai arba, kitaip tariant, mes pradedame 32

rodyti kas yra program sistemos viduje. Tai reikia, jog bet kuri koncepcinio sistemos modelio diagrama turi patalpinta kokiame nors ries pakete, kuris yra atitinkamo komponento paketo viduje. 5.4.1. Poskyrio Uduotys ir j vykdymo scenarijai turinys ir struktra iame poskyryje detalizuojama Poreiki specifikacijoje pateikta uduoi diagrama ir apraomas jos realizavimo bdas. Poskyr sudaro ie skyreliai: sistemos vykdomos uduotys, uduoties .. gyvendinimas. Antrasis skyrelis kartojamas tiek kart, kiek yra sistemos vykdom uduoi. Skyrelyje Sistemos vykdomos uduotyspatekiama dokumente Poreiki specifikacija aprayta uduoi diagrama (ji talpinama pakete ), pakoreguota, atsivelgiant uduoi apraus, pateiktus dokumente Dalykins srities koncepcinis modelis. Skyrelyje Uduoties .. gyvendinimas pateikiamos atitinkamos uduoties vykdymo sek ir, galbt, komunikavimo diagramos (UML kalba) ir jas paaikinantis tekstas. Jos parodo, kaip, vykdydami i uduot, komunikuoja program sistemos objektai. Sek diagram aikinantis tekstas rengiamas pagal tas paias taisykles, kaip ir dalykins srities koncepcinio modelio atveju. Kai kurie sek diagramoje parodyti praneimai gali bti traktuojami kaip sveikos (t.y. emesnio lygmens uduotys). Jeig sek diagramoje yra sveik, tai jai rengiama atitinkama emesnio lygmens uduoi diagrama, tai diagramai - atitinkamos emesnio lygmens sek ir, galbt, komunikavimo diagramos ir t.t. Dekompozicija tsiama tol, kol sek (ir komunikavimo) diagramomis lieka tik praneimai, kvieiantys atitinkam objekt operacijas (metodus). Dekompozicija turi bti suderinta su skyriuje Program sistemos projektiniai reikalavimai aprayta dekompozicija. PIM

PIM

U1,1 U1,1 U1,m U1,1arba

1 lygmuo

U1,m+1 U1,n U1,n

U1,n

n? 72

n?72

U1,n

U1,1

2 lygmuoSek diagrama Uduoi diagrama Klasi diagrama

...

...

Sek diagrama

Uduoi diagrama

Klasi diagrama

...

...Un-1,1

Un-1,k

n-asis lygmuoSek diagrama Uduoi diagrama Klasi diagrama

...

...

Sek diagrama

Uduoi diagrama

Klasi diagrama

Program sistemos koncepcinio modelio projektavimas

33

5.4.2. Poskyrio Struktrinis program sistemos modelis turinys ir struktra io skyriaus paskirtis aprayti program sistemos duomen architektr. Skyriuje pateikiamos klasi diagramos. Kiekvienas program sistemos uduot atitinkantis posistemis turi sav klasi diagram, kuri yra gaunama i atitinkam sek diagram. Papildomai reikia padaryti dar vien klasi diagram, apraani sistemos duomen bazs struktr. i diagrama sudaroma analizuojant posistemi klasi diagramas, nes duomen baz turi utikrinti duomen mainus tarp posistemi. Klasi diagramos turi bti sudtos atitinkam posistemi (arba emesnio lygmens komponent paketus). Prie klasi diagram pridedamas jas paaikinantis tekstas, kuriame trumpai apraoma klasi paskirtis.

Klasi nustatymo pagal sek diagram pavyzdys

Klasi operacij nustatymo pagal sek diagram pavyzdysregistration form registration manager

3: add course(Joe, math 01)

Kursas kursoKodas auditorija laikas

Klasi atribut nustatymo pagal sek diagram pavyzdys 5.4.3. Poskyrio Dinaminis program sistemos modelis turinys ir struktra io poskyrio paskirtis koncepciniu lygmeniu aprayti program sistemos vartotojo interfeis architektr ir tos sistemos funkcionavim. Joje parodoma, kokie praneimai (uduotys) ateina per vartotojo interfeis bei kaip ir kokiu bdu jie keia program sistemos posistemi ir duomen bazs klasi objekt bsenas. Kiekvienai klasei pateikiama UML kalbos bsen diagrama, modeliuojanti tai klasei priklausani objekt gyvavimo ciklus. itaip modeliuojama, kaip keiiasi program sistemos duomenys. Kadangi objekt bsenas gali keisti tik klass, kuriai jie priklauso, operacijos (metodai), tai veiksmai, kuriais yra ymimi bsen diagram lankai turi sutapti su atitinkamos klass operacijomis (metodais). Prie diagram pridedami jas paaikinantys tekstai. Duomen bazs bsen diagramos talpinamos duomen bazs pakete, kitos atitinkam posistemi paketuose. 5.4.4. Poskyrio Program sistemos iskirstymas kompiuteri tinkle turinys ir struktra io poskyrio paskirtis parodyti kaip komponentai iskirstomi kompiuteri tinkle ir kokio tipo mazguose (kompiuteri tinklo mazguose) jie yra talpinami. Tai padaroma, pateikiant tip lygmens sistemos idstymo diagrama (r. skaidres, 7 tema. UML) ir j paaikinant tekst.Parodomi tik vykdymo meto komponentai, artifakt vaizduoti nereikia. Tekste apraomos kiekvieno kompiuteri tinklo mazgo charakteristikos (sutinkamai su Poreiki specifikacija). Idstymo diagrama talpinama pakete. 34

5.5. Ketvirto darbo vertinimo metodika5.5.1. Vertinimas pagal skyrius Skyrius Titulinis Anotacija Turinys 1. vadas Poskyris Skyrelis vertis

PS pavadinimas DS PS Naudotojai Darbo pagrindas Naudoti dokumentai

2. Program sistemos projektiniai reikalavimai

Program sistemos dekompozicija Reikalavim lokalizavimo matrica Reikalavim matrica ryio j Sistemos vykdomos uduotys Uduoties .. gyvendinimas

3.Program sistemos koncepcinis modelis

Uduotys ir vykdymo scenarijai

Struktrinis program sistemos modelis Dinaminis program sistemosmodelis Program sistemos iskirstymas kompiuteri tinkle 5. Ivados Skyri numeracija Termin odynas 5.5.2. Darbo tiksl realizavimas projektuoti program sistemas (vertis) UML kalbos pagrind (vertis) rengti technin dokumentacij (vertis) dirbti pagal formalius reikalavimus (vertis) dirbti grupse (vertis) planuoti grupin darb ir baigti j numatytais terminais (vertis) vieai pristatyti darb, argumentuoti priimtus sprendimus (vertis) 5.5.3. Darbo klaid vertinimas 4 darbas. Klaid suvestin (+ paymtos klaidos, ? vertinimui nepakanka informacijos) Klaidos 1 2 3 4 5 6 7 Dokumentavimo klaidos titulinis anotacija turinys darbo struktra dokument sraas bei nuorodos j odynlis diagram kokyb trksta diagram apra puslapiavimas puslapi numeriai skyri numeracija kitos Dalykines klaidos dalykin sritis 35

0

Klaidos problemin sritis vartotoj kvalifikaciniai reikalavimai Reikalavim nuleidimas ir lokalizavimas komponent diagrama reikalavim lokalizavimo matrica reikalavim nuleidimas emyn ryio matrica Uduotys sistemos vykdomos uduotys (diagramos) Uduotys neatitinka reikalavim specifikacijos Uduoi gyvendi