Įvadas

Nagrinėjama disertacija buvo parašyta remiantis Donecko OJSC Donecko manufaktūra Cleonelly parduotuvei.

Viena iš pagrindinių OJSC Donecko manufaktūrų veiklų gamina platų drabužių asortimentą, daugiausia chalatus, paklodes ir rankšluosčius. Be to, įmonė gamina dažytus medvilninius verpalus, skirtus audimo ir mezgimo gamybai.

Automatizuotų informacinių technologijų plėtra vyksta lygiagrečiai su naujų tipų techninių priemonių atsiradimu informacijai apdoroti ir perduoti, tobulinti organizacines kompiuterių naudojimo formas, prisotinti infrastruktūrą naujomis ryšio priemonėmis. Rinkos santykių plėtra lėmė naujų verslo veiklos rūšių atsiradimą ir, svarbiausia, informacinį verslą užsiimančių įmonių kūrimąsi, informacinių technologijų plėtrą, jų tobulinimą, automatizuotų informacinių technologijų komponentų platinimą. , ypač programinės įrangos produktai, automatizuojantys informaciją ir skaičiavimo procesus. Tai taip pat apima Kompiuterinė technologija, ryšių, biuro įrangos ir specifinių paslaugų rūšių – informacijos, techninių ir konsultacinių paslaugų, mokymų ir kt. Tai prisidėjo prie greito plitimo ir efektyvus naudojimas informacines technologijas valdymo ir gamybos procesuose, jų beveik visuotinį taikymą ir didelę įvairovę.

Įmonės, užsiimančios įvairių paskirčių prietaisų projektavimu ir kūrimu, šiuo metu plačiai naudojasi įvairiomis priemonėmis tiek kompiuterinis projektavimas – CAD (CAD), tiek gamybos procesų stebėjimas – automatizuotos procesų valdymo sistemos (SCADA/DCS). Tačiau savo dizaino įrenginiams būtina sukurti savo priemones, skirtas stebėti jų veikimą ir analizuoti gaminio kokybę.

„Cleanelly“ parduotuvės sandėlyje esančių produktų apskaitos technologinis procesas apima parduotų gaminių apskaitos vedimo etapą.

Šio diplominio projekto tikslas – automatizuotos darbo vietos (AWS) įdiegimas, leidžiantis vykdyti prekių apskaitą parduotuvės sandėlyje.

Norint pasiekti aukščiau nurodytą tikslą, būtina išspręsti šias užduotis:

¾ atlikti parduotuvės verslo procesų analizę;

¾ ištirti informacijos srautus, kurie atsiranda kuriamo produkto pristatymo etape;

¾ kurti konceptualius ir loginius duomenų modelius;

¾ sukurti programinę įrangą produktų apskaitos darbo vietoms

¾ atlikti ekonominio efektyvumo vertinimą informacinė sistema.

1 Programinės įrangos reikalavimų kūrimas

1.1 Esamų sprendimų analizė

Šiuo metu yra daugybė įmonių, kurios derina tiek tiesioginį produktų kūrimą, tiek šių produktų valdymo sistemų kūrimą. Panašias sistemas kuria tokios žinomos kompanijos kaip 1:C Enterprise ir Zvezda. Tokiose sistemose kontroliuojamos ir apskaitomos medžiagos, apdorojama gauta informacija.

„1C:Enterprise“ yra taikomųjų sprendimų sistema, sukurta pagal vienodus principus ir vienoje technologinėje platformoje. Vadovas gali pasirinkti sprendimą, atitinkantį dabartinius įmonės poreikius ir toliau tobulėjantis įmonei augant ar plečiantis automatizavimo užduotims.

1C:Enterprise programinės įrangos sistema skirta spręsti įvairias apskaitos ir valdymo automatizavimo problemas, su kuriomis susiduria dinamiškai besivystančios šiuolaikinės įmonės. Dabartinių apskaitos ir valdymo problemų sprendimas 1C:Enterprise sistemos programų sudėtis orientuota į esamus įmonių poreikius. 1C įmonė gamina masinės gamybos programinės įrangos sprendimus, skirtus automatizuoti tipines apskaitos ir valdymo užduotis įmonėse. Išskirtinis bruožas tiražiniai bendrovės „1C“ sprendimai – tai nuodugnus į standartinius sprendimus įtraukto funkcionalumo sudėties tyrimas. 1C įmonė analizuoja vartotojų patirtį naudojant 1C:Enterprise sistemos programas ir stebi jų poreikių pokyčius.

Pagrindiniai mano Didmeninės prekybos bazės sistemos pranašumai yra santykinai mažos diegimo išlaidos šios sistemos ir Taip pat yra keletas kitų privalumų:

¾ Patikimumas sukurtų programų. Programinės įrangos paketas (PC) turi būti atsparus ne tik vartotojo klaidoms, bet ir ryšio sistemos gedimams.

¾ Sąsajos naudojimo paprastumas;

¾ Aukštas sistemos saugumo lygis, kuris reiškia ne tik tam tikrų sistemos išteklių prieinamumo ir informacijos saugumo kontrolę visuose veikimo etapuose, bet ir atliktų veiksmų sekimą su dideliu patikimumu.

1.2 Domeno analizė

Domenų analizės ypatumas yra tas, kad ji leidžia matyti visą organizacijos operacijų rinkinį.

CASE skirtas verslo procesų analizei ir reorganizavimui – aukščiausio lygio įrankis All Fusion Process Modeler (BPwin), palaikantis IDEF0 (funkcinis modelis), DFD (Dataflow Diagram) ir IDEF3 (Workflow Diagram) metodikas. BPwin yra galingas programinės įrangos produktas, skirtas kurti modelius, leidžiančius analizuoti, dokumentuoti ir planuoti sudėtingų verslo procesų pakeitimus. BPwin siūlo įrankį viskam surinkti reikalinga informacija apie įmonės veiklą ir grafinį šios informacijos atvaizdavimą holistinio ir nuoseklaus modelio forma.

Sistemos funkcionalumo požiūriu. IDEF0 (Integration Definition for Function Modeling) metodikos rėmuose verslo procesas pateikiamas kaip darbo elementų, kurie sąveikauja tarpusavyje, visuma, taip pat parodoma kiekvieno darbo sunaudojama informacija, žmogiškieji ir gamybos ištekliai. Funkcinis modelis skirtas apibūdinti esamus verslo procesus įmonėje (vadinamasis AS-IS modelis) ir idealią reikalų būklę. – ko siekti (TO-BE modelis). IDEF0 metodika numato sudaryti hierarchinę diagramų sistemą, t.y. pavieniai sistemos fragmentų aprašymai. Pirmiausia aprašoma visa sistema ir jos sąveika su išoriniu pasauliu (kontekstinė diagrama), po to atliekamas funkcinis skaidymas. – sistema suskirstyta į posistemes ir kiekviena sistema aprašoma atskirai (dekompozicijos diagramos). Tada kiekvienas posistemis suskaidomas į mažesnes ir pan., kad būtų pasiektas norimas detalumo lygis.

Jei modeliavimo proceso metu reikia pabrėžti konkrečius įmonės technologijos aspektus, BPwin leidžia bet kurioje modelio šakoje pereiti prie DFD arba IDEF3 žymėjimo. DFD (duomenų srauto diagramos) diagramos gali papildyti tai, kas jau atsispindi IDEF3 modelyje, nes jos apibūdina duomenų srautus, leidžiančius atsekti, kaip sistemoje keičiamasi informacija tarp verslo funkcijų. Tuo pačiu metu DFD diagramos nepaiso verslo funkcijų sąveikos.

Atliktų darbų sekos požiūriu. O dar tikslesnį vaizdą galima gauti papildžius modelį IDEF3 diagramomis. Šis metodas atkreipia dėmesį į įvykių vykdymo tvarką. IDEF3 apima logikos elementus, leidžiančius modeliuoti ir analizuoti alternatyvius verslo proceso plėtros scenarijus.

Norint atsižvelgti į verslo procesus, atliekamus parduotuvės sandėlyje, reikia naudoti tik dvi metodikas IDEF0 ir DFD. Sistemos modeliavimo procesas IDEF0 prasideda nuo konteksto apibrėžimo, t.y. abstrakčiausias sistemos ar verslo procesų kaip visumos aprašymo lygis.

Modelis IDEF0. Norėdami ištirti verslo procesus „Tiekėjo užsakymo formavimas“, „Prekių gavimas“, „Prekių išdavimas“, pažvelkime į diagramas, kurios pateikiamos IDEF0 diagramos pavidalu. IDEF0 sistema vaizduojama kaip sąveikaujančių veiklų ar funkcijų rinkinys.

IDEF0 metodika remiasi keturiomis pagrindinėmis sąvokomis.

Pirmasis iš jų yra koncepcija funkcinis blokas (Veiklos laukelis). Funkcinis blokas grafiškai pavaizduotas kaip stačiakampis ir atspindi konkrečią nagrinėjamos sistemos funkciją.

Kiekviena iš keturių funkcinio bloko pusių turi savo specifinę reikšmę (vaidmenį) ir:

Viršutinė pusė nustatyta į „Valdymas“;

Kairėje pusėje nustatyta „Įvestis“;

Dešinė pusė nustatyta į Output;

Apatinė pusė turi reikšmę „Mechanizmas“.

Antrasis IDEF0 metodologijos ramstis yra sąsajos lanko (rodyklės) koncepcija. Grafinis sąsajos lanko vaizdas yra vienakryptė rodyklė. Kiekvienas sąsajos lankas turi turėti savo pavadinimą (Arrow Label). Naudojant sąsajos lankus, rodomi įvairūs objektai, kurie vienaip ar kitaip lemia sistemoje vykstančius procesus. Šiuo atveju rodyklės, atsižvelgiant į tai, į kurį darbo stačiakampio paviršių įeina arba iš kurio išeina, skirstomos į:

Įvesties rodyklės (įeina į funkcinio bloko kairę pusę) – vaizduoja duomenis ar objektus, kurie keičiasi atliekant darbus;

Valdymo rodyklės (yra viršutiniame funkcinio bloko krašte) - vaizduoja taisykles ir apribojimus, dėl kurių atliekamas darbas;

Išėjimo rodyklės (išeinančios iš funkcinio bloko dešinės pusės) - vaizduoja duomenis ar objektus, kurie atsiranda dėl darbo atlikimo;

Mechanizmo rodyklės (yra apatiniame funkcinio bloko krašte) - vaizduoja išteklius (pavyzdžiui, įrangą, žmogiškuosius išteklius).

Trečioji pagrindinė IDEF0 standarto koncepcija yra skaidymas. Dekompozicijos principas naudojamas skaidant sudėtingą procesą į jo sudedamąsias funkcijas.

Dekompozicija leidžia palaipsniui ir struktūriškai pateikti sistemos modelį atskirų diagramų hierarchinės struktūros pavidalu, todėl jis yra mažiau perkrautas ir lengviau virškinamas.

Paskutinė IDEF0 sąvoka yra žodynėlis. Kiekvienam IDEF0 elementui: diagramoms, funkciniams blokams, sąsajos lankams esamas standartas reiškia atitinkamų apibrėžimų rinkinio sukūrimą ir priežiūrą, raktinius žodžius, naratyviniai teiginiai ir pan., apibūdinantys šio elemento rodomą objektą. Šis rinkinys vadinamas žodynėliu ir yra tam tikro elemento esmės aprašymas.

Panagrinėkime verslo procesų, vykstančių OJSC DMM, „Cleonelly“ parduotuvės sandėlyje, diagramas:

Bendram sistemos matomumui būtina sukurti kontekstą „Įmonės sandėlio veikla“ (žr. 1.1 pav.).

1.1 pav. – Diagrama „Įmonės sandėlio veikla“

Nustačius kontekstą, vykdomas dekompozavimas, t.y. hierarchijoje sudarydami šias diagramas.

Kiekviena sekanti diagrama yra daugiau Išsamus aprašymas vienas iš darbų aukščiau esančioje diagramoje. Kontekstinio darbo išskaidymo pavyzdys parodytas 1.2 pav. Taigi visa sistema suskirstyta į posistemes iki reikiamo detalumo lygio, ši sistema suskirstyta į tris lygius.

1.2 pav. – Pirmojo lygio skilimo diagramos

1.3 pav. Diagrama „Gaminio dizainas“

1.4 pav. Diagrama „Prekių išleidimas“

1.5 pav. – Diagrama „Prekių gavimas“

DFD.Ši metodika paremta analizuojamos IS modelio – suprojektuoto ar realiai egzistuojančio – konstravimu. Pagal metodiką sistemos modelis apibrėžiamas kaip duomenų srautų diagramų (DFD) hierarchija, apibūdinanti asinchroninį informacijos transformavimo procesą nuo jos įvedimo į sistemą iki pateikimo vartotojui. DFD diagramos dažniausiai kuriamos taip, kad vizualiai pavaizduotų dabartinę organizacijos dokumentų valdymo sistemos veiklą. Dažniausiai DFD diagramos naudojamos kaip IDEF0 sukurto verslo procesų modelio papildymas.

Pagrindiniai duomenų srauto diagramos komponentai yra šie:

Išoriniai subjektai (grafiškai pavaizduoti kvadratu) – nurodo materialų objektą arba individualus, atstovaujantis informacijos šaltiniui arba gavėjui. Pavyzdžiui: klientai, darbuotojai, tiekėjai, klientai, sandėlis;

Sistemos/posistemės (grafiškai atrodo kaip stačiakampis su užapvalintais kampais) – darbai, žymintys funkcijas ar procesus, apdorojančius ir keičiančius informaciją;

Duomenų diskai yra abstraktus informacijos saugojimo įrenginys, kurį galima bet kada įdėti į diską ir po kurio laiko nuskaityti, o įdėjimo ir gavimo būdai gali būti bet kokie. Duomenų saugojimo įrenginys apskritai yra būsimos duomenų bazės prototipas ir joje saugomų duomenų aprašymas turi būti susietas su informaciniu modeliu;

Duomenų srautai – apibrėžia informaciją, perduodamą tam tikru ryšiu iš šaltinio į paskirties vietą. Duomenų srautas diagramoje vaizduojamas linija, kuri baigiasi rodykle, rodančia srauto kryptį.

Apsvarstykite duomenų srauto diagramą (DFD) „Prekių išdavimas“, 1.6 pav. Šioje diagramoje parodytas dokumentų judėjimas, kai organizacija gauna „prekių užklausą“.

1.6 pav. – DFD diagrama „Prekių problema“

Apsvarstykite toliau pateiktą duomenų srauto schemą „Produkto tarpas“ (žr. 1.7 pav.). Tai parodo darbų atlikimo procesą ir dokumentų judėjimą „prekių išleidimo“ metu.

1.7 pav. – DFD diagrama „Produkto registracija“

Duomenų srautų diagramos pateikia visus naudojamus simbolius į bendrą vaizdą, kuris aiškiai parodo, kokie duomenys naudojami ir kokias funkcijas atlieka darbo eigos sistema. Tuo pačiu dažnai paaiškėja, kad esami informacijos srautai, svarbūs įmonės veiklai, nėra patikimai įgyvendinami ir juos reikia pertvarkyti.********

Įmonės, užsiimančios kilpinių gaminių pardavimu, organizacinė struktūra nagrinėjama naudojant Cleonelly parduotuvės įmonės OJSC „Donetsk Manufactory M“ pavyzdį:

Kuriant medžiagų kontrolės ir apskaitos sistemas, galima sėkmingai išspręsti šias problemas:

1. Tai tiekiamų ir sandėlyje laikomų prekių kontrolė.

2. Informacija apie tiekėjus ir vartotojus

3. Jame taip pat pateikiama informacija ir su gaminiu susijusios operacijos

4. Jame yra išleistų prekių ataskaitos žurnalas

5. Yra produktų katalogas

6. Sandėlio funkcijų automatizavimas (prekių gavimas, suvartojimas, nurašymas, rezervavimas)

7. Sąskaitų už įsigytas ir parduotas prekes ir paslaugas registravimas ir saugojimas, taip pat sąskaitų išrašymas už išankstinį apmokėjimą, atidėtą apmokėjimą ir prekių pristatymą

8. Sąskaitų faktūrų surašymas ir išrašytų prekių apskaita

9. Sandėlių inventorizacija sudarant derinimo lapą, trūkumo ir pertekliaus aktą.

10. Gaminių ryšulių kūrimas

Kaip minėta, pagrindinė šios įmonės veikla yra prekyba medvilnės gaminiais. Projektavimo procesas apima daugybę etapų, kuriuos kruopščiai parengė projektavimo įmonių valdymo struktūros per visą įmonės gyvavimo laikotarpį. Šio proceso iš karto pakeisti negalima, nes jame dalyvauja daug pačios įmonės padalinių, išorės subrangovai ir projekto įmonės klientai. Todėl įmonės atsargiai diegia informacines sistemas, susijusias su projektavimo ir plėtros valdymo procesais. Paprastai Rusijos įmonės naudojasi savo plėtra šioje srityje.

1.3 Surinkimo reikalavimai

Projektuojant informacinę sistemą (IS) „Darbo vieta Didmeninė parduotuvė“, reikėjo surinkti reikalavimus, kurie padėtų sukurti tokią sąsają, kad galutiniam vartotojui (parduotuvės darbuotojui) būtų patogu dirbti su sukurta IS.

Reikalavimų inžinerija yra procesas, apimantis veiklą, reikalingą dokumentui su specifikacija sukurti ir patvirtinti Sistemos reikalavimai.

Norint įgyvendinti medžiagų apskaitos ir kontrolės automatizavimo procesą, būtina, kad informacinė sistema atitiktų šiuos funkcinius reikalavimus:

¾ rezultatų dokumentacija.

¾ Informacinė sistema turi būti įdiegta kaip programa, pagrįsta integruota Visual Fox Pro aplinka.

Programa veikia Windows 2000/NT/XP operacinėje sistemoje.

Yra keturi pagrindiniai reikalavimų rengimo proceso etapai (1.8 pav.):

Sistemos sukūrimo techninių galimybių analizė;

Reikalavimų formavimas ir analizė;

Reikalavimų patikslinimas ir atitinkamos dokumentacijos sukūrimas;

Reikalavimų sertifikavimas.

Reikalavimų rinkimas yra svarbus programinės įrangos kūrimo etapas, nes būtent čia visi klientų reikalavimai turi būti teisingai ir teisingai suformuluoti.

1.4 Reikalavimų specifikacija

Tinkamų reikalavimų nustatymas yra bene svarbiausias programinės įrangos projekto etapas. Labai svarbu, kad projekto formatas atitiktų kūrimo komandos surinktus programinės įrangos reikalavimus, kitaip šie reikalavimai negali būti palaikomi ir pateikiami programinės įrangos produkte. Programinės įrangos reikalavimų specifikacija (SRS) yra pagrindinė viso kūrimo ciklo dalis programinės įrangos produktas. Tai ne tik išvestinis dokumentas, apibrėžiantis programinės įrangos projekto specifikacijas, bet ir pagrindinis dokumentas, naudojamas atliekant kvalifikacijos ir priėmimo testus. Sertifikavimas – tai projektų vadovų darbo kokybės įvertinimas. Jis nustato programinės įrangos produkto atitikties nustatytiems reikalavimams laipsnį. SRS specifikacija veikia kaip tam tikras sistemos reikalavimų, kurie naudojami kaip sertifikavimo kriterijai, nustatymo mechanizmas.

SRS pagrindu sudaromas susitarimas tarp klientų ir programinės įrangos produktų gamintojų. SRS specifikacijoje pilnai aprašytos funkcijos, kurias turi atlikti kuriamas programinės įrangos produktas. Tai leidžia potencialiems vartotojams nustatyti, kokiu mastu produktas atitinka jų poreikius, taip pat kaip produktą galima modifikuoti, kad jis būtų naudingesnis sprendžiant jų problemas.

Sumažėja kūrimo laiko sąnaudos. Rengiant SRS specifikaciją dalyvauja įvairios klientų organizacijos grupės. Prieš pradedant realų projekto vystymą, jie atidžiai išnagrinėja visus reikalavimus. Tai sumažina vėlesnio perprojektavimo, kodavimo ir testavimo tikimybę.

Kruopštus SRS specifikacijoje pateiktų reikalavimų tyrimas gali atskleisti apsirikimus, nesusipratimus ir neatitikimus kūrimo ciklo pradžioje, kai problemas išspręsti daug lengviau nei vėliau kūrimo cikle.

SRS specifikacija tampa sąnaudų įvertinimo ir planavimo pagrindu. Produkto aprašymas yra tikrasis pagrindas įvertinti projekto kainą. Aplinkoje, kurioje egzistuoja oficialaus pasiūlymo sąvoka, pasiūlymo arba kainos sąmatai patvirtinti naudojamas SRS.

Tinkamai surašytų SRS specifikacijų pagalba organizacijos organizacijos lygmeniu gali parengti daug produktyvesnius kvalifikacijos ir audito planus. Plėtros sutartyje SRS pateikia gaires, kaip įvertinti atitiktį specifikacijoms.

SRS specifikacija leidžia lengviau perduoti programinės įrangos produktą naujiems vartotojams, taip pat įdiegti jį kituose kompiuteriuose. Taigi klientams tampa lengviau programinės įrangos produktą perkelti į kitus organizacijos padalinius, o kūrėjams – kitiems klientams.

SRS specifikacija yra atnaujinimo pagrindas. Šiame dokumente aptariamas pats produktas, o ne projekto kūrimo procesas, todėl juo galima remtis plečiant užbaigtą produktą.

Pasibaigus reikalavimų apibrėžimo ir patikslinimo procesui, būtina juos patvirtinti.

Programinės įrangos projekto reikalavimų specifikacija turėtų būti pateikta A priede.

1.5 Reikalavimų patvirtinimas

Patvirtinimas turi parodyti, kad reikalavimai tikrai apibrėžia sistemą, kurią klientas nori turėti. Reikalavimų patikrinimas yra svarbus, nes klaidų specifikacijose gali prireikti sistemos pertvarkymo ir didelių išlaidų, jei jos aptinkamos sistemos kūrimo proceso metu arba po to, kai ji buvo pradėta eksploatuoti.

Reikalavimų patvirtinimo proceso metu turi būti atliekami įvairių tipų reikalavimų dokumentacijos patikrinimai:

1. Reikalavimų teisingumo tikrinimas.

2. Nuoseklumo patikra.

3. Patikrinkite išsamumą.

4. Patikrinkite, ar įmanoma.

Yra keletas reikalavimų sertifikavimo metodų, kuriuos galima naudoti kartu arba atskirai:

1. Reikalavimų peržiūra.

2. Prototipų kūrimas.

3. Bandymo scenarijų generavimas.

4. Automatizuota nuoseklumo analizė.

Akivaizdžiausias būdas klientui suprasti sistemą yra prototipų kūrimas.

Prieš pradėdami prototipų kūrimą, galite sukurti vartotojo sąsajos schemą. Ši diagrama naudojama pagrindinių vartotojo sąsajos elementų ryšiams ištirti.

Kitas reikalavimų patvirtinimo žingsnis yra tikrasis prototipų kūrimas.

Programinės įrangos prototipas – tai dalinis arba galimas siūlomo naujo produkto įgyvendinimas. Prototipų kūrimas atlieka tris pagrindines užduotis: paaiškina ir užbaigia reikalavimų procesą, ieško alternatyvių sprendimų ir sukuria galutinį produktą.

Šio modulio pagrindinio meniu prototipas parodytas 1.9 pav.

1.6 Informacinės sistemos projektavimo metodikos pasirinkimas

Struktūrinio požiūrio į IS kūrimą esmė slypi jos skaidyme (suskirstyme) į automatizuotas funkcijas: sistema suskirstoma į funkcines posistemes, kurios savo ruožtu skirstomos į pofunkcijas, suskirstomos į užduotis ir pan. Padalijimo procesas tęsiasi iki konkrečių procedūrų. Šiuo atveju automatizuota sistema palaiko holistinį vaizdą, kuriame visi komponentai yra tarpusavyje sujungti.

Visos labiausiai paplitusios struktūrinio požiūrio metodikos yra pagrįstos keletu Bendri principai. Kaip dviese Pagrindiniai principai Naudojami šie principai:

Principas „skaldyk ir valdyk“ yra sprendimo principas sudėtingos problemos suskirstant jas į daug mažesnių savarankiškų problemų, kurias lengva suprasti ir išspręsti;

Hierarchinės tvarkos principas yra organizavimo principas komponentai problemas į hierarchines medžio struktūras, kiekviename lygyje pridedant naujų detalių.

Struktūrinėje analizėje dažniausiai naudojamos dvi įrankių grupės, iliustruojančios sistemos atliekamas funkcijas ir duomenų ryšius. Kiekviena įrankių grupė atitinka tam tikrų tipų modelius (diagramas), iš kurių dažniausiai naudojami šie:

SADT (Structured Analysis and Design Technique) modeliai ir atitinkamos funkcinės diagramos;

DFD (Data Flow Diagrams) duomenų srautų diagramos;

ERD (Entity-Relationship Diagrams) esybės ir santykių diagramos.

IS projektavimo stadijoje modeliai plečiami, tobulinami ir papildomi programinės įrangos struktūrą atspindinčiomis diagramomis: programinės įrangos architektūra, programų blokų diagramomis ir ekrano formų diagramomis.

Išvardinti modeliai kartu suteikia Pilnas aprašymas IP, nesvarbu, ar jis yra, ar naujai sukurtas. Diagramų sudėtis kiekvienu konkrečiu atveju priklauso nuo reikiamo sistemos aprašymo išsamumo.

2 INFORMACIJOS SISTEMOS PROJEKTAVIMAS

2.1 Architektūrinis projektavimas

Kuriant bet kokią sudėtingą informacinę sistemą, kritinis aspektas yra jos architektūra, kurioje ji reprezentuoja konceptualią ateities funkcinių procesų ir technologijų struktūros viziją sistemos lygmeniu ir tarpusavyje susijusioje. Paprastai sudėtingos organizacijų informacinės sistemos yra sukurtos kaip aukšto lygio sąveikaujančių komponentų, kurie patys gali būti sistemos, sudėtis. Organizacijos informacinės sistemos architektūra leidžia lengviau suprasti sistemą, nes jos funkcionalumas ir struktūra apibrėžiama taip, kad atskleidžiami projektiniai sprendimai ir leistų stebėtojui užduoti klausimus apie projektavimo reikalavimų tenkinimą, funkcionalumo pasiskirstymą ir komponentų įgyvendinimą.

Organizacijos informacinės sistemos architektūra yra modelis, kaip Informacinės technologijos palaikys pagrindinius automatizuoto objekto tikslus ir plėtros strategiją. Tai įgalina kritinį mąstymą ir aiškią viziją, kaip turėtų būti struktūrizuoti integruoti informacinių sistemų rinkiniai, kad būtų pasiekti šie tikslai. Informacinės sistemos architektūra apibūdina, kaip informacinės sistemos, programos ir žmonės veikia visoje organizacijoje nuosekliai ir vieningai.

Taigi informacinės sistemos architektūra apima visuotinai priimtą komponentų rinkinį, kuris suteikia informacinės sistemos „statybinius blokus“. Šie „statybiniai blokai“ ir jų charakteristikos yra apibrėžtos atitinkamu detalumo lygiu, kad atitiktų priimamų planavimo sprendimų poreikius.

Kuriant šiuolaikines organizacijos informacines sistemas, jų architektūra turi būti kuriama atsižvelgiant į daugelį suinteresuotųjų šalių, ji turi būti suprantama vartotojams, leisti kūrėjams planuoti ir planuoti sistemą, leisti apibrėžti pagrindines sąsajas, funkcijas ir technologijas, taip pat įvertinti projekto grafiką ir biudžetą. Tai darydami, šiuolaikiniai informacinių sistemų architektai privalo prisiimti atsakomybę už patenkinamos ir įgyvendinamos sistemos koncepcijos sukūrimą ankstyvame jos kūrimo etape, išlaikant šios koncepcijos vientisumą viso kūrimo metu ir nustatant gautos sistemos tinkamumą naudoti klientui. Kita vertus, informacinių sistemų architektūros projektavimas – tai procesas, kai informacinių sistemų architektūros aprašomos pakankamai išsamiai, kad jos būtų naudingesnės kuriant informacines sistemas.

Užsienio patirties tyrimas rodo, kad išsivysčiusiose šalyse kuriant informacinės sistemos architektūrą turi būti laikomasi šių sąlygų:

¾ sutelkti dėmesį į organizacijos misiją;

¾ dėmesys reikalavimams;

¾ dėmesys tobulėjimui;

¾ gebėjimas prisitaikyti;

¾ lankstumo poreikis.

Visų šių sąlygų laikymasis leidžia sukurti pažangesnę ir efektyvesnę organizacijos informacinės sistemos architektūrą.

Pagrindinės šiuo metu įdiegtos programinės įrangos architektūros yra šios:

¾ failų serveris;

¾ klientas-serveris;

¾ kelių lygių.

Failų serveris. Ši tinkle pasiekiama centralizuotos duomenų bazės architektūra apima vieno iš tinklo kompiuterių priskyrimą kaip dedikuotąjį serverį, kuriame bus saugomi centralizuotų duomenų bazių failai. Pagal vartotojo pageidavimus failai iš failų serverio perkeliami į vartotojo darbo vietas, kuriose atliekama didžioji duomenų apdorojimo dalis. Centrinis serveris daugiausia atlieka tik failų saugojimo funkciją, nedalyvaudamas apdorojant duomenis. Baigę darbą, vartotojai kopijuoja failus su apdorotais duomenimis atgal į serverį, iš kurio juos gali paimti ir apdoroti kiti vartotojai. Toks duomenų valdymo organizavimas turi nemažai trūkumų, pavyzdžiui, kai daug vartotojų vienu metu pasiekia tuos pačius duomenis, darbo našumas smarkiai krenta, nes reikia palaukti, kol su duomenimis dirbantis vartotojas baigs savo darbą. Priešingu atveju kai kurių vartotojų pataisymai gali būti perrašyti kitų naudotojų atliktais pakeitimais.

Kliento serveris. Šios koncepcijos idėja yra ta, kad be duomenų bazės failų saugojimo centrinis serveris turėtų atlikti didžiąją duomenų apdorojimo dalį. Vartotojai prie centrinio serverio prisijungia naudodami specialią kalbą struktūrinės užklausos(SQL, Structured Query Language), kuri aprašo serverio atliekamų užduočių sąrašą. Naudotojų užklausas priima serveris ir jame generuojami duomenų apdorojimo procesai. Atsakydamas vartotojas gauna jau apdorotą duomenų rinkinį. Tarp kliento ir serverio perduodamas ne visas duomenų rinkinys, kaip tai vyksta failų serverio technologijoje, o tik klientui reikalingi duomenys. Vos kelių eilučių naudotojo užklausa gali generuoti duomenų apdorojimą, apimantį kelias lenteles ir milijonus eilučių. Atsakydamas klientas gali gauti tik kelis numerius. Kliento-serverio technologija leidžia išvengti didžiulio informacijos kiekio perdavimo tinkle, perkeliant visą duomenų apdorojimą į centrinį serverį. Be to, nagrinėjamas metodas leidžia išvengti konfliktų tarp kelių vartotojų atliekamų tų pačių duomenų pakeitimų, kurie būdingi failų serverio technologijai. Kliento-serverio technologija įgyvendina suderintą kelių klientų duomenų modifikavimą, užtikrindama automatinį duomenų vientisumo laikymąsi. Dėl šių ir kai kurių kitų privalumų klientas-serveris technologija tapo labai populiari. Šios technologijos trūkumai yra dideli centrinio serverio našumo reikalavimai. Kuo daugiau klientų pasiekia serverį ir kuo didesnis apdorojamų duomenų kiekis, tuo galingesnis turi būti centrinis serveris.

Remiantis šiais samprotavimais, kuriant AWS architektūrą, buvo remiamasi kliento-serverio technologija. Išdėstymo diagramos atspindi fizinius ryšius tarp programinės įrangos ir sistemos aparatinės įrangos komponentų.)

2.2 Informacinės sistemos sąsajos projektavimas

Vartotojo sąsaja dažnai suprantama tik kaip išvaizda programas. Tačiau realiai vartotojas per ją suvokia visą sistemą kaip visumą, vadinasi, toks jos supratimas yra per siauras. Iš tikrųjų vartotojo sąsaja apima visus dizaino aspektus, turinčius įtakos vartotojo ir sistemos sąveikai. Vartotojas mato ne tik ekraną. Vartotojo sąsaja susideda iš daugelio komponentų, tokių kaip:

vartotojo užduočių rinkinys, kurį jis sprendžia naudodamasis sistema;

sistemos valdikliai;

navigacija tarp sistemos blokų;

vizualinis programų ekranų dizainas.

Pabrėžkime kai kuriuos svarbiausius geros vartotojo sąsajos pranašumus verslo požiūriu:

sumažinti vartotojo klaidų skaičių;

sumažinti sistemos palaikymo išlaidas;

darbuotojų produktyvumo nuostolių mažinimas sistemos diegimo metu ir greitesnis prarasto produktyvumo atstatymas;

gerinti darbuotojų moralę;

sumažinti vartotojo sąsajos keitimo vartotojų pageidavimu išlaidas;

sistemos funkcionalumo prieinamumas maksimalus kiekis vartotojų.

Automatizuota darbo vietų didmeninės prekybos duomenų bazė sukurta kaip programa, naudojant kliento-serverio technologiją.

2.2.1 Valdymo programos vartotojo sąsaja

Pagrindinis „Darbo stoties didmeninės prekybos bazės“ modulis yra Luck.exe modulis, kuriame įdiegtas pagrindinis 1.4 skyriaus 1.9 pav. pateiktos naudojimo atvejų diagramos funkcionalumas.

Kuriant informacinę sistemą, vienas pagrindinių uždavinių – sukurti paprasčiausią ir mažiausiai apkraunamą sąsają. Tai programinės įrangos produkto sąsaja, padedanti vartotojams „bendrauti“ su informacine sistema, veikianti kaip dialogas tarp vartotojo ir sistemos.

Programos sąsaja, administracinė dalis:

1. programos pradžios forma. Ši forma prasideda, kai paleidžiamas programinės įrangos produktas, taip formuojant dialogo tarp vartotojo ir sistemos pradžią (2.3 pav.);

2. administratoriaus forma. Šioje formoje vykdomas pilnas informacinės sistemos valdymas, t.y. duomenų papildymas, ištrynimas, keitimas duomenų bazėje, taip pat, esant poreikiui, ataskaitų peržiūra ir spausdinimas (2.4 pav.);

3. „Klientų“ forma, šios formos dėka matote visa informacija apie įmonės klientus (2.7 pav.);

4. Forma „Tiekėjai“, šios formos dėka galite matyti visą informaciją apie įmonės klientus (2.8 pav.).

Programos sąsajos vartotojo dalis:

Prekių pristatymo lange prekės apdorojamos. Pasirinkdamas šį formos skirtuką, vartotojas pirmiausia turi

Išlaidų meniu yra sandėlio darbuotojo atliekamos prekių išleidimo ir pardavimo operacijos.

Likučių meniu skaičiuojami sandėlyje saugomų prekių pavadinimai.

Kasos meniu čia saugoma informacija apie gaunamus ir išsiunčiamus kasos orderius.(ekrano nuotraukos)

2.2.2 Valdymo komponentų vartotojo sąsajos

2.0 pav. Pagrindinis programos meniu

Pagrindinis programos langas parodytas fig. 1.9. Kaip matyti iš paveikslo, be jau aprašyto pagrindinio meniu, jame taip pat bus valdymo pultas (mygtukai „Gaunami“, „Išlaidos“, „Prieiga“, „Likučiai“, „Pinigai“, „Perkainojimas“). , „Analytics“, „ Katalogai“, „Paslauga“ ir „Išeiti iš programos“).

2.1 pav. Atvežimo arba sandėlio gavimo meniu langas.

2.2 pav. Srauto meniu langas

2.2 pav. Meniu langas, reguliuojantis prieigos prie programos teises.

2.3 pav. Likęs elemento meniu langas.

2.4 pav. Kasos aparato meniu langas.

2.4 pav. Perkainojimo meniu langas.

2.3 Duomenų bazės dizainas

Duomenų bazei kurti buvo naudojama ERwin 4.0 iš Computer Associates Int.

ERwin yra galingas ir lengvai naudojamas duomenų bazių kūrimo įrankis, pelnęs platų pripažinimą ir populiarumą. Tai užtikrina aukščiausią produktyvumo lygį kuriant ir prižiūrint duomenų bazių programas. Viso proceso metu – nuo ​​loginio duomenų bazę apibrėžiančių informacijos reikalavimų ir verslo taisyklių modeliavimo iki fizinio modelio optimizavimo pagal nurodytas charakteristikas – ERwin leidžia vizualiai atvaizduoti duomenų bazės struktūrą ir pagrindinius elementus.

ERwin – ne tik geriausia priemonė duomenų bazėms kurti, bet ir joms skirtas įrankis greitas kūrimas. ERwin optimizuoja modelį pagal tikslinės duomenų bazės fizines charakteristikas. Skirtingai nuo kitų įrankių, ERwin automatiškai palaiko loginio ir fizinio projektavimo nuoseklumą ir paverčia logines konstrukcijas, pvz., ryšius „daugelis su daugeliu“, į jų fizinį įgyvendinimą. Palengvina duomenų bazės kūrimą. Norėdami tai padaryti, tiesiog sukurkite grafiką E-R modelis(objekto ryšys), kuris atitinka visus duomenų reikalavimus ir įveskite verslo taisykles, kad sukurtumėte loginį modelį, kuriame būtų rodomi visi elementai, atributai, ryšiai ir grupės. Ervinas turi du modelio vaizdavimo lygius – loginį ir fizinį. Loginis lygis yra abstraktus duomenų vaizdas, kuriame duomenys pateikiami taip, kaip jie atrodo realiame pasaulyje, ir gali būti vadinami taip, kaip jie vadinami realiame pasaulyje, pvz., „Nuolatinis klientas“, „Padalinys“ arba „Darbuotojas“ Pavardė". Modelio objektai, vaizduojami loginiu lygiu, vadinami esybėmis ir atributais. Loginis duomenų modelio lygis yra universalus ir niekaip nesusijęs su konkrečiu DBVS diegimu. Yra trys duomenų modelio loginio lygio polygiai, kurie skiriasi informacijos apie duomenis pateikimo gyliu:

Entity Relationships diagrama (ERD);

Duomenų modelis, pagrįstas raktais (Key Based model (KB));

Visiškai priskirtas modelis (FA)

Esybės ir santykių diagrama apima esybes ir ryšius, kurie atspindi pagrindines dalykinės srities verslo taisykles. Tokia diagrama nėra per daug detali, joje pateikiami pagrindiniai subjektai ir ryšiai tarp jų, atitinkantys pagrindinius reikalavimus. Esybės ir santykių diagramoje gali būti daug ryšių, o ne raktų aprašymas. Paprastai ERD naudojama pristatymams ir duomenų struktūros aptarimui su domeno ekspertais. Raktu pagrįstas duomenų modelis yra išsamesnis duomenų vaizdas. Jame yra visų objektų ir pirminių raktų aprašymas ir jis skirtas duomenų struktūrai ir raktams, atitinkantiems dalykinę sritį, atstovauti.

Loginis modelis yra detaliausias duomenų struktūros vaizdas: jis vaizduoja duomenis trečiąja normalia forma ir apima visas esybes, atributus ir ryšius (žr. B priedą).

Fizinių duomenų modelis priešingai, tai priklauso nuo konkrečios DBVS, iš tikrųjų tai yra sistemos katalogo atspindys. Fiziniame modelio sluoksnyje yra informacija apie visus duomenų bazės objektus. Kadangi duomenų bazės objektams nėra standartų (pavyzdžiui, nėra standarto duomenų tipams), fizinis modelio sluoksnis priklauso nuo konkretaus DBVS įgyvendinimo. Vadinasi, keli skirtingi fiziniai lygiai gali atitikti tą patį modelio loginį lygį įvairių modelių. Jei modelio loginiame lygmenyje nėra svarbiau, kokį konkretų duomenų tipą turi atributas (nors palaikomi abstrakčių duomenų tipai), tai fiziniame modelio lygyje svarbu aprašyti visą informaciją apie konkrečius fizinius objektus. lentelės, stulpeliai, rodyklės, procedūros ir kt. Duomenų modelio padalijimas į loginį ir fiziniai sluoksniai leidžia išspręsti keletą svarbių problemų.

Fizinių duomenų modelis pateiktas B priede.

2.4 Informacinės sistemos kūrimo platformos pasirinkimo pagrindimas

„Visual FoxPro“ yra vaizdinė kūrimo aplinka, skirta reliacinių duomenų bazių valdymo sistemoms, kurią šiuo metu gamina „Microsoft“. Naujausia versija yra 9.0. Naudoja FoxPro programavimo kalbą. Sistemos versija 7.0 gali veikti operacinėse sistemose Windows sistemos 9x ir NT branduoliai, 8.0 ir 9.0 versijos – tik Windows XP, 2000, 2003.

FoxPro (Fox-pro?) yra vienas iš xBase programavimo kalbos dialektų. Ji daugiausia naudojama kuriant reliacines DBVS, nors gali būti naudojama ir kitų klasių programoms kurti.Kaip minėta aukščiau, VFP kalba yra labai papildyta ir išplėsta xBase kalba. Visual FoxPro programavimo kalba, ty pagrindinė kalbos konstrukcija, yra klasės sąvoka. Originali xBase versija yra gryna struktūrinė kalba, turinti pagrindinę procedūrų ir funkcijų koncepciją. Taigi šiuolaikinė kalba Vaizdinis programavimas FoxPro leidžia derinti programavimą „senamadišku būdu“, aprašant daugybę procedūrų, ir OOP stiliumi, sukuriant sudėtingą klasių hierarchiją.

Pasirinkau šią programavimo kalbą, nes ji turi keletą privalumų:

¾ Plačiai žinomas duomenų bazės lentelės formatas, leidžiantis lengvai keistis informacija su kitomis programomis Microsoft Windows.

Modernus reliacinių duomenų bazių organizavimas, leidžiantis saugoti informaciją apie duomenų bazių lenteles, jų ypatybes, indeksus ir ryšius, nustatyti referencinio vientisumo palaikymo sąlygas, kurti vietinius ir nuotolinius vaizdus (Views), ryšius su serveriais, saugomas procedūras, vykdomas atsiradus daugiau daugiau nei 50 skirtingų renginių tipų (VFP 7.0-9.0).

Didelis greitis darbas su didelėmis duomenų bazėmis.

Didelis darbo su duomenų bazėmis matomumas: daugiafunkcinis duomenų seanso langas leidžia matyti sąrašą atviri stalai duomenų bazės, jų jungtys, filtrai, tvarka pagal indeksus, buferio režimai, pereiti prie struktūros modifikavimo režimų, darbas su lentelės informacija ir kt.

Didelis programų kūrimo greitis naudojant Wizards, Designers, Builders, IntelliSense užuominų režimą rašant programos tekstą, derinant ir testuojant sistemas.

Galimybė kurti programas, veikiančias naudojant kliento-serverio technologiją su duomenimis, esančiais Oracle ir Microsoft SQL Server duomenų bazių serveriuose ir su kitomis Microsoft Windows programomis, naudojant ODBC ir OLE

VFP sistema skirta naudoti profesionaliems programuotojams, todėl nėra prasmės rusifikuoti jos meniu ir kalbos – bet kuriam programuotojui angliška algoritminės kalbos sintaksė yra labiau pažįstama nei rusų.

2.5 Modulio projektavimas

Atidžiau pažvelkime į vieno iš programos modulių dizainą ir naudodamiesi jo pavyzdžiu pažiūrėkime į veiksmus, būtinus projektui sukurti.

Kaip pavyzdį panagrinėsiu modulio, įgyvendinančio naudojimo atvejį „Užpildo paraišką dėl priėmimo“, dizainą.

Pirmiausia apibūdinkime įvykių, vykstančių šiuo naudojimo atveju, srautą.

Būtina naudojimo atvejo sąlyga yra kliento prašymo gavimas.

5. Naudojimo atvejis prasideda klientui pateikus prašymą.

6. Vadovas atidaro Kvito formą.

7. Vadovas nustato prašymo pateikimo datą.

8. Vadovas įdeda prekės pavadinimą.

9. Vadovas įveda gaunamų prekių kiekį.

10. Vadovas suveda paraiškos sumą.

11. Vadovas uždaro formą.

12. Naudojimo atvejis baigiasi.

Naudojimo atvejo posąlyga yra paraiškos registravimas sistemoje ir naujo kliento atsiradimas pagrindiniame formos žurnale.

Pažvelkime į šio naudojimo atvejo sekos diagramą. Kaip matote iš šios diagramos, vadybininkas, atidaręs Kvito formą, verčia atlikti kelis veiksmus - automatiškai užpildoma prašymo data (vadovo požiūriu). Pildant prašymą, klientų sąrašas pildomas iš duomenų bazės su pirmine informacija. Po to vadybininkas įveda visus reikiamus duomenis ir paspaudžia mygtuką „Priimti“. Atliekami šie veiksmai. Visi duomenys perduodami saugomai procedūrai.

3 Informacinės sistemos diegimas ir sertifikavimas

3.1 Programos įgyvendinimas

Programos diegimas pagal savo prigimtį informacinės sistemos kūrėjui yra vienas iš daugiausiai darbo reikalaujančių etapų, nes užsakovo keliami reikalavimai turi būti aiškiai ir teisingai integruoti į sistemą. Dar nėra programinės įrangos produktų, kurie galėtų „prisiderinti“ prie vadinamojo kliento reikalavimų ir suteikti tam tikrą funkcijų rinkinį, kad būtų galima įdiegti šiuos reikalavimus atitinkančią sistemą. Todėl kiekvienas kūrėjas turi pats pasirinkti optimalią sistemos kūrimo aplinką, tačiau reikia atkreipti dėmesį, kad diegiant aplikaciją be rašymo neapsieisite programos kodas. Būtent rašant programos kodą bus įgyvendinamos tam tikros funkcijos, kurias turi atlikti sistema. Priklausomai nuo pasirinktos sistemos diegimo aplinkos, programos kodas atrodys kitaip, tokioje aplinkoje kaip Microsoft Visual FoxPro turės vieną programos kodą, Visual Basic – kitą ir t.t.

Šiuo atveju programa buvo įdiegta Microsoft Visual FoxPro.

Pagrindinės sistemos funkcijos bus aprašytos toliau:

1. Sistemos pradinė forma. Ši forma yra mygtukų forma ir atitinkamai kiekvienas mygtukas atlieka savo funkciją. Administratoriaus registracijos mygtukas parodytas 3.1 pav.. Šis mygtukas atliks funkciją, kuri atidarys administratoriaus skydelį, jei vartotojas turi tokias teises į šią sistemą

2. Atvykimo meniu mygtukas. Šis mygtukas leidžia sekti į parduotuvės sandėlį gaunamas prekes (3.2 pav.).

3. Išlaidų meniu mygtuke vedama iš sandėlio išleistų prekių apskaita (3.3 pav.).

4. Prieigos meniu mygtuke reguliuojamos teisės naudotis šia programa (3.4 pav.).

5. Meniu mygtukas „lieka“ saugo informaciją apie parduotuvės sandėlyje saugomas medžiagas (3.5 pav.).

6. Kasos aparato meniu mygtukas saugo informaciją apie gaunamus kasos orderius ir išsiunčiamus kasos orderius (3.6 pav.).

7. Meniu mygtuku perkainojimas vyksta per kainų pokyčius iki nauja kaina gaminys 3.7 pav.

3.1 pav. – Sistemos pradinė forma

3.2 pav. – Medžiagos gavimo sandėlyje registravimo forma.

3.3 pav. Parduotų prekių apskaitos forma.

3.4 pav. Forma, reguliuojanti prieigos prie programos teises.

3.5 pav. – Sandėlyje likusių prekių forma.

3.5 pav. Įeinančių ir išsiunčiamų kasos orderių forma.

3.6 pav. Prekių sandorių forma.

Taikymo testavimas

Testavimas yra programos vykdymo procesas, siekiant aptikti klaidas. Testavimas suteikia:

Klaidų aptikimas;

Programos funkcijų atitikimo jos paskirčiai demonstravimas;

Programos veiklos reikalavimų įgyvendinimo demonstravimas;

Patikimumo rodymas kaip programos kokybės rodiklis.

3.2 paveiksle pavaizduoti testavimo proceso informacijos srautai.

Testavimo proceso įvestyje yra trys srautai:

Programos tekstas;

Pradiniai programos paleidimo duomenys;

Tikėtini Rezultatai.

Atliekami testai ir įvertinami visi gauti rezultatai. Tai reiškia, kad tikrieji bandymo rezultatai lyginami su laukiamais rezultatais. Kai aptinkamas neatitikimas, įrašoma klaida ir pradedamas derinimas.

Surinkus ir įvertinus testų rezultatus, pradedama rodyti programinės įrangos kokybė ir patikimumas. Jei reguliariai susiduriama su rimtomis klaidomis, dėl kurių reikia keisti dizainą, tada programinės įrangos kokybė ir patikimumas kelia įtarimų, todėl teigiama, kad reikia stiprinti testavimą.

Testavimo metu sukauptus rezultatus galima įvertinti formaliau. Tam naudojami programinės įrangos patikimumo modeliai, kurie atlieka patikimumo prognozes pagal realius klaidų lygio duomenis.

Yra 2 programos testavimo principai:

Funkcinis testavimas (juodosios dėžės testavimas);

Struktūrinis testavimas (baltos dėžutės testavimas).

Baltosios dėžutės testavimo metu yra žinoma vidinė programos struktūra. Čia tikrinamas ne išorinis, o vidinis programos elgesys. Tikrinamas visų programos elementų konstrukcijos teisingumas ir tarpusavio sąveikos teisingumas.

Juodosios dėžės bandymai ( funkcinis testavimas) leidžia gauti įvesties duomenų derinius, kurie pateikia pilnas patikrinimas visi programos funkciniai reikalavimai //. Programinės įrangos produktas čia laikomas „juodąja dėže“, kurios elgesį galima nustatyti tik ištyrus jo įvestis ir atitinkamus išėjimus.

Juodosios dėžės principas nėra baltos dėžės principo alternatyva. Atvirkščiai, tai yra papildomas metodas, kuriuo aptinkamos skirtingos klaidos.

Juodosios dėžės testavimas ieško šių kategorijų klaidų:

Netinkamos arba trūkstamos funkcijos;

sąsajos klaidos;

Klaidos išorinėse duomenų struktūrose arba prieigos prie išorinės duomenų bazės;

Charakteristinės klaidos (reikalinga atminties talpa ir kt.);

Inicijavimo ir užbaigimo klaidos.

Skirtingai nuo baltosios dėžės testavimo, kuris atliekamas bandymo proceso pradžioje, juodosios dėžės testavimas naudojamas vėlesniuose testavimo etapuose. Bandydami „juodąją dėžę“, jie nepaiso valdymo struktūra programas. Čia dėmesys sutelkiamas į apibrėžimo informacinę sritį programinės įrangos sistema. Atliekant testavimą šiame etape dėmesys sutelkiamas į sprendimo tinkamumą naudoti gyvoje gamybos aplinkoje. Pagrindinis dėmesys skiriamas klaidų taisymui ir jų sunkumo nustatymui bei produkto paruošimui išleidimui.

Testavimo etape išsprendžiamos dvi pagrindinės užduotys:

Sprendimo testavimas - vykdomi planavimo etape sukurti ir kūrimo etape išplėsti ir išbandyti bandymų planai;

Pilotinis veikimas – sprendimo diegimas bandomojoje aplinkoje ir testavimas įtraukiant būsimus vartotojus bei realių sistemos naudojimo scenarijų įgyvendinimas. Ši užduotis atliekama prieš pradedant diegimo etapą.

Testavimo etapo tikslas – sumažinti riziką, kuri kyla, kai sprendimas pradedamas naudoti komerciniais tikslais.

Kad testavimo etapas būtų sėkmingas, būtina, kad pasikeistų požiūris į projektą ir kūrėjas pereitų nuo naujų funkcijų kūrimo prie tinkamos sprendimo kokybės užtikrinimo.

Šiame informacinės sistemos kūrimo etape būtina atlikti šių tipų testavimą:

Pagrindinis testavimas yra žemo lygio techninis testavimas. Tai atlieka pats kūrėjas, rašydamas programos kodą. Naudojamas „baltos dėžutės“ metodas, yra didelė klaidų rizika.

Naudojimo testavimas – tai aukšto lygio testavimas, kurį atlieka testuotojas ir būsimi produkto vartotojai. Naudojamas „juodosios dėžės“ metodas.

Alfa ir beta versijos testavimas – kalbant apie MSF, alfa kodas iš esmės yra visas šaltinio kodas, sukurtas MSF proceso modelio kūrimo etape, o beta kodas yra kodas, kuris buvo išbandytas testavimo etape. Todėl MSF proceso modelio kūrimo fazėje yra testuojamas alfa kodas, o testavimo fazėje – beta kodas.

Suderinamumo testavimas – kuriamas sprendimas reikalingas norint integruotis ir sąveikauti su esamomis sistemomis ir programinės įrangos sprendimais. Ši testavimo forma yra orientuota į sukurto sprendimo integralumo ir gebėjimo sąveikauti su esamomis sistemomis patikrinimą. Šiuo konkrečiu atveju bus patikrintas teisingas programos veikimas vartotojo įrangoje ir vartotojo naudojama programinė įranga.

Našumo testavimas yra skirtas patikrinti, ar programa atitinka našumo ir greičio komforto lygio reikalavimus.

Dokumentacijos ir pagalbos sistemų testavimas – testuojami visi sukurti lydintys dokumentai ir pagalbos sistemos.

Bandomoji operacija bando sprendimą pramoninėje aplinkoje. Pagrindinis bandomosios veiklos tikslas – parodyti, kad sprendimas gali stabiliai veikti pramoninėmis sąlygomis ir atitinka verslo reikalavimus. Pilotinio veikimo metu sprendimas išbandomas realiomis sąlygomis. Pilotinis veikimas suteikia vartotojams galimybę pareikšti savo nuomonę apie gaminio veikimą. Vadovaudamasis šia nuomone, kūrėjas pašalina visas galimas problemas arba sukuria veiksmų planą, susidarius nenumatytoms aplinkybėms. Galiausiai bandomasis projektas leidžia nuspręsti, ar pradėti visapusišką diegimą, ar palaukti, kol bus išspręstos problemos, galinčios sutrikdyti diegimą.

Kuriamos informacinės sistemos bandomasis veiklos proceso planas parodytas 3.2 lentelėje.

3.2 lentelė. Bandomasis veiklos planas

Veiksmas		apibūdinimas
1. Sėkmės kriterijų pasirinkimas		Kūrėjas ir bandomojo testavimo dalyviai nustato sėkmės kriterijus ir dėl jų susitaria
2. Vartotojų ir diegimo vietos pasirinkimas		Formuojama bandomųjų testavimo dalyvių iš vartotojų ir kūrėjų komanda. Nustatoma bandomojo proceso vieta.
3. Vartotojų paruošimas ir įrengimo vieta		Vykdomi vartotojų – testo dalyvių mokymai. Montavimo vieta ruošiama.
4. Prototipo versijos diegimas		Bandomoji versija yra įdiegta ir pradėta eksploatuoti.
5. Bandomosios versijos palaikymas ir stebėjimas		Vartotojų ir sistemos veikimo stebėjimas, pagalbos teikimas eksploatuojant, informacijos apie sistemos veikimą rinkimas
6. Atsiliepimas su vartotojais ir rezultatų įvertinimu		Vartotojai išsako savo nuomonę apie sistemos veikimą, nurodo trūkumus ir klaidas.
7. Pakeitimai ir papildymai	Aptiktos klaidos ištaisomos ir atliekami projekto ar proceso pakeitimai. Pataisyti rezultatai pateikiami vartotojams darbui ir įvertinimui.
8. Diegimo sprendimai	Jei bandomojo testavimo rezultatai vartotojus tenkina, priimamas sprendimas diegti sistemą.

3.2 Programų diegimo metodika

Šiame etape kūrėjas (arba komanda) diegia sprendimui reikalingas technologijas ir komponentus, projektas pereina į priežiūros ir palaikymo stadiją, o klientas galiausiai jį patvirtina. Po įdiegimo komanda įvertina projektą ir apklausia vartotojus, kad nustatytų jų pasitenkinimą.

Diegimo etapo tikslai:

¾  sprendimą perkelti į pramoninę aplinką;

¾  užsakovo pripažinimas, kad projektas baigtas.

Konkrečiai vietai skirtų komponentų diegimas susideda iš kelių etapų: paruošimo, įrengimo, mokymo ir oficialaus patvirtinimo.

Sistemos diegimo etapo rezultatai – priežiūros ir palaikymo sistemos, dokumentų saugykla, kurioje yra visos projekto metu sukurtų dokumentų ir kodo versijos.

Kuriamai sistemai diegti buvo sudarytas veiksmų planas, kuris parodytas 3.1 lentelėje.

3.1 lentelė. Programos diegimo planas

Veiksmas	Veiksmo aprašymas
1. Atsarginė kopija	Vartotojo duomenų atsarginės kopijos sukuriamos jam dalyvaujant ir jam pritarus, perduodant informaciją į keičiamąją laikmeną (CD, DVD)
2. Sprendimo pagrindinių komponentų montavimas	Technologijų taikymas, užtikrinantis sprendimo veikimą. Šiuo atveju įdiegiamas Visual FoxPro komponentas
3. Kliento programos įdiegimas	Perkėlimas į vartotojo kompiuterį ir sukurtos IS bei duomenų bazės galutinės versijos įdiegimas
4. Mokymas	Vartotojai apmokomi dirbti su sistema, kūrėjas užtikrina, kad klientai teisingai suprastų IS darbą ir
5. Projekto žinių bazės perdavimas klientui	Visa projektinė dokumentacija perduodama užsakovui
6. Projekto uždarymas	Parengiama projekto užbaigimo ataskaita. Klientas pasirašo priėmimo aktą.

Normaliam automatizuotos darbo vietos funkcionavimui tai būtina Operacinė sistema Microsoft WindowsXP.

4 Valdymas informacinis projektas

4.1 Kūrimo gyvavimo ciklo pasirinkimas

Vienas iš pagrindinės sąvokos IS projektavimo metodika – tai jos programinės įrangos gyvavimo ciklo (programinės įrangos gyvavimo ciklo) samprata. Programinės įrangos gyvavimo ciklas yra nenutrūkstamas procesas, kuris prasideda nuo to momento, kai priimamas sprendimas dėl jos sukūrimo poreikio, ir baigiasi jos visiško pašalinimo iš tarnybos momentu.

Pagrindinis norminis dokumentas, reglamentuojantis programinės įrangos gyvavimo ciklą, yra tarptautinis standartas ISO/IEC 12207 (ISO – Tarptautinė standartizacijos organizacija, IEC – Tarptautinė elektrotechnikos komisija). Ji apibrėžia gyvavimo ciklo struktūrą, apimančią procesus, veiklą ir užduotis, kurios turi būti atliekamos kuriant programinę įrangą.

ISO/IEC 12207 standartas nesiūlo konkretus modelis Gyvenimo ciklas ir programinės įrangos kūrimo metodai. Gyvavimo ciklo modelis gali būti suprantamas kaip struktūra, kuri apibrėžia vykdymo seką ir ryšius tarp procesų, veiksmų ir užduočių, atliekamų gyvavimo ciklo metu. Gyvavimo ciklo modelis priklauso nuo informacinės sistemos specifikos ir konkrečių sąlygų, kuriomis ji kuriama ir veikia.

Šiandien yra daug programinės įrangos gyvavimo ciklo modelių, tačiau du populiariausi ir plačiausiai paplitę modeliai yra šie:

Spiralinis modelis (žr. 4.1 pav.);

Iteratyvus modelis.

4.1 pav. – Programinės įrangos gyvavimo ciklo spiralinis modelis

Sukurti informacinę sistemą, t.y. "Automatizuotas darbo vieta sandėlio darbuotojo didmeninės prekybos depas“, pasirinktas pasikartojantis. Iteratyvaus modelio išskirtinis bruožas yra tai, kad jis yra formalus metodas, susideda iš nepriklausomų fazių, atliekamų nuosekliai ir dažnai peržiūrimas (4.2 pav.). Iteratyvus metodas puikiai pasiteisino kuriant informacines sistemas, kurioms pačioje kūrimo pradžioje visi reikalavimai gali būti gana tiksliai ir iki galo suformuluoti, kad kūrėjams būtų suteikta laisvė juos įgyvendinti kuo geriau iš techninės pusės. požiūrio.

Iteracinio modelio pranašumai:

Modelis yra gerai žinomas ne programinės įrangos kūrimo vartotojams ir galutiniams vartotojams.

Patogumas ir naudojimo paprastumas, nes visi darbai atliekami etapais (pagal modelio fazes);

Reikalavimų stabilumas;

Modelis yra lengvai suprantamas;

Net ir prastai techniškai apmokytas personalas (nepatyrę vartotojai) gali vadovautis modelio struktūra;

Modelis tvarkingai susidoroja su sudėtingumu ir puikiai tinka projektams, kurie yra gana paprasti;

Modelis skatina griežtą projektų valdymo kontrolę;

Projekto vadovui lengviau planuoti ir surinkti kūrimo komandą.

4.2 pav. Iteratyvus programinės įrangos gyvavimo ciklo modelis

Modelio etapai:

Analizės etape nustatomos funkcijos, kurias turi atlikti sistema, nustatomos aukščiausio prioriteto, pirmiausia reikalaujančios detalizavimo, aprašomi informacijos poreikiai;

Projektavimo etape sistemos procesai nagrinėjami išsamiau. Funkcinis modelis išanalizuojamas ir prireikus koreguojamas. Kuriami sistemos prototipai;

Diegimo etape sistema kuriama;

Diegimo etape gatavas produktas įvedamas į jau egzistuojančią organizacijos sistemą. Vykdomi vartotojų mokymai;

Priežiūros etape programinės įrangos produktas aptarnaujamas (bet koks papildymas ar pakeitimas, kad produktas būtų funkcionalesnis).

Programinės įrangos kūrimo gyvavimo ciklo modelio pasirinkimas yra svarbus žingsnis. Todėl projektui programinės įrangos kūrimo gyvavimo ciklo modelį galima pasirinkti naudojant šiuos procesus.

Skirtingų projekto kategorijų analizė, pateikta lentelėse.

Atsakykite į kiekvienos kategorijos klausimus, pabraukdami žodžius „taip“ ir „ne“.

Kategorijas ar problemas kiekvienoje kategorijoje suskirstykite pagal svarbą projektui, kuriam pasirenkamas tinkamas modelis.

Kūrimo komanda. Remiantis galimybėmis, personalo atranka į kūrimo komandą vyksta dar prieš pasirenkant programinės įrangos kūrimo gyvavimo ciklo modelį. Tokios komandos charakteristikos (žr. G priedą, G.1 lentelę) vaidina svarbų vaidmenį renkantis gyvavimo ciklo modelį, tai reiškia, kad komanda gali suteikti reikšmingą pagalbą pasirenkant programinės įrangos produkto gyvavimo ciklo modelį, nes atsako už sėkmingą sukurto gyvavimo ciklo modelio įgyvendinimą .

Vartotojų komanda. Pradiniuose projekto etapuose galima pilnai suprasti vartotojų grupę (žr. priedą IR I.1 lentelę), kuri dirbs su sukurta programine įranga, ir jos būsimus santykius su kūrimo komanda viso projekto metu. Šis vaizdavimas padeda pasirinkti tinkamą modelį, nes kai kuriems modeliams reikalingas didesnis vartotojo dalyvavimas kūrimo procese ir dizaino tyrimas, kadangi kūrimo proceso metu vartotojas gali šiek tiek pakeisti reikalavimus, kūrėjas turi žinoti šiuos pakeitimus ir kaip parodyti šiuos programinės įrangos pakeitimus.

4.2 Programinės įrangos projekto tikslo ir apimties apibrėžimas

Kuriamas programinis produktas, skirtas prekių apskaitai sandėlyje, automatizuos duomenų apie prekes sandėlyje gavimo, struktūrizavimo ir saugojimo procesą, taip pat supaprastins ataskaitų išrašymo procesą.

Programinės įrangos projekto tikslai bus sukurti ir įdiegti prekių apskaitos sistemą. Ši sistema skirtas vidiniam naudojimui Cleonelly personalui, dažniausiai įmonės sandėlio darbuotojams.

Norėdami nustatyti programinės įrangos produkto apimtį, toliau bus aprašyta, koks programinės įrangos projektas turėtų būti ar neturėtų būti.

Programinės įrangos projektas turi būti:

Vidiniam naudojimui organizacijos viduje;

Daugelio vartotojų prieigos projektas;

Projektas, turintis galimybę įvesti, keisti ir saugoti informaciją apie įmonės produktą;

Projektas, turintis galimybę įvesti, keisti ir saugoti informaciją apie sistemos vartotojus;

Projektas, turintis galimybę įvesti, keisti ir saugoti informaciją apie organizacijos klientus ir tiekėjus, kurie yra sudarytų sandorių subjektai;

Projektas, kuris generuos išorines ataskaitas.

4.3 Operatyvaus darbų sąrašo struktūros sukūrimas

Norint sukurti unikalų produktą ar paslaugą (projekto rezultatą), reikia atlikti tam tikrą darbų seką. Projekto planavimo užduotis – tiksliai įvertinti šių darbų laiką ir kainą. Kuo tikslesnė sąmata, tuo kokybiškesnis projekto planas. Norėdami tiksliai įvertinti, turite gerai suprasti projekto darbo apimtį, ty tiksliai žinoti, kokius darbus reikia atlikti, kad gautumėte rezultatą. Tik sudarius projekto veiklų sąrašą, įvertinama kiekvienos iš jų trukmė ir paskirstomi ištekliai, reikalingi joms atlikti. Ir tik tada galite įvertinti kiekvienos užduoties kainą ir laiką, o kartu ir bendrą projekto kainą bei trukmę. Štai kodėl darbo apimties apibrėžimas yra pirmasis projekto planavimo žingsnis. Projektavimo darbų apimties nustatymas prasideda nuo projekto etapų (arba etapų) apibrėžimo. Pavyzdžiui, projekte sukurti sistemą „Prekių apskaita sandėlyje“ galima išskirti šiuos etapus:

Programinės įrangos reikalavimų kūrimas;

Informacinių sistemų projektavimas;

Informacinės sistemos diegimas ir sertifikavimas;

Sistemos diegimas.

Nustačius etapų sudėtį ir jų rezultatus, būtina nustatyti šių fazių seką viena kitos atžvilgiu ir jų įgyvendinimo terminus. Tada reikia nustatyti, iš kokių darbų susideda etapai, kokia seka šie darbai atliekami ir kokių terminų turi būti laikomasi jų atlikimui.

Operatyvinis darbų sąrašas (4.3 pav.) buvo sudarytas naudojant programinės įrangos produktą, tokį kaip MS Project 2003.

4.3 pav. – Operatyvinis darbų sąrašas

4.4 Programinės įrangos kūrimo trukmės ir išlaidų įvertinimas

Trukmės įvertinimas. Jis nustatomas sudarius operatyvinį darbų sąrašą (4.3 pav., 4.3 punktas). Šį trukmės įvertinimą galima pamatyti naudojant Ganto diagramą (K priedas).

Diagramos yra grafinė priemonė projekto faile esančiai informacijai rodyti. Diagramos gali vaizdžiai parodyti užduočių seką, jų santykinę trukmę ir viso projekto trukmę.

Ganto diagrama yra vienas iš populiariausių būdų grafiškai pavaizduoti projekto planą, naudojamas daugelyje projektų valdymo programų.

MS Project Ganto diagrama yra pagrindinė projekto plano vizualizavimo priemonė. Ši diagrama yra grafikas, kuriame laiko skalė dedama horizontaliai, o užduočių sąrašas – vertikaliai. Šiuo atveju užduotis žyminčių segmentų ilgis yra proporcingas užduočių trukmei.

Ganto diagramoje prie juostų gali būti rodoma papildoma informacija (prie užduočių rodomi su jais susijusių išteklių pavadinimai ir jų apkrova, kai užduotis yra baigta).

Išlaidų įvertinimas

Projektas susideda iš užduotys , tai yra veikla, skirta tam tikram rezultatui pasiekti. Tam, kad užduotis būtų atlikta, jai skiriamos lėšos išteklių .

Svarbi išteklių savybė yra jų panaudojimo projekte kaina (Cost). MS Project yra dviejų tipų išteklių sąnaudos: laiko norma ir naudojimo kaina.

Laiko norma (Įkainis) išreiškiama ištekliaus naudojimo kainomis per laiko vienetą, pavyzdžiui, 100 rublių per valandą arba 1000 rublių per dieną. Tokiu atveju išteklių dalyvavimo projekte kaina bus laikas, per kurį jis dirba projekte, padaugintas iš valandinio tarifo.

Šiuo atveju buvo naudojama laiko norma (4.4 pav.) Bendros išteklių naudojimo išlaidos matomos 4.5 pav.

4.4 pav. Išteklių naudojimo laikas

Šiame paveikslėlyje matote, kad sistemos kūrėjas, vykdydamas projektą, gauna 50 rublių per valandą; verslo analitikas gauna 45 rublius per valandą, testeris – 38 rublius per valandą. Į viršvalandžių įkainius neatsižvelgiama.

4.5 pav. Bendros projekto išteklių naudojimo išlaidos

4.5 Projekto išteklių paskirstymas

Sistemos „Prekių apskaita sandėlyje“ išteklių paskirstymo fragmentas matomas 4.6 pav.

4.6 pav. Projekto išteklių paskirstymo fragmentas

Kiekvienam projekte atliktam darbui priderinamas išteklius, kuris bus atliktas Šis darbas. Paveiksle parodytas bendras kiekvienam ištekliui sugaištas darbo kiekis ir konkretus tam tikrą dieną praleistų valandų skaičius.

4.6 Projekto ekonominio naudingumo įvertinimas

Projekto ekonominio naudingumo skaičiavimas yra svarbus žingsnis. Čia bus skaičiuojamas projekto ekonominis naudingumas. Šis skaičiavimas parodys, kiek projektas pelningas, ar visiškai nepelningas. Skaičiuojant projekto ekonominį naudingumą, reikės skaičiuoti projekto atsipirkimo laikotarpį. Atsipirkimo laikotarpis parodys laikotarpį, per kurį projektas atsipirks.

Įvesties duomenys.

Papildomas pelnas iš projekto (DP) = 38 000 rublių. Papildomą pelną prognozavo įmonės ekspertai.

Pradinė investicija (IC) = 39 396,47 rubliai. Pradinės investicijos atitinka bendras projekto išteklių panaudojimo išlaidas (4.5 pav., 4.6 pastraipa)

Diskonto norma (i) = 12%.

Trukmė, kuriai skirtas projektas (n) = 2 metai.

Papildomas pelnas iš projekto (DP) = 38 000 rublių.

Metinės projekto įgyvendinimo išlaidos (Z 1) = 15 000 rublių.

Metinės projekto įgyvendinimo išlaidos (Z 2) = 10 000 rublių.

Metiniai grynųjų pinigų įplaukos (R 1) = 23 000 rublių.

Metiniai grynųjų pinigų įplaukos (R 2) = 28 000 rublių.

Vertinant investicinius projektus, naudojamas grynosios dabartinės vertės apskaičiavimo metodas, kurio metu diskontuojami pinigų srautai: visos pajamos ir sąnaudos sumažinamos iki vieno momento.

Centrinis rodiklis nagrinėjamame metode yra NPV (grynosios dabartinės vertės) rodiklis – pinigų srautų einamoji vertė. Tai apibendrintas galutinis investicinės veiklos rezultatas absoliučiais dydžiais.

Svarbus momentas yra diskonto normos pasirinkimas, kuris turėtų atspindėti numatomą vidutinį paskolos palūkanų lygį finansų rinkoje.

Grynoji dabartinė vertė (NPV) apskaičiuojama pagal 4.2 formulę

(4.2)

R k – metinės kasos pajamos už n metų.

k – metų, kuriems projektuojamas, skaičius.

IC – pradinė investicija.

i – diskonto norma.

Pagal šios formulės skaičiavimus NPV = 3 460,67 RUB

NPV rodiklis yra absoliutus padidėjimas, nes jis įvertina, kiek dabartinės pajamos padengia esamas išlaidas. Kadangi NPV > 0, projektas turėtų būti priimtas.

Investicijų grąža (IG) apskaičiuojama pagal 4.3 formulę

(4.3)

Pagal skaičiavimus (IG) = 108,78 %

4.1 lentelė  Pagalbinė lentelė projekto atsipirkimo laikotarpiui skaičiuoti

= 1,84

Atsipirkimo laikotarpis n ok = 1,84 metų (1 metai ir 11 mėnesių)

Kadangi ROI = > 100% (būtent = 108,78%), projektas laikomas pelningu.

(4.4)

Taigi pelningumo indeksas lygus (PI) =1,2

Ryžiai. 6.2.

(Įmonės informacinė sistema)

Įmonės informacinių sistemų perdavimas iš išorės

Gamybos funkcijų ir verslo procesų perdavimas įmonių informacinėmis sistemomis leidžia pasinaudoti naujausiais šiuolaikinio valdymo pasiekimais ir „geriausia praktika“. Įmonės informacinių sistemų diegimas yra verslo procesų pertvarkymo pagrindas (Verslo procesas...
(Užsakomosios paslaugos ir darbuotojų perkėlimas: aukštosios valdymo technologijos)

Įmonės informacinių sistemų integravimo modeliai

Informacinių sistemų integravimo modeliai yra aukščiausias dizaino modelių klasifikacijos lygis. Panašiai kaip žemesnių klasifikavimo lygių modeliai, tarp integracijos modelių yra identifikuojama struktūrinių modelių grupė. Struktūriniai modeliai apibūdina pagrindinius vieno integruoto...
(Įvadas į programinės įrangos architektūrą)

ĮMONIŲ INFORMACINĖS SISTEMOS FUNKCINĖS UŽDUOTYS IR PAGRINDINIAI ŠIUOLAIKINIŲ ĮMONĖS INFORMACIJŲ SISTEMŲ MODULIAI. MODULIŲ INTEGRAVIMAS

Esminė modulio sąvokos prasmė apima funkcinių posistemių, funkcinių užduočių palyginimą funkcinės užduoties požiūriu su pagrindiniais šiuolaikinių modulių. Ryžiai. 6.2. Funkcinių užduočių palyginimas su pagrindiniais modernių ICISP pagrindu veikiančių įmonių informacinių sistemų moduliais,...
(Įmonės informacinė sistema)

ĮMONIŲ INFORMACINIŲ SISTEMŲ SAMPRATA, RAJIMO ISTORIJA IR KLASIFIKACIJA. INTEGRUOTOS ĮMONĖS ĮMONĖS INFORMACIJOS SISTEMOS

Informacinių sistemų samprata ir klasifikacija keičiasi jų istorinės raidos procese. Tačiau tikslas išlieka pastovus ir yra susijęs su įmonės valdymo efektyvumu. Įmonės valdymo efektyvumas priklauso nuo daugelio veiksnių sąveikos, tarp jų: ​​filosofinių, istorinių,...
(Įmonės informacinė sistema)

MODERNIŲ INFORMACIJŲ TECHNOLOGIJŲ SAVYBĖS ĮMONIŲ INFORMACINĖSE SISTEMOSE

MODERNIOS TECHNOLOGIJOS DUOMENŲ ĮVEŽIMO Į BENDROVĖS INFORMACIJOS SISTEMAS ORGANIZAVIMO TECHNOLOGIJOS Informacija apie verslo sandorius turi būti nedelsiant įvedama į operacinę duomenų bazę iš bet kokių jos atsiradimo šaltinių. Tai leis efektyviai organizuoti tolesnį duomenų apdorojimą informacinėje...
(Įmonės informacinė sistema)

Remdamiesi kuriamos informacinės sistemos paskirtimi, toliau kursime modulinę programos struktūrą. Norėdami nustatyti modulinę struktūrą, naudosime komponentų diagramą UML žymėjimai 2.0 (3.4 pav.).

Ryžiai. 3.4

Informacinė sistema susideda iš trijų komponentų:

• 1. Sąsaja. Vartotojo sąveikos su informacine sistema įgyvendinimas. Sudėtyje yra šie moduliai:
  • · Input/output – informacijos įvedimo ir išvedimo organizavimas dirbant su IS;
  • · Ataskaitų teikimas – ataskaitų organizavimas pagal nustatytas dokumentacijos formas įvairioms įdarbinimo agentūros veiklos sritims;
  • · Paieška – kandidatų ir laisvų darbo vietų paieškos organizavimas pagal nurodytus parametrus;
• 2. Duomenų apdorojimas. Informacijos apdorojimo funkcijų įgyvendinimas: duomenų paieška duomenų bazėje, matematinis modelis pirminės dokumentų analizės uždaviniui atlikti ir kt.;
• 3. DB. Duomenų saugyklos, kurioje yra informacija apie klientus, įdiegimas.

Duomenų bazės struktūros kūrimas

Kaip minėta anksčiau, informacinėje sistemoje visa informacija yra saugoma vienoje duomenų bazėje. Duomenų bazės loginei struktūrai modeliuoti naudota IDEF1x metodika. Pagal šią metodiką informacinio modelio kūrimo procesas susideda iš šių žingsnių:

• · subjektų apibrėžimas; priklausomybių tarp subjektų apibrėžimas;
• · pirminių ir alternatyvių raktų nustatymas;
• · esybės atributų apibrėžimas;
• · modelio pakėlimas į reikiamą normalios formos lygį;
• · perėjimas prie fizinis aprašymas modeliai: atitikmenų priskyrimas objekto pavadinimas - lentelės pavadinimas, objekto atributas - lentelės atributas;
• · trigerių, procedūrų ir apribojimų nustatymas;
• · Duomenų bazių generavimas.

Esybės ir ryšių diagrama, apibūdinanti duomenų bazę pagal IDEF1.x, sudaryta iš trijų pagrindinių blokų – objektų, atributų ir ryšių. Jei laikysime diagramą kaip grafinis vaizdavimas dalykinės srities taisyklės, tada esybės ir atributai yra daiktavardžiai, o santykiai – veiksmažodžiai.

Kadangi būsimoji IS atliks paiešką šioje duomenų bazėje, pagrindiniai dokumento atributai buvo pasirinkti:

• - dokumento pavadinimas;
• - dokumento gavimo į archyvą data (archyvavimo paslaugas teikiančios advokatų kontoros stebi dokumentacijos saugojimo terminus. Kiekvienas dokumentas turi savo galiojimo laiką. Daugelis vertybinių popierių laikui bėgant praranda savo aktualumą, jų vertė sumažėja iki nulio. Tokie dokumentai turi būti sunaikinti.Savalaikis tokių popierių parinkimas ir dokumentų sunaikinimas yra įtrauktas į advokatų kontorų teikiamų archyvavimo paslaugų paketą.Kiekvieną dokumentą priėmus saugoti, atlikus specialią ekspertizę, nustatomas saugojimo terminas. dokumentas pateikiamas sunaikinti);
• - dokumento priklausomybė (tipas) (nes visi dokumentai buvo suskirstyti į 7 tipus, kuriems jie buvo suskirstyti pagal svarbą);
• - stulpelio numeris;
• - lentynos numeris;
• - skaidrės numeris (šie 3 parametrai būtini norint nustatyti dokumento vietą archyve);
• - dokumento buvimas jo langelyje (reikia žinoti, ar dokumentas yra archyve, ar jis buvo išduotas pareiškėjui).

Prašymo atrinkti visus vienam klientui priklausančius dokumentus rezultatas turėtų atrodyti taip, žr. 3.5 pav. Pateiktame pavyzdyje dokumentų skaičius buvo sąmoningai apribotas iki 20.

Dabar plačiau pažvelkime į kuriamos informacinės sistemos loginį duomenų modelį, pateiktą 3.6 pav.

Ryžiai. 3.5

Ryžiai. 3.6

Iš pateikto duomenų modelio matyti, kad jame yra trys subjektai, kurių kiekvienas turi savo atributų rinkinį, ir du iš jų yra priklausomi, o vienas ne.

Subjektas „Darbuotojas“, kuris yra nepriklausomas subjektas, turi šiuos požymius:

• · Darbuotojo identifikavimo numeris yra pirminis raktasšis subjektas;
• · Pilnas darbuotojo vardas ir pavardė;
• · Specializacijos sritis;
• · Įvertinimas;
• · Papildoma informacija.

Subjektas „Klientas“ yra priklausomas nuo „Darbuotojo“ subjekto, o tai reiškia, kad kiekvienas darbuotojas gali aptarnauti daug klientų. Kliento objektas turi šiuos atributus:

• · Paso serija ir numeris – yra pirminis šio subjekto raktas;
• · Darbuotojo identifikavimo numeris – yra antrinis šio subjekto raktas;
• · Pilnas darbuotojo vardas ir pavardė;
• · Specializacijos sritis;
• · Įvertinimas;
• · Papildoma informacija.

Objektas „Dokumentas“ yra priklausomas nuo objekto „Klientas“, o tai reiškia, kad kiekvienas klientas archyve gali saugoti daug skirtingų dokumentų. Dokumento objektas turi šiuos atributus:

• · Dokumento identifikatorius – yra pirminis šio subjekto raktas;
• · Paso serija ir numeris – yra antrinis šio subjekto raktas;
• · Dokumento pavadinimas;
• · Gavimo data;
• · Priklausymas grupei;
• · Stulpelio numeris;
• · Lentynos numeris;
• · Skaidrės numeris;
• · Dokumento buvimas langelyje.

Elementai, užtikrinantys IS veikimą bet kokiam tikslui, yra išvardyti apibrėžime. Vieni iš jų – priemonės, metodai ir personalas – užtikrina informacinės sistemos veikimą, o kiti – informacijos saugojimą, apdorojimą ir išvedimą – nurodo funkcines charakteristikas, t.y. nustatyti, kokie informaciniai procesai sudaro IS funkcionavimą. Todėl IS struktūra nagrinėjama dviejuose skirtinguose planuose: funkcinė struktūra ir IS kaip pagalbinių posistemių rinkinio struktūra.

Pagal apibrėžimą IS funkciniai elementai yra šios procesų grupės (blokai):

informacijos įvedimas iš išorinių ar vidinių šaltinių;

apdoroti įvestą informaciją ir pateikti ją patogia forma;

informacijos išvedimas pateikti vartotojams arba perkelti į kitą IS;

Atsiliepimai yra informacija, kurią apdoroja tam tikros organizacijos žmonės, norėdami pataisyti įvestą informaciją.

Funkcinė struktūra Informacinė sistema pateikiama blokinės schemos pavidalu (1 pav.), kurioje kiekvienas sistemos elementas vaizduojamas kaip blokas (paveiksle stačiakampis), o jungtys ir jų kryptys nurodomos rodyklėmis.

Atskiros dalys (sistemos blokai) vadinamos posistemėmis.

Kiekvienu konkrečiu atveju funkcinių posistemių rinkinys ir ryšiai priklauso nuo dalykinės srities ir įmonės, kurios veiklą palaiko informacinė sistema, specifikos.

IS struktūrą taip pat galima pateikti kaip pagalbinių posistemių kompleksą (2 pav.).

1 pav. Apibendrinta IC funkcinė blokinė schema.

Tačiau AIS, kurios skiriasi informacijos apdorojimo pobūdžiu ir tipais, funkcinė diagrama skiriasi apdorojimo posistemių rinkiniu. Pavyzdžiui, AIPS (biblioteka, muziejus, teisinė nuoroda ir kt.) vartotojo pageidavimu įveda, sistemina, saugo, ieško ir išduoda informaciją be sudėtingų duomenų transformacijų. Informacinių sprendimų sistemos: ASOD, ACS, DSS – apdoroja duomenų bazės informaciją pagal konkretų algoritmą, tačiau skiriasi ir informacijos apdorojimo posistemių sudėtimi. CAD specializuojasi projektavimo automatizavime savo struktūroje turi specialias posistemes: techninę dokumentaciją, užduočių generavimą, imitacinį modeliavimą, skaičiavimą, o kai kuriose gali būti ir ekspertinė sistema (žr. blokinę schemą 2 pav.).

2 pav. CAD blokinė schema

Panagrinėkime kitą IS struktūros tipą: kaip pagalbinių posistemių kompleksą (3 pav.).

Informacinės sistemos struktūra gali būti laikoma posistemių visuma, neatsižvelgiant į taikymo sritį. Posistemis yra sistemos dalis, išsiskirianti tam tikra charakteristika. Šiuo atveju jie kalba apie struktūrinį klasifikavimo požymį, o posistemės vadinamos pagalbinėmis.

Taigi bet kurios informacinės sistemos struktūra gali būti pavaizduota pagalbinių posistemių rinkiniu.

3 pav. IS struktūra pagal pagalbinių posistemių tipą.

Tarp pagalbinių posistemių dažniausiai išskiriama informacinė, techninė, matematinė, programinė, organizacinė ir teisinė pagalba.

Informacinis palaikymas– informacijos duomenų rinkinių rinkinys, vieninga sistema informacijos klasifikavimas ir kodavimas, vieningos dokumentacijos sistemos, organizacijoje cirkuliuojančių informacijos srautų modeliai, taip pat duomenų bazių kūrimo metodika. Informacinės paramos posistemio tikslas – laiku generuoti ir pateikti patikimą informaciją valdymo sprendimams priimti.

Vieningos dokumentacijos sistemos kuriami valstybiniu, respublikiniu, sektoriniu ir regioniniu lygiu. Pagrindinis tikslas – užtikrinti rodiklių palyginamumą įvairiose socialinės gamybos srityse. Buvo sukurti standartai, kurie nustato šiuos reikalavimus:

prie vieningų dokumentų sistemų;

į suvienodintas įvairių valdymo lygių dokumentų formas;

į detalių ir rodiklių sudėtį ir struktūrą;

prie vienodų dokumentų formų įgyvendinimo, priežiūros ir registravimo tvarkos.

Nepaisant vieningos dokumentacijos sistemos, daugumos organizacijų apklausa atskleidžia daugybę tipiškų trūkumų:

itin didelė dokumentų apimtis rankiniam tvarkymui;

tie patys rodikliai dažnai dubliuojami skirtinguose dokumentuose;

dirbti su didelė suma dokumentai atitraukia specialistus nuo neatidėliotinų problemų sprendimo;

yra sukurti, bet nenaudojami rodikliai ir pan.

Šių trūkumų pašalinimas yra viena iš užduočių, su kuriomis susiduriama kuriant informacinę paramą.

Informacijos srauto diagramos atspindi informacijos judėjimo maršrutus, jos apimtis, pirminės informacijos atsiradimo vietas ir gautos informacijos panaudojimą. Išanalizavus tokių schemų struktūrą, galima parengti priemones visai valdymo sistemai tobulinti.

Informacijos srautų diagramų, leidžiančių identifikuoti informacijos maršrutus ir apimtis, rodiklių dubliavimą ir jų apdorojimo procesus, sudarymas ir detali analizė užtikrina:

pasikartojančios ir nepanaudotos informacijos pašalinimas;

informacijos klasifikavimas ir racionalus pateikimas.

Duomenų bazių kūrimo metodika remiasi jų projektavimo teoriniais pagrindais.

Pagrindinės metodologijos sąvokos:

aiškus visos organizacijos valdymo sistemos tikslų, uždavinių, funkcijų supratimas;

identifikuojantis informacijos judėjimą nuo jos atsiradimo iki jos panaudojimo įvairiose valdymo lygius, pateikta analizei informacijos srautų diagramų pavidalu;

dokumentų srauto sistemos tobulinimas;

klasifikavimo ir kodavimo sistemos prieinamumas ir naudojimas;

konceptualios informacijos kūrimo metodikos ir loginių modelių, atspindinčių informacijos tarpusavio ryšį, išmanymas;

informacinių masyvų kūrimas kompiuterinėse laikmenose, kuriam reikalingas šiuolaikiškas techninis palaikymas.

Ši koncepcija praktiškai įgyvendinama dviem etapais.

1 etapas – visų įmonės funkcinių padalinių patikrinimas, siekiant:

suprasti savo veiklos specifiką ir struktūrą;

sudaryti informacijos srautų schemą;

analizuoti esamą dokumentų srautų sistemą;

nustatyti informacinius objektus ir atitinkamą detalių (parametrų, charakteristikų) kompoziciją, apibūdinančią jų savybes ir paskirtį.

2 etapas – konceptualios informacijos ir loginio duomenų modelio konstravimas remiantis I etapo apklausos rezultatais. Šiame modelyje visi ryšiai tarp objektų ir jų detalių turi būti nustatyti ir optimizuoti. Informacinis loginis modelis yra pagrindas, ant kurio bus kuriama duomenų bazė.

Techninė pagalba– techninių priemonių, skirtų informacinei sistemai veikti, rinkinį, taip pat atitinkamą šių priemonių ir technologinių procesų dokumentaciją.

Techninių priemonių kompleksą sudaro:

bet kokio modelio kompiuteriai;

Informacijos rinkimo, kaupimo, apdorojimo, perdavimo ir išvedimo prietaisai;

duomenų perdavimo įrenginiai ir ryšio linijos;

biuro įranga ir automatiniai informacijos paieškos įrenginiai;

eksploatacinės medžiagos ir kt.

Dokumentacija apima preliminarų techninių priemonių pasirinkimą, jų veikimo organizavimą, duomenų apdorojimo technologinį procesą, technologinę įrangą. Dokumentus galima suskirstyti į tris grupes:

visos sistemos, įskaitant valstybės ir pramonės standartus techninei pagalbai;

specializuotas, turintis technikų rinkinį visiems aparatinės įrangos kūrimo etapams;

normatyvas ir nuoroda, naudojama atliekant techninės pagalbos skaičiavimus.

Iki šiol susiformavo dvi pagrindinės techninės pagalbos organizavimo formos (techninių priemonių panaudojimo formos): centralizuota ir iš dalies arba visiškai decentralizuota.

Centralizuotas techninis palaikymas pagrįstas didelių kompiuterių ir kompiuterių centrų naudojimu informacinėje sistemoje. Tokia organizavimo forma palengvina standartizacijos valdymą ir įgyvendinimą, tačiau sumažina darbuotojų atsakomybę ir iniciatyvą.

Techninių priemonių decentralizavimas apima funkcinių posistemių diegimą asmeniniuose kompiuteriuose tiesiai darbo vietose. Tokiu atveju iš personalo reikalaujama daugiau asmeninės atsakomybės, o vadovybei sunkiau įgyvendinti standartizaciją.

Šiuo metu labiau paplitęs iš dalies decentralizuotas požiūris – techninės pagalbos organizavimas, pagrįstas paskirstytais tinklais, susidedančiais iš asmeninių kompiuterių ir pagrindinio kompiuterio, skirto bet kokiems funkciniams posistemiams bendroms duomenų bazėms saugoti.

Matematika ir programinė įranga– matematinių metodų, modelių, algoritmų ir programų visuma informacinės sistemos tikslams ir uždaviniams įgyvendinti, taip pat normaliam techninių priemonių komplekso funkcionavimui.

Prie priemonių programinė įranga susieti:

valdymo procesų modeliavimo įrankiai;

tipinės valdymo užduotys;

matematinio programavimo metodai, matematinė statistika, eilių teorija ir kt.

dalis programinė įranga apima visos sistemos ir specialius programinės įrangos produktus, taip pat techninę dokumentaciją.

KAM visos sistemos programinė įranga Tai apima į vartotoją orientuotus programinės įrangos paketus, skirtus tipinėms informacijos apdorojimo problemoms spręsti. Jie skirti išplėsti kompiuterių funkcionalumą, kontroliuoti ir valdyti duomenų apdorojimo procesą.

Speciali programinė įranga yra programų rinkinys, sukurtas kuriant konkrečią informacinę sistemą. Tai apima taikomosios programinės įrangos paketus (APP), kurie įgyvendina sukurtus įvairaus adekvatumo modelius, atspindinčius realaus objekto veikimą.

Programinės įrangos kūrimo techninėje dokumentacijoje turi būti užduočių aprašymas, algoritmizavimo užduotis, ekonominis ir matematinis problemos modelis, bandymų pavyzdžiai.

Organizacinis palaikymas yra metodų ir priemonių visuma, reguliuojanti darbuotojų sąveiką su techninėmis priemonėmis ir tarpusavyje kuriant ir eksploatuojant IS.

Organizacinė pagalba įgyvendina šias funkcijas:

analizė esama sistema organizacijos, kurioje bus naudojama IS, valdymas ir automatizuojamų užduočių nustatymas;

problemų rengimas sprendimui kompiuteriu, įskaitant technines IS projektavimo specifikacijas ir jos efektyvumo galimybių studiją;

valdymo sprendimų dėl organizacijos sudėties ir struktūros kūrimas, problemų sprendimo metodika, nukreipta į valdymo sistemos efektyvumą.

Organizacinė parama kuriama remiantis priešprojektinės apklausos I-ame duomenų bazės kūrimo etape rezultatais.

Teisinė pagalba– informacijos gavimo, transformavimo ir naudojimo tvarką reglamentuojančių informacinių sistemų kūrimą, teisinį statusą ir funkcionavimą lemiančių teisės normų visuma.

Pagrindinis teisinės paramos tikslas – stiprinti teisinę valstybę. Teisinė pagalba apima įstatymus, potvarkius, valstybės valdžios institucijų nutarimus, įsakymus, nurodymus ir kitus ministerijų, departamentų, organizacijų, vietos valdžios norminius dokumentus. Teisinę pagalbą galima suskirstyti į bendrąją dalį, kuri reguliuoja bet kurios informacinės sistemos funkcionavimą, ir vietinę, kuri reguliuoja konkrečios sistemos funkcionavimą.

Teisinė pagalba informacinės sistemos kūrimo etapams apima reglamentavimą, susijusį su kūrėjo ir užsakovo sutartiniais santykiais bei nukrypimų nuo sutarties teisinį reglamentavimą.

Teisinė pagalba informacinės sistemos veikimo etapams apima:

informacinės sistemos būsena;

personalo teisės, pareigos ir atsakomybė;

informacijos kūrimo ir naudojimo tvarka ir kt.

Šis posistemių rinkinys būdingas beveik visų tipų AIS. Tačiau pagalbinių posistemių struktūra ir sudėtingumas priklauso nuo AIS tipo, taikymo srities ir kitų veiksnių. Taigi programinės įrangos posistemis vyksta originalios programinės įrangos kūrimo AIS - AIS su standartine programine įranga jo nėra. Teisinės pagalbos posistemio gali nebūti įmonės vidaus AIS – tokiu atveju galite apsiriboti organizacinio palaikymo posistemiu, kuris, be kita ko, sprendžia teisinės pagalbos klausimus; AIS nepriklausomiems tikslams, pavyzdžiui, informacinių paslaugų sistemoms, gali turėti teisinės paramos posistemį. AIS, turinčios faktines duomenų bazes, turi tik informacijos palaikymo posistemį, kuriame gali prireikti spręsti atskirus kalbinius klausimus. Dokumentinis AIPS turi išvystytą kalbinio palaikymo posistemį, nes šios sistemos sprendžia sudėtingas vartotojų užklausų semantinio atitikimo išduodamų dokumentų turiniui užtikrinimo problemas. Ir tai, kaip taisyklė, yra ne tik programinės įrangos moduliai morfologinei analizei, bet ir žodynų rinkinys bei jų priežiūros taisyklės.

IP kūrimo ir įgyvendinimo tikslai.

Ko galima tikėtis diegiant informacines sistemas?

Informacinių sistemų įdiegimas gali prisidėti prie:

1. atleisti darbuotojus nuo įprastų darbų ir paspartinti juos automatizuojant;

2. popierinių duomenų laikmenų pakeitimas magnetiniais diskais ar juostelėmis, dėl to sumažėja dokumentų kiekis popieriuje, taigi ir galimybė racionaliau organizuoti informacijos apdorojimą kompiuteriu;

3. informacijos srautų struktūros ir dokumentų srautų sistemos tobulinimas įmonėje dėl sisteminio efekto: vienkartinis duomenų įvedimas – pakartotinis ir įvairiapusis naudojimas“;

4. racionalesnių valdymo problemų sprendimo galimybių gavimas (diegiant matematinius metodus ir intelektualias sistemas ir kt.):

naujų rinkos nišų paieška;

produktų ir/ar paslaugų gamybos kaštų optimizavimas;

santykių su klientais ir tiekėjais optimizavimas.

Informacinių sistemų kūrimo etapai

IP raidos istorija suskirstyta į etapus (2 lentelė), atitinkančius maždaug priimtą tikslų numeraciją – požiūris į IP naudojimą keičiasi.

2 lentelė. IP kūrimo etapai.

Laiko periodas	Informacijos naudojimo koncepcija	Informacinių sistemų tipas	Naudojimo paskirtis
1950 – 1960 m	Popierinis atsiskaitymo dokumentų srautas	Atsiskaitymų dokumentų tvarkymo informacinės sistemos elektromechaninėse apskaitos mašinose	Padidinti dokumentų apdorojimo greitį Sąskaitų faktūrų apdorojimo ir darbo užmokesčio apskaitos supaprastinimas
1960 – 1970 m	Pagrindinė pagalba rengiant ataskaitas	Valdymo informacinės sistemos gamybos informacijai	Paspartinti ataskaitų teikimo procesą
1970 – 1980 m	Pardavimų (pardavimų) valdymo kontrolė	Sprendimų palaikymo sistemos Sistemos vyresniajai vadovybei	Racionaliausio sprendimo atranka
1980 – 2000 m	Informacija yra strateginis išteklius, suteikiantis konkurencinį pranašumą	Strateginės informacinės sistemos Automatizuoti biurai	Įmonės išlikimas ir klestėjimas

Pirmosios informacinės sistemos atsirado praėjusio amžiaus viduryje. 50-aisiais jie buvo skirti sąskaitoms faktūroms apdoroti ir darbo užmokesčio apskaičiavimui, buvo įdiegti elektromechaninėse apskaitos mašinose. Dėl to šiek tiek sumažėjo popierinių dokumentų rengimo išlaidos ir laikas.

60-ieji pasižymi požiūrio į informacines sistemas pasikeitimu. Iš jų gauta informacija buvo pradėta naudoti periodinėms ataskaitoms apie daugelį parametrų. Šiandien organizacijoms reikėjo bendrosios paskirties kompiuterinės įrangos, galinčios atlikti daugybę funkcijų, o ne tik tvarkyti sąskaitas ir skaičiuoti atlyginimus, kaip buvo anksčiau.

70-aisiais - 80-ųjų pradžioje. Informacinės sistemos pradedamos plačiai naudoti kaip valdymo kontrolės priemonė, palaikanti ir pagreitinanti sprendimų priėmimo procesą.

Iki 80-ųjų pabaigos. Vėl keičiasi informacinių sistemų naudojimo samprata. Jie tampa strateginiu informacijos šaltiniu ir naudojami visuose bet kurios organizacijos lygiuose. Šio laikotarpio informacinės sistemos, laiku pateikdamos reikiamą informaciją, padeda organizacijai pasiekti sėkmės savo veikloje, kurti naujas prekes ir paslaugas, rasti naujas rinkas, užsitikrinti vertus partnerius, organizuoti produkcijos gamybą žema kaina ir kt.

Šiuolaikinis informacinės sistemos supratimas numato asmeninio kompiuterio naudojimą kaip pagrindinę techninę informacijos apdorojimo priemonę. Didelėse organizacijose kartu su Asmeninis kompiuteris Informacinės sistemos techninę bazę gali sudaryti pagrindinis kompiuteris arba superkompiuteris. Be to, informacinės sistemos techninis įgyvendinimas pats savaime nieko nereikš, jei nebus atsižvelgta į asmens, kuriam sukurta informacija yra skirta ir be kurio neįmanoma gauti ir pateikti jos, vaidmenį.